path: root/ec/36d6ae340648c00a33494ffd888de7044c094e

Return-Path: <mats@blockchain.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 387278F5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  5 Nov 2017 23:48:47 +0000 (UTC)
Received: by mail-wm0-f66.google.com with SMTP id s66so10482236wmf.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 05 Nov 2017 15:48:45 -0800 (PST)
From: Mats Jerratsch <mats@blockchain.com>
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 <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: 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 =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013=
542.html>
[2]
=
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-e=
ncoding.md =
<https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-=
encoding.md>

--Apple-Mail=_60E21DC9-B230-429F-A3BC-54B3500AA09D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D"">
<div class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; =
margin-bottom: 0pt;"><span class=3D"" style=3D"font-size: 11pt; =
font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">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).</span></div><br class=3D""><div class=3D"" =
style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;"><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;">## Rationale</span></div><br class=3D""><div class=3D"" =
style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;"><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;">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.</span></div><br class=3D""><div class=3D"" =
style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;"><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;">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. </span></div><br =
class=3D""><div class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; =
margin-bottom: 0pt;"><span class=3D"" style=3D"font-size: 11pt; =
font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">## Iterative =
Forks</span></div><br class=3D""><div class=3D"" style=3D"line-height: =
1.38; margin-top: 0pt; margin-bottom: 0pt;"><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">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.</span></div><br class=3D""><div class=3D"" =
style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;"><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;">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</span></div><br =
class=3D""><div class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; =
margin-bottom: 0pt;"><span class=3D"" style=3D"font-size: 11pt; =
font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">```</span></div><div =
class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: =
0pt;"><span class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"> Double SHA256 of the serialization of:</span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"><br =
class=3D"kix-line-break"></span><span class=3D"" style=3D"font-size: =
11pt; font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;1. nVersion of the transaction (4-byte little =
endian)</span><span class=3D"" style=3D"font-size: 11pt; font-family: =
Arial; font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><br class=3D"kix-line-break"></span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;2. hashPrevouts (32-byte hash)</span><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><br class=3D"kix-line-break"></span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;3. hashSequence (32-byte hash)</span><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><br class=3D"kix-line-break"></span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;4. outpoint (32-byte hash + 4-byte little =
endian) </span><span class=3D"" style=3D"font-size: 11pt; font-family: =
Arial; font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><br class=3D"kix-line-break"></span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;5. scriptCode of the input (serialized as =
scripts inside CTxOuts)</span><span class=3D"" style=3D"font-size: 11pt; =
font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"><br =
class=3D"kix-line-break"></span><span class=3D"" style=3D"font-size: =
11pt; font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;6. value of the output spent by this input =
(8-byte little endian)</span><span class=3D"" style=3D"font-size: 11pt; =
font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"><br =
class=3D"kix-line-break"></span><span class=3D"" style=3D"font-size: =
11pt; font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;7. nSequence of the input (4-byte little =
endian)</span><span class=3D"" style=3D"font-size: 11pt; font-family: =
Arial; font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><br class=3D"kix-line-break"></span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;8. hashOutputs (32-byte hash)</span><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><br class=3D"kix-line-break"></span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> =
&nbsp;&nbsp;&nbsp;&nbsp;9. nLocktime of the transaction (4-byte little =
endian)</span><span class=3D"" style=3D"font-size: 11pt; font-family: =
Arial; font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><br class=3D"kix-line-break"></span><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;10. =
sighash type of the signature (4-byte little endian)</span></div><div =
class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: =
0pt;"><span class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"> &nbsp;&nbsp;&nbsp;</span><span class=3D"" style=3D"font-size: =
11pt; font-family: Arial; font-style: italic; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">11. nForkId (4-byte =
little endian)</span></div><div class=3D"" style=3D"line-height: 1.38; =
margin-top: 0pt; margin-bottom: 0pt;"><span class=3D"" style=3D"font-size:=
 11pt; font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">```</span></div><br =
class=3D""><br class=3D""><div class=3D"" style=3D"line-height: 1.38; =
margin-top: 0pt; margin-bottom: 0pt;"><span class=3D"" style=3D"font-size:=
 11pt; font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">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. =
</span></div><br class=3D""><div class=3D"" style=3D"line-height: 1.38; =
margin-top: 0pt; margin-bottom: 0pt;"><span class=3D"" style=3D"font-size:=
 11pt; font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">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. </span></div><br =
class=3D""><div class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; =
margin-bottom: 0pt;"><span class=3D"" style=3D"font-size: 11pt; =
font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">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. </span></div><br =
class=3D""><div class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; =
margin-bottom: 0pt;"><span class=3D"" style=3D"font-size: 11pt; =
font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">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. </span></div><br class=3D""><div class=3D"" style=3D"line-height: =
1.38; margin-top: 0pt; margin-bottom: 0pt;"><span class=3D"" =
style=3D"font-size: 11pt; font-family: Arial; font-variant-ligatures: =
normal; font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;">[1]</span></div><div =
class=3D"" style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: =
0pt;"><span class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;"><a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Febru=
ary/013542.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Fe=
bruary/013542.html</a></span></div><br class=3D""><div class=3D"" =
style=3D"line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;"><span =
class=3D"" style=3D"font-size: 11pt; font-family: Arial; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;">[2]</span></div><div class=3D"" style=3D"line-height: 1.38; =
margin-top: 0pt; margin-bottom: 0pt;"><span class=3D"" style=3D"font-size:=
 11pt; font-family: Arial; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;"><a =
href=3D"https://github.com/lightningnetwork/lightning-rfc/blob/master/11-p=
ayment-encoding.md" =
class=3D"">https://github.com/lightningnetwork/lightning-rfc/blob/master/1=
1-payment-encoding.md</a></span></div></body></html>=

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