summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJacob Eliosoff <jacob.eliosoff@gmail.com>2017-11-15 00:02:48 -0500
committerbitcoindev <bitcoindev@gnusha.org>2017-11-15 05:02:52 +0000
commit2b8f9b41654490c74d6ffe1a0feec1c4c7c85f73 (patch)
tree1224abe9781756a00aa6faa3ef145a3a224840f0
parent935b947d0c542944a3ccd3ec19c4343223d784dd (diff)
downloadpi-bitcoindev-2b8f9b41654490c74d6ffe1a0feec1c4c7c85f73.tar.gz
pi-bitcoindev-2b8f9b41654490c74d6ffe1a0feec1c4c7c85f73.zip
Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks
-rw-r--r--5d/4b8ea1f27cdfd3a44cbf44b644d55e63b08f44266
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 `&gt;=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&#39;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&#39;s created on - making it invalid on <i>all</i=
+> other forks (eg, any future &quot;non-contentious upgrade&quot; HF that r=
+eplaces that fork).=C2=A0 Or you give it nForkId 0 - which has the &quot;BC=
+H tx valid on Segwit2x (&amp; vice versa)&quot; flaw.</div><div><br></div><=
+div>It may make sense to revise your proposal to incorporate Luke&#39;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">&lt;<a href=3D"mailto:mats@blockchain.com" target=3D"_blank">mats@=
+blockchain.com</a>&gt;</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 &#39;old&#39; 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&#39;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&#39;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&#39;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&#39;s fundamentally impos=
+sible to disallow transactions in future projects, the goal shouldn&#39;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 &quot;nForkId&gt;=3D1&quot;?=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&#39;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, &quot;&gt;=3D&quot; 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&gt;=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&#39;=
+d have to get into stuff like making each fork reference its parent-fork&#3=
+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 `&gt;=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&#39;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--
+