From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Thu, 9 Nov 2017 22:01:10 +0100
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>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Jacob Eliosoff <jacob.eliosoff@gmail.com>,
	Mats Jerratsch <mats@blockchain.com>
In-Reply-To: <CAAUaCyjVxJbPrbBUdb9irK5CNnuqUSnzSjywpozhLqONcb_m_w@mail.gmail.com>
Message-Id: <45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard
	Forks
Precedence: list


--Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> Op 9 nov. 2017, om 21:45 heeft Jacob Eliosoff via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> As I understand you, a private key in cold storage would (of course) =
remain valid across HFs, but an address would be valid only for the =
nForkId it was generated for.  There may be cold-storage-type cases =
where it's important for an address to be valid across all chains, ie, =
to intentionally allow replay?  But I guess this could just be a special =
nForkId value, say -1?

If I understand the proposal correctly, you can always spend coins; it's =
the next transaction that is replay protected.

I like the idea of specifying the fork in bech32 [0]. On the other hand, =
the standard already has a human readable part. Perhaps the human =
readable part can be used as the fork id?

Note that in your currently proposal nForkId is only in the transaction =
signature pre-image. It's not in the serialized transaction, so a node =
would just have to try to see if the signature is valid. I don't know if =
that's a problem.

Can you clarify what you mean with:
> 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.

What's the purpose of nForkId 1?

>  potentially a way to opt-out of replay protection of any fork, where =
deemed necessary (can be beneficial for some L2 applications).

Can you give an example of where this opt-out would be useful? Why =
wouldn't it be enough to just sign one transaction for each fork?

In Spoonnet, the version number is added to the SIGHASH_TYPE in the =
pre-image. Your solution of just adding another field seems easier, but =
maybe there's a downside?

Sjors

[0] =
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32

--Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85
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-----

iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAloEwhYACgkQV/+b28ww
EAl23BAAwO4AVIi6bHwtbxfM9MHSGWr/YL1hH+N29cuaCBz4vIRhTgvb86bQTnJy
MiuiKGV8GjYZ2iIrLUTfhUBTdPzLgG8QVtzXvfMMUYeU/t1oOGBfh3Ui3vatNLyn
Wzf8GeklD+K5NMmsC8ZiYrBubFOh/wqYPAKZY9J5qoA3VH1DN/OukfO+KYBUaONe
2WS6sPzNxUmvF00v1/FYrLFuY8cfB2gU7vyL5JFpTnPH22PMQylIUowzstfvMvTC
tkB0rB521u7wdJbXl+Drs/ST3jHwQSl3QzZp7rnHGXWcbANmuT+iQVDXhdt0vl3b
I+1gBep5XTzAmwwkFU3riqu7UcMm0V2BP8FYyLKOxAx0+l6ZI/+SHUuZzws3CuPA
CEFCpUGQz6a+XNRz/j+lDapJ7pliB20TbX5lrmla12buLe5xWXVW+mKla3hhG2eX
kAN/h43EeOucQ7D7xIjX9iK0Ws7/Nu2e1brJFcHfnn1z44Nn4+O+oYO3K4o4PXOT
YnIhErphmLyl9BTF8gyZ+4sXftnSHZRbxO2+EpikfmxQDKSSXNr2UjrT/1BTq7kP
NdOJf3eOJAkVujTfsj9jIssemWHj2voCmt7+YouQh4N8jLN3r1Jr0dfpSb+IuPui
Tsr27JTGUR4a0ggzXcUCzPmB6dvyVBMWhL9P0flHG9wuESunMOI=
=pJ6W
-----END PGP SIGNATURE-----

--Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85--