diff options
| author | Rusty Russell <rusty@rustcorp.com.au> | 2018-12-19 11:09:26 +1030 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-12-19 00:39:38 +0000 |
| commit | 8dcd8ef81d8819b66f58f6bfcbf45e85b7cbf8c7 (patch) | |
| tree | d69abac2e6aa060d226d9ac3f52793d2efa3d81a /31 | |
| parent | 3f8daa52fe88d090be6d2b75f1273aeba0004640 (diff) | |
| download | pi-bitcoindev-8dcd8ef81d8819b66f58f6bfcbf45e85b7cbf8c7.tar.gz pi-bitcoindev-8dcd8ef81d8819b66f58f6bfcbf45e85b7cbf8c7.zip | |
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Diffstat (limited to '31')
| -rw-r--r-- | 31/f8a8f4ed2e2973bdf94cfb3c3d9525af2bf056 | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/31/f8a8f4ed2e2973bdf94cfb3c3d9525af2bf056 b/31/f8a8f4ed2e2973bdf94cfb3c3d9525af2bf056 new file mode 100644 index 000000000..7b25ed8bb --- /dev/null +++ b/31/f8a8f4ed2e2973bdf94cfb3c3d9525af2bf056 @@ -0,0 +1,125 @@ +Return-Path: <rusty@ozlabs.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 23CBDD94 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 19 Dec 2018 00:39:38 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from ozlabs.org (ozlabs.org [203.11.71.1]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6377082F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 19 Dec 2018 00:39:37 +0000 (UTC) +Received: by ozlabs.org (Postfix, from userid 1011) + id 43KGHW2xbtz9s1c; Wed, 19 Dec 2018 11:39:35 +1100 (AEDT) +From: Rusty Russell <rusty@rustcorp.com.au> +To: Johnson Lau <jl2012@xbt.hk>, + bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk> +References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com> + <87ftv3xerx.fsf@rustcorp.com.au> + <DAAB7568-A004-4897-B5B3-0FBBC6895246@xbt.hk> + <87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au> + <20181214093002.p2nvfrlaycqblww3@erisian.com.au> + <8736qyhsej.fsf@rustcorp.com.au> + <6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk> +Date: Wed, 19 Dec 2018 11:09:26 +1030 +Message-ID: <87efaenydd.fsf@rustcorp.com.au> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Wed, 19 Dec 2018 12:40:29 +0000 +Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 19 Dec 2018 00:39:38 -0000 + +Johnson Lau <jl2012@xbt.hk> writes: +>> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev <bitcoin-dev@l= +ists.linuxfoundation.org> wrote: +>>=20 +>> Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= +ites: +>>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev= + wrote: +>>>> And is it worthwhile doing the mask complexity, rather than just +>>>> removing the commitment to script with NOINPUT? It *feels* safer to +>>>> restrict what scripts we can sign, but is it? +>>>=20 +>>> If it's not safer in practice, we've spent a little extra complexity +>>> committing to a subset of the script in each signature to no gain. If +>>> it is safer in practice, we've prevented people from losing funds. I'm +>>> all for less complexity, but not for that tradeoff. +>>=20 +>> There are many complexities we could add, each of which would prevent +>> loss of funds in some theoretical case. +> +> Every security measures are overkill, until someone get burnt. If these s= +ecurity measures are really effective, no one will get burnt. The inevitabl= +e conclusion is: every effective security measures are overkill. +> +>>=20 +>> From practical experience; reuse of private keys between lightning and +>> other things is not how people will lose funds[1]. +> +> So you argument seems just begging the question. Without NOINPUT, it is j= +ust impossible to lose money by key reuse, and this is exactly the topic we= + are debating. + +I think we're getting confused here. I'm contributing my thoughts from +the lightning implementer's point of view; there are other important +considerations, but this is my contribution. + +In *lightning* there are more ways to lose funds via secret reuse. + +Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous +property; with OP_MASK the danger is limited to reuse-on-the-same-script +(ie. if you use the same key for a non-lightning output and a lightning +output, you're safe with OP_MASK. However, this is far less likely in +practice). + +I state again: OP_MASK doesn't seem to gain *lightning* any significant +security benefit. + +> It does not need to be something like GetMaskedScript(GetScriptCodeForMul= +tiSig()). After all, only a very small number of script templates really ne= +ed NOINPUT. A GetMaskedScript() in a wallet is just an overkill (and a vuln= +erability if mis-implemented)=20 + +Our current transaction signing code is quite generic (and, if I may say +so, readable and elegant). We could, of course, special case +GetMaskedScript() for the case we need (the Eltoo examples I've seen +have a single OP_MASK at the front, which makes it trivial). + +> It=E2=80=99s also about functionality here: as I mentioned in another rep= +ly, OP_CODESEPARATOR couldn=E2=80=99t function properly with NOINPUT but wi= +thout OP_MASKEDPUSH + +The mailing list seems a bit backed up or something; I replied to that +in the hope you can clear my confusion on that one. + +> This debate happens because NOINPUT introduces the third way to lose fund= + with key reuse. And once it is deployed, we have to support it forever, an= +d is not something that we could softfork it away. + +A would use the same words to encourage you to create the simplest +possible implementation? + +I don't think we disagree on philosophy, just trade-offs. And that's +OK. + +Cheers, +Rusty. + |