Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 266956C for ; 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 ; Wed, 15 Nov 2017 05:02:50 +0000 (UTC) Received: by mail-lf0-f48.google.com with SMTP id e143so24776972lfg.12 for ; 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> <45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl> <95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl> <55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl> <46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl> <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com> <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com> <71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com> From: Jacob Eliosoff Date: Wed, 15 Nov 2017 00:02:48 -0500 Message-ID: To: Mats Jerratsch 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 , 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 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
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

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 all 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>It may make sense to revise your proposal to incorporate Luke's OP_= CHECKBLOCKATHEIGHT, 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!


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 no= t 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.. si= nce you don't need one. Also, all the old outputs work fine, and LN not= an issue.

I'm missi= ng 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. 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

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].

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.

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

If the bit isn't set, it means `nForkId=3D0`, w= hich allows other forks to validate the signature.

<= div dir=3D"ltr">
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...

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>[1]

--94eb2c1a64324156d4055dfe6af8--