Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CD537ACC for ; Tue, 14 Nov 2017 13:50:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C82401CE for ; Tue, 14 Nov 2017 13:50:01 +0000 (UTC) Received: by mail-wr0-f194.google.com with SMTP id q66so17527677wrb.13 for ; Tue, 14 Nov 2017 05:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockchain.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4RqnIaP8GMYGtmhAZDRAcd51fZH92X9Dh1vjtErt4fM=; b=EH1wyl8PI+8QUQ7wLB3+ZJa+skI3l+J9Mg5aaE3TK+dmMHVWvCXlgUv0PBht4jJZoM 8x7HnER1SVz3T6cCX6rodfNvnHpKagvZQRT4tKf2GGXhn30OO02VohPg7FM0y69Lbj5C kADiRdJoUvx5Lu0JuGANVdAHoCVpB3bKZQcAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4RqnIaP8GMYGtmhAZDRAcd51fZH92X9Dh1vjtErt4fM=; b=SbrIXVO6MblLIQ3I1zsHjkIS7+MceB6HEFnRXb6mabO+m/5MfPYEX/eYMUwgfPpdui eQsYhLXDCR9kwykKrFTmgLcAEzHChfjKe6jdouUCdZ9EwIMlMQjyL3Vu/9Lo21hSghS5 TtS4BGmh+QWLMXGoVXQrF6tqC2RTPl0bJ1VVCMrUzmCv/I8J63oNxUK6xc4nlmk6pHN0 lfXdm8B+TVzvjoXei861hVwjkX7CLGOwxVew6Jn+1mQWEdDL6s/Szxwqk1MJvZv5u/PC eEk4kZr5GiyQr4zkxTmzulx4vMDyqAKNmpJH9LRhfjK2pxkTDA4AGwe/sPR2ydao1GeR xDEw== X-Gm-Message-State: AJaThX6ZA3vrf9l6t0BjKcNTO7l9HyrElCGU0UlLVChVUqVkIU4KW1dE lW8dxMIRaXCK0ITEbMxH2dJK+Q== X-Google-Smtp-Source: AGs4zMbzObYTFMt2dLn9kZDLCjOrY4zwmKIlgFq4cDrHJLPQxr5KOHJAlJ9YfYoFImvcfnlXoVr7qA== X-Received: by 10.223.184.171 with SMTP id i40mr11204527wrf.124.1510667400416; Tue, 14 Nov 2017 05:50:00 -0800 (PST) Received: from [192.168.2.105] (p5089FF1E.dip0.t-ipconnect.de. [80.137.255.30]) by smtp.gmail.com with ESMTPSA id 80sm13529409wmk.14.2017.11.14.05.49.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 05:49:58 -0800 (PST) From: Mats Jerratsch Message-Id: <71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com> Content-Type: multipart/signed; boundary="Apple-Mail=_514CAD64-72A6-44B0-A168-59C192AEA883"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 13:49:56 +0000 In-Reply-To: To: Spartacus Rex 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> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM 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 02:42:03 +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: Tue, 14 Nov 2017 13:50:02 -0000 --Apple-Mail=_514CAD64-72A6-44B0-A168-59C192AEA883 Content-Type: multipart/alternative; boundary="Apple-Mail=_F62ED146-51B9-4DD2-B93A-84D0D8AFA743" --Apple-Mail=_F62ED146-51B9-4DD2-B93A-84D0D8AFA743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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. >=20 > 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. >=20 > 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>=3D1"? 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=3D0`, which allows other forks = to validate the signature. > Also note that since forks form a partial order, but IDs (numbers) = form a total order, ">=3D" 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>=3D2, 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 `>=3D` 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 = --Apple-Mail=_F62ED146-51B9-4DD2-B93A-84D0D8AFA743 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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>=3D1"?  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=3D0`, which allows other forks to validate the = signature.

Also note that since forks form a partial = order, but IDs (numbers) form a total order, ">=3D" 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>=3D2, 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 `>=3D` = 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
= = --Apple-Mail=_F62ED146-51B9-4DD2-B93A-84D0D8AFA743-- --Apple-Mail=_514CAD64-72A6-44B0-A168-59C192AEA883 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJaCvSEAAoJEAYZmwZ/PsbKsO0P/R0Dm6NqaHqFqt9YMAg3wdRL OpAta3qPp7smJ8xqKgrzIFHxnobQWYPPTNt4pN3FlPnaA5zxGbjcR2tNRm/OmSRM 2/vuJHcNfM4v2fbxLpCqfniqxynmlEKW6vxzQYJppS8rHURJ+/H6yMsbm9TSNgpW IjIz8OuaSopk+bpvcB6iI64qMemd6UAKNnad5w1oQsZALok+DLe10VkGnenl08/L CfcPhaEyBBPqpr8m66xxc7W/UtPWeg5+SMTC5XDw90f5ahG5LJ0ibJYszATrgNXG Gz9oooNghAXVM7wMBYRlR9ZV6aTacFc/dZ/gdTqrhqtQ1e17bFU2qmRNMnuvUPl9 yuU0FF6Panc1e8LUs3/tBxsUK4z7l5YKya/KFlVzzipfZyALyvZSi99qxfPbMlgs sL2wZiFgpTN6M5Byqo1Du6DlFNxjpcrp/s4u3iTdQWFzjZnZ/zHKfobeQqkVt8/g TEpHm3B8bL+tNPIDzPLbQuN6uoakbUFvSd4MM736uQJClNZHZix/UCNGik3LJRdu JagdAqyxLRyiAH+wxaZAQ2GooAn2mIiN50pWOPo/28WWl0QFRgshioSyRUrp2nyc vcPPI8Fr/L83VxwI+1/d6o8H0rcVhnDQAs8EiUEU2ftfFkQ1ML8zctAdb2Q/Iq9Y f6gYJfas37RS5IGOIX/r =No9i -----END PGP SIGNATURE----- --Apple-Mail=_514CAD64-72A6-44B0-A168-59C192AEA883--