Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 387278F5 for ; Sun, 5 Nov 2017 23:48:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F361247A for ; Sun, 5 Nov 2017 23:48:47 +0000 (UTC) Received: by mail-wm0-f66.google.com with SMTP id s66so10482236wmf.5 for ; Sun, 05 Nov 2017 15:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockchain.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=CyFJwkEXflFkgbMUzYGzvg2x19OqsSYJBJ99c9cXuZo=; b=b4k9Dn3NdAq9nFzNEmto6lvGqHj9Cdy+OMJH3GcjGTyGi/pc6ivjBqm91J1W0LXUU0 IeDhEBUyOIyBPoQYHjZUOg7hj9ke7TWAmuLRu+i/WS1E7lgsTiUiDGnTq+Dm7glRUBuS Q1UvbNsdVPKE3xdoXiTnPIgq0649S/JWlo7YM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=CyFJwkEXflFkgbMUzYGzvg2x19OqsSYJBJ99c9cXuZo=; b=ucd5dpyATaPB1+OYslF5pnGeRwP2OJtzezE7VK160GvKQLNBAj70cAV/5/+sDOfU1a jed+KPZ2cH90Zb0TsVOFHDidzY6T5xLBiaxv0lsqcH42US8pj7JBqWNzncqk/sWVwCPn UIw/SGraxRhHQvnVSi3vn5jVwBwR4d2Pp1vj0ePgLzaqqS6T0vwz35BcEKPCSfZYo0Ky kVgrFFg5u5ExKRPQfr5LJsr35onPzDG9JDbjP+l37zuHIs6g7Q8sZ4li545Oi5Y5AaBS se3XEcGfsC6KAEuRYZZyN+6JLzimkHaBXuegmSzGD1ATurdpm/wt/yQ18M7FKr+bXlbp 4e6Q== X-Gm-Message-State: AJaThX56HAGgoQDMulQKxA9uqkt7h/cMih7Je/a6VKQF38fxlIczfxhC nA5w1zDHmOzjuwpkJ/Vn5BffHKCCrhM= X-Google-Smtp-Source: ABhQp+Qu54zzklLku+gP0YznyzwjU/wdhaefhhuSm3U++OgpCpst8OAxFG54rZL33vsI6g1Bvg0DNA== X-Received: by 10.28.143.212 with SMTP id r203mr3745634wmd.44.1509925726128; Sun, 05 Nov 2017 15:48:46 -0800 (PST) Received: from [192.168.15.233] (my83-216-95-75.cust.relish.net. [83.216.95.75]) by smtp.gmail.com with ESMTPSA id t14sm7918797wmc.46.2017.11.05.15.48.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 15:48:45 -0800 (PST) From: Mats Jerratsch Content-Type: multipart/signed; boundary="Apple-Mail=_FB246C13-2AA4-4E6E-8F31-1060D4A2BCBD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com> Date: Sun, 5 Nov 2017 23:48:43 +0000 To: bitcoin-dev@lists.linuxfoundation.org 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: Mon, 06 Nov 2017 15:05:03 +0000 Subject: [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: Sun, 05 Nov 2017 23:48:49 -0000 --Apple-Mail=_FB246C13-2AA4-4E6E-8F31-1060D4A2BCBD Content-Type: multipart/alternative; boundary="Apple-Mail=_60E21DC9-B230-429F-A3BC-54B3500AA09D" --Apple-Mail=_60E21DC9-B230-429F-A3BC-54B3500AA09D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Presented is a generalised way of providing replay protection for future = hard forks. On top of replay protection, this schema also allows for = fork-distinct addresses and potentially a way to opt-out of replay = protection of any fork, where deemed necessary (can be beneficial for = some L2 applications). ## Rationale Currently when a hard fork happens, there is ad-hoc replay protection = built within days with little review at best, or no replay protection at = all. Often this is either resource problem, where not enough time and = developers are available to sufficiently address replay protection, or = the idea that not breaking compatibility is favourable. Furthermore, = this is potentially a recurring problem with no generally accepted = solution yet. Services that want to deal in multiple forks are expected = to closely follow all projects. Since there is no standard, the = solutions differ for each project, requiring custom code for every fork. = By integrating replay protection into the protocol, we advocate the = notion of non-hostile forks. Users are protected against accidentally sending coins on the wrong = chain through the introduction of a fork-specific incompatible address = space. The coin/token type is encoded in the address itself, removing = some of the importance around the question _What is Bitcoin?_. By giving = someone an address, it is explicitly stated _I will only honour a = payment of token X_, enforcing the idea of validating the payment under = the rules chosen by the payee. ## Iterative Forks In this schema, any hard fork is given an incremented id, `nForkId`. = `nForkId` starts at `1`, with `0` being reserved as a wildcard. When = project X decides to make an incompatible change to the protocol, it = will get assigned a new unique `nForkId` for this fork. A similar = approach like for BIP43 can be taken here. Potentially `nForkId` can be = reused if a project has not gained any amount of traction. When preparing the transaction for signing or validation, `nForkId` is = appended to the final template as a 4B integer (similar to [1]). = Amending BIP143, this would result in ``` Double SHA256 of the serialization of: 1. nVersion of the transaction (4-byte little endian) 2. hashPrevouts (32-byte hash) 3. hashSequence (32-byte hash) 4. outpoint (32-byte hash + 4-byte little endian) 5. scriptCode of the input (serialized as scripts inside CTxOuts) 6. value of the output spent by this input (8-byte little endian) 7. nSequence of the input (4-byte little endian) 8. hashOutputs (32-byte hash) 9. nLocktime of the transaction (4-byte little endian) 10. sighash type of the signature (4-byte little endian) 11. nForkId (4-byte little endian) ``` For `nForkId=3D0` this step is ommitted. This will immediately = invalidate signatures for any other branch of the blockchain than this = specific fork. To distinguish between `nForkId=3D0` and `nForkId` = hardcoded into the software, another bit has to be set in the 1B = SigHashId present at the end of signatures. To make this approach more generic, payment addresses will contain the = fork id, depending on which tokens a payee expects payments in. This = would require a change on bech32 addresses, maybe to use a similar = format used in lightning-rfc [2]. A wallet will parse the address, it = will extract `nForkId`, and it displays which token the user is about to = spend. When signing the transaction, it will use `nForkId`, such that = the transaction is only valid for this specific token. This can be = generalised in software to the point where replay protection *and* a new = address space can be introduced for forks without breaking existing = clients. For light clients, this can be extended by enforcing the coinbase/block = header to contain the `nForkId` of the block. Then the client can = distinguish between different chains and tokens it received on each. = Alternatively, a new P2P message type for sending transactions could be = introduced, where prevOut and `nForkId` is transmitted, such that the = lite client can check for himself, which token he received. Allowing signatures with `nForkId=3D1` can be achieved with a soft fork = by incrementing the script version of SegWit, making this a fully = backwards compatible change. [1] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/0135= 42.html = [2] = https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-e= ncoding.md = --Apple-Mail=_60E21DC9-B230-429F-A3BC-54B3500AA09D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Presented is a = generalised way of providing replay protection for future hard forks. On = top of replay protection, this schema also allows for fork-distinct = addresses and potentially a way to opt-out of replay protection of any = fork, where deemed necessary (can be beneficial for some L2 = applications).

## Rationale

Currently when a hard fork happens, there is ad-hoc replay = protection built within days with little review at best, or no replay = protection at all. Often this is either resource problem, where not = enough time and developers are available to sufficiently address replay = protection, or the idea that not breaking compatibility is favourable. = Furthermore, this is potentially a recurring problem with no generally = accepted solution yet. Services that want to deal in multiple forks are = expected to closely follow all projects. Since there is no standard, the = solutions differ for each project, requiring custom code for every fork. = By integrating replay protection into the protocol, we advocate the = notion of non-hostile forks.

Users are protected against accidentally sending coins on the = wrong chain through the introduction of a fork-specific incompatible = address space. The coin/token type is encoded in the address itself, = removing some of the importance around the question _What is Bitcoin?_. = By giving someone an address, it is explicitly stated _I will only = honour a payment of token X_, enforcing the idea of validating the = payment under the rules chosen by the payee.

## Iterative = Forks

In this schema, any = hard fork is given an incremented id, `nForkId`. `nForkId` starts at = `1`, with `0` being reserved as a wildcard. When project X decides to = make an incompatible change to the protocol, it will get assigned a new = unique `nForkId` for this fork. A similar approach like for BIP43 can be = taken here. Potentially `nForkId` can be reused if a project has not = gained any amount of traction.

When preparing the transaction for signing or validation, = `nForkId` is appended to the final template as a 4B integer (similar to = [1]). Amending BIP143, this would result in

```
Double SHA256 of the serialization of:
 =     1. nVersion of the transaction (4-byte little = endian)
 =     2. hashPrevouts (32-byte hash)
 =     3. hashSequence (32-byte hash)
 =     4. outpoint (32-byte hash + 4-byte little = endian)
=     5. scriptCode of the input (serialized as = scripts inside CTxOuts)
 =     6. value of the output spent by this input = (8-byte little endian)
 =     7. nSequence of the input (4-byte little = endian)
 =     8. hashOutputs (32-byte hash)
 =     9. nLocktime of the transaction (4-byte little = endian)
    10. = sighash type of the signature (4-byte little endian)
   11. nForkId (4-byte = little endian)
```


For `nForkId=3D0` this = step is ommitted. This will immediately invalidate signatures for any = other branch of the blockchain than this specific fork. To distinguish = between `nForkId=3D0` and `nForkId` hardcoded into the software, another = bit has to be set in the 1B SigHashId present at the end of signatures. =

To make this approach = more generic, payment addresses will contain the fork id, depending on = which tokens a payee expects payments in. This would require a change on = bech32 addresses, maybe to use a similar format used in lightning-rfc = [2]. A wallet will parse the address, it will extract `nForkId`, and it = displays which token the user is about to spend. When signing the = transaction, it will use `nForkId`, such that the transaction is only = valid for this specific token. This can be generalised in software to = the point where replay protection *and* a new address space can be = introduced for forks without breaking existing clients.

For light clients, = this can be extended by enforcing the coinbase/block header to contain = the `nForkId` of the block. Then the client can distinguish between = different chains and tokens it received on each. Alternatively, a new = P2P message type for sending transactions could be introduced, where = prevOut and `nForkId` is transmitted, such that the lite client can = check for himself, which token he received.

Allowing signatures = with `nForkId=3D1` can be achieved with a soft fork by incrementing the = script version of SegWit, making this a fully backwards compatible = change.

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Fe= bruary/013542.html

[2]
https://github.com/lightningnetwork/lightning-rfc/blob/master/1= 1-payment-encoding.md
= --Apple-Mail=_60E21DC9-B230-429F-A3BC-54B3500AA09D-- --Apple-Mail=_FB246C13-2AA4-4E6E-8F31-1060D4A2BCBD 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 iQIcBAEBCgAGBQJZ/6NbAAoJEAYZmwZ/PsbKIkYP/iBsKECi918QnFSeQ0MF5aao Y2AXjCpKK3athhf1DeQVp5z/e1CGQOb9HK5f0R5CEkmdwsnc1wOHJvAe6wsHbB8F K7dfBC4r8ZXBhgmJMf4UpWBWlfA2qGRWGdARcCegwJz0oc2PJmGRhHZKuEDFxbTy G0Xqw9h0v6Bwti5FB9Lp+/P3afR+3bsO6suewzVe/LhcKY/epFhPpV+/eqxlJ9xC +AfC8VMuuMoJidhP+0MLtkNCcEXq/p0NQdtFImSChi3I7vt8bgDCF6oBezrmJ0gm AibvnT7TmjyAiN3GNskchs79z2CZfbTbzHmBiPtovJ4qS0RVQ4UAnubwtQ5PuUYN JJkrn8cUIhLjZiBV163vrBYlgtqzFn5VThuSth+Rw78h2yVZFsu+PGbA3NbjfKeE m2fuyWXHhuqf8d0SsP+35V4GSbffuzwlMkuAt7DxxCCm+UE6KoUbDOGsC9lmdPnh LIEWeS6rfFNBjJ6+ykBtNbk+xF/u8mf2o5eknCwudvXK59Ji/G0ZrFKwtS3tHHlQ sNLk3drl7dW5kpeRORF0zGNikWOFGShxFf7az0t+L+qhYOrtFTYRK7eJS5INhYaB RjiOGailZ6FDNuH5Q9z3ztLqd7d8EKfPlF0HnSKohRV9cTuZObNYzJ9DeU5oZId8 jj28vQxUsQ84Az329wH/ =702e -----END PGP SIGNATURE----- --Apple-Mail=_FB246C13-2AA4-4E6E-8F31-1060D4A2BCBD--