diff options
author | Jacob Eliosoff <jacob.eliosoff@gmail.com> | 2017-11-15 00:02:48 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-11-15 05:02:52 +0000 |
commit | 2b8f9b41654490c74d6ffe1a0feec1c4c7c85f73 (patch) | |
tree | 1224abe9781756a00aa6faa3ef145a3a224840f0 | |
parent | 935b947d0c542944a3ccd3ec19c4343223d784dd (diff) | |
download | pi-bitcoindev-2b8f9b41654490c74d6ffe1a0feec1c4c7c85f73.tar.gz pi-bitcoindev-2b8f9b41654490c74d6ffe1a0feec1c4c7c85f73.zip |
Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks
-rw-r--r-- | 5d/4b8ea1f27cdfd3a44cbf44b644d55e63b08f44 | 266 |
1 files changed, 266 insertions, 0 deletions
diff --git a/5d/4b8ea1f27cdfd3a44cbf44b644d55e63b08f44 b/5d/4b8ea1f27cdfd3a44cbf44b644d55e63b08f44 new file mode 100644 index 000000000..1365cb24a --- /dev/null +++ b/5d/4b8ea1f27cdfd3a44cbf44b644d55e63b08f44 @@ -0,0 +1,266 @@ +Return-Path: <jacob.eliosoff@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 266956C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 15 Nov 2017 05:02:52 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com + [209.85.215.48]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 08A52FD + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 15 Nov 2017 05:02:50 +0000 (UTC) +Received: by mail-lf0-f48.google.com with SMTP id e143so24776972lfg.12 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 14 Nov 2017 21:02:50 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to + :cc; bh=SrPJjw1Pa6iOqE07RCuExg8LOefkccLA0i79uFq2DDQ=; + b=e2c9UbJhKpV0QjYTa0j+NkbQPL8zHCD/xAUtK8z5KyuoIUBDPgJeR4gIv22GlX+G36 + 9dA2wgv1Ymm+WaNCtRPZu5zFYBv/+CkaCRMbnx5udjWF0HpPqtDQmxowpbxCU0L9EVzz + 3SM4uMpTUZb3KiCwUYo/VIijl7jkfRHhsnF/lxkrFiuzaitwp1KmDofFWWhrnqoq+O7V + FcjPfkSQs+khRZzkUKD+AIIaJsjtrR51W5egXCqircp7Gd76TxV0MOW3LqV51NLAPdgI + dNTib5Th3OCBy/Hn/5sNOj8UWxfdykgVN3N6v9ovIGb0oTbYZJXqcP4ys6cj03yVh3xe + YTbA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to:cc; + bh=SrPJjw1Pa6iOqE07RCuExg8LOefkccLA0i79uFq2DDQ=; + b=kcWavNROkUNaG3KouaDvDvdoG5u5m+9tPV4g4DYgdD8qXLu6/SWWsreAX1MdvFBal0 + PIYqus541fgHKlVLSxiIMiO1JFPeLl4YqZtYtDjSIMlOwZJqY9r1qKTM5H3qwJTa3CYt + KIAUBwU3+4Dea7alRoJoV9D8MxxYS1I+H1pr3Awtpe85Kp8KK3MdfLv4Bb/TEYETSfnl + rlmdVgfVOCaJ7rAWNKzoF5WUcE+MM2dZK3XrdM8C4qcvs5Q5cziwP1/akL52v7rdtUN2 + Ro+45w5MT+VUpzp28qoBa3sD87zKYrzjaX8r1ZgXHapvgh7E+YOSE+fj/HvSMOd+514R + FemA== +X-Gm-Message-State: AJaThX4USAK5BwDszp7Fy+e+gkJ+lcKeU2Uj7sXX7lCjdAt7Xy9dLHAb + S/tZulIb8qCrmIp60HZmvw1cVvkxdBEdKc1iZw8= +X-Google-Smtp-Source: AGs4zMaVNL1goiKp+DIgPfxM9v1PVGa94aUcVTIo4pPWzyvijIR8EM2S98oDtPwiocA0eTF+xA3QDWnfkvT6p3Y7N2A= +X-Received: by 10.46.29.207 with SMTP id w76mr63388lje.171.1510722169295; Tue, + 14 Nov 2017 21:02:49 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.25.215.19 with HTTP; Tue, 14 Nov 2017 21:02:48 -0800 (PST) +In-Reply-To: <71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com> +References: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com> + <CAAUaCyii2U5VBLS+Va+F3h4Hka0OWDnFFmjtsvyaaD4TKVzV3Q@mail.gmail.com> + <CAAUaCyiZ0bmWZLZc-yDvVHupzbdRR=Kdq4P8VkWqpU1L3G-u3A@mail.gmail.com> + <C9A47922-5777-44AC-871A-6C27A22054AC@blockchain.com> + <CAAUaCyjVxJbPrbBUdb9irK5CNnuqUSnzSjywpozhLqONcb_m_w@mail.gmail.com> + <45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl> + <CAAUaCygeOxAK=EpzfWndx6uVvVO9B+=YTs1m-jHa3BFp82jA4w@mail.gmail.com> + <95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl> + <CAAUaCyg_PGT0F=RHfX89T54j-vuyz5wcbXaYoikJv95WKgsNPg@mail.gmail.com> + <55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl> + <CAAUaCyhncyCt_ao9i0=33LswDOkCf6o-+36zrGxKWD+WranmZw@mail.gmail.com> + <46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl> + <CAAUaCyibOEHqw1J5O8yEp8v=j8t9sovn2vn=S8bZPZCzCY-gRw@mail.gmail.com> + <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com> + <CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com> + <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com> + <CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.gmail.com> + <CA+Cf5AZT6KtRXmt3X6UiF0tP_hCtbUiUsS3XMXDdoaa0T1tepQ@mail.gmail.com> + <71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com> +From: Jacob Eliosoff <jacob.eliosoff@gmail.com> +Date: Wed, 15 Nov 2017 00:02:48 -0500 +Message-ID: <CAAUaCyjpH0hAxS7pUzZihft3KDtgB3nkZdT_6JUhmE9hJ7T4sA@mail.gmail.com> +To: Mats Jerratsch <mats@blockchain.com> +Content-Type: multipart/alternative; boundary="94eb2c1a64324156d4055dfe6af8" +X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, + DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE + autolearn=disabled 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, 15 Nov 2017 11:16:06 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard + Forks +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, 15 Nov 2017 05:02:52 -0000 + +--94eb2c1a64324156d4055dfe6af8 +Content-Type: text/plain; charset="UTF-8" + +> +> Sorry, I was careless with the use of `>=` there. You are correct, forks +> form a tree. For this proposal, every leaf must be assigned a unique +> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which +> number is bigger), as long as they are unique. Transactions are only valid +> IFF `nForkId` matches exactly the `nForkId` of the software validating it. +> As described above, the transaction doesn't even contain `nForkId`, and the +> node surely is not starting to guess which one it could be. +> + +OK, but then it seems to me you have a dilemma for, eg, your LN commitment +tx. You either give it the specific nForkId of the fork it's created on - +making it invalid on *all* other forks (eg, any future "non-contentious +upgrade" HF that replaces that fork). Or you give it nForkId 0 - which has +the "BCH tx valid on Segwit2x (& vice versa)" flaw. + +It may make sense to revise your proposal to incorporate Luke's +OP_CHECKBLOCKATHEIGHT +<https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki>, and make +the fork ID a (block height, hash) pair rather than just a number. But I +still think the idea of fork-specific addresses is a keeper! + + +On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <mats@blockchain.com> wrote: + +> +> But I like the 'old' idea of putting the hash of a block that MUST be on +> the chain that this txn can eventually be added to. If the hash is not a +> valid block on the chain, the txn can't be added. +> +> It means you can choose exactly which forks you want to allow your txn on, +> pre-fork for both, post-fork for only one, and gets round the issue of who +> gets to decide the nForkid value.. since you don't need one. Also, all the +> old outputs work fine, and LN not an issue. +> +> I'm missing why this scheme would be better ? +> +> +> I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the +> sense that they are very difficult to circumvent. However, a fork could +> also follow the original chain in SPV mode and allow transactions protected +> with these mechanism. Since it's fundamentally impossible to disallow +> transactions in future projects, the goal shouldn't be to make this overly +> complicated. +> +> Furthermore, this schema is not just adding replay protection. It makes +> transacting safer overall (due to a dedicated address format per fork) and +> allows light clients to differentiate between multiple forks. In the past +> three months, at least $600k has been lost by users sending BCH to a BTC +> address [1]. +> +> Thanks for the clarification. How would a tx specify a constraint like +>> "nForkId>=1"? I was thinking of it just as a number set on the tx. +>> +> +> Whether the transaction is replay protected or not is specified by setting +> a bit in the `SigHashId`. If this bit is set, then the signature *preimage* +> MUST have `nForkId` appended. `nForkId` is not part of the final +> transaction, someone who wants to verify the transaction must know which +> `nForkId` it was created with. +> +> If the bit isn't set, it means `nForkId=0`, which allows other forks to +> validate the signature. +> +> Also note that since forks form a partial order, but IDs (numbers) form a +>> total order, ">=" will miss some cases. Eg, suppose BCH had forked with +>> nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and +>> then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would +>> be valid on Segwit2x. This is more of a fundamental problem than a bug - +>> to avoid it you'd have to get into stuff like making each fork reference +>> its parent-fork's first block or something, someone has written about +>> this... +>> +> +> Sorry, I was careless with the use of `>=` there. You are correct, forks +> form a tree. For this proposal, every leaf must be assigned a unique +> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which +> number is bigger), as long as they are unique. Transactions are only valid +> IFF `nForkId` matches exactly the `nForkId` of the software validating it. +> As described above, the transaction doesn't even contain `nForkId`, and the +> node surely is not starting to guess which one it could be. +> +> [1] +> https://twitter.com/khannib/status/930223617744437253 +> + +--94eb2c1a64324156d4055dfe6af8 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail= +_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= +,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Sorry, I w= +as careless with the use of `>=3D` there. You are correct, forks form a = +tree. For this proposal, every leaf must be assigned a unique `nForkId`. Th= +e relationship between `nForkId` is irrelevant (e.g. which number is bigger= +), as long as they are unique. Transactions are only valid IFF `nForkId` ma= +tches exactly the `nForkId` of the software validating it. As described abo= +ve, the transaction doesn't even contain `nForkId`, and the node surely= + is not starting to guess which one it could be.=C2=A0</div></div></blockqu= +ote></div></div><div><br></div><div>OK, but then it seems to me you have a = +dilemma for, eg, your LN commitment tx.=C2=A0 You either give it the specif= +ic nForkId of the fork it's created on - making it invalid on <i>all</i= +> other forks (eg, any future "non-contentious upgrade" HF that r= +eplaces that fork).=C2=A0 Or you give it nForkId 0 - which has the "BC= +H tx valid on Segwit2x (& vice versa)" flaw.</div><div><br></div><= +div>It may make sense to revise your proposal to incorporate Luke's <a = +href=3D"https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki">OP_= +CHECKBLOCKATHEIGHT</a>, and make the fork ID a (block height, hash) pair ra= +ther than just a number.=C2=A0 But I still think the idea of fork-specific = +addresses is a keeper!</div><br><div class=3D"gmail_extra"><br><div class= +=3D"gmail_quote">On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <span dir= +=3D"ltr"><<a href=3D"mailto:mats@blockchain.com" target=3D"_blank">mats@= +blockchain.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= +tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= +ding-left:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D"gmai= +l-"><br><blockquote type=3D"cite"><div><div dir=3D"auto"><div dir=3D"auto">= +But I like the 'old' idea of putting the hash of a block that MUST = +be on the chain that this txn can eventually be added to. If the hash is no= +t a valid block on the chain, the txn can't be added.<br></div><div dir= +=3D"auto"><br></div><div dir=3D"auto">It means you can choose exactly which= + forks you want to allow your txn on, pre-fork for both, post-fork for only= + one, and gets round the issue of who gets to decide the nForkid value.. si= +nce you don't need one. Also, all the old outputs work fine, and LN not= + an issue.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I'm missi= +ng why this scheme would be better ?<br></div></div></div></blockquote><div= +><br></div></span><div>I do agree that solutions like `SIGHASH_BLOCKCOMMIT`= + are superior in the sense that they are very difficult to circumvent. Howe= +ver, a fork could also follow the original chain in SPV mode and allow tran= +sactions protected with these mechanism. Since it's fundamentally impos= +sible to disallow transactions in future projects, the goal shouldn't b= +e to make this overly complicated.=C2=A0</div><div><br></div><div>Furthermo= +re, this schema is not just adding replay protection. It makes transacting = +safer overall (due to a dedicated address format per fork) and allows light= + clients to differentiate between multiple forks. In the past three months,= + at least $600k has been lost by users sending BCH to a BTC address [1].</d= +iv><span class=3D"gmail-"><div><br></div><blockquote type=3D"cite"><div cla= +ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu= +ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= +4);padding-left:1ex"><div dir=3D"ltr">Thanks for the clarification.=C2=A0 H= +ow would a tx specify a constraint like "nForkId>=3D1"?=C2=A0 = +I was thinking of it just as a number set on the tx.</div></blockquote></di= +v></div></blockquote><div><br></div></span><div>Whether the transaction is = +replay protected or not is specified by setting a bit in the `SigHashId`. I= +f this bit is set, then the signature *preimage* MUST have `nForkId` append= +ed. `nForkId` is not part of the final transaction, someone who wants to ve= +rify the transaction must know which `nForkId` it was created with.=C2=A0</= +div><div><br></div><div>If the bit isn't set, it means `nForkId=3D0`, w= +hich allows other forks to validate the signature.</div><span class=3D"gmai= +l-"><div><br></div><blockquote type=3D"cite"><div class=3D"gmail_extra"><di= +v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0= +px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><= +div dir=3D"ltr"><div>Also note that since forks form a partial order, but I= +Ds (numbers) form a total order, ">=3D" will miss some cases.= +=C2=A0 Eg, suppose BCH had forked with nForkId 2, and then you set up a LN = +funding tx on BCH with nForkId>=3D2, and then Segwit2x forked (from BTC!= +) with nForkId 3.=C2=A0 The BCH funding tx would be valid on Segwit2x.=C2= +=A0 This is more of a fundamental problem than a bug - to avoid it you'= +d have to get into stuff like making each fork reference its parent-fork= +9;s first block or something, someone has written about this...<br></div></= +div></blockquote></div></div></blockquote><div><br></div></span><div>Sorry,= + I was careless with the use of `>=3D` there. You are correct, forks for= +m a tree. For this proposal, every leaf must be assigned a unique `nForkId`= +. The relationship between `nForkId` is irrelevant (e.g. which number is bi= +gger), as long as they are unique. Transactions are only valid IFF `nForkId= +` matches exactly the `nForkId` of the software validating it. As described= + above, the transaction doesn't even contain `nForkId`, and the node su= +rely is not starting to guess which one it could be.=C2=A0</div></div><br><= +div>[1]</div><div><a href=3D"https://twitter.com/khannib/status/93022361774= +4437253" target=3D"_blank">https://twitter.com/khannib/<wbr>status/93022361= +7744437253</a></div></div></blockquote></div><br></div></div> + +--94eb2c1a64324156d4055dfe6af8-- + |