1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0467DA7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Nov 2017 21:01:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3236816A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Nov 2017 21:01:15 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id E533A20B4C;
Thu, 9 Nov 2017 16:01:13 -0500 (EST)
Received: from frontend2 ([10.202.2.161])
by compute1.internal (MEProxy); Thu, 09 Nov 2017 16:01:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
content-type:date:from:in-reply-to:message-id:mime-version
:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=
fm1; bh=S4hXgGSSRIXl2TBGf0XL/+sBoBB+itLGspyBtlmaQSQ=; b=AGcGUZ6W
Os0DyHOQCWa1svPORymz3Rs8jwoo2cJ9OnCpj9fBXxeMXv8WBGmL68dmHlos/WCZ
kndKmrERkAqysCAvrlgxhQ1iAbvOipEUwiKlgpBnDDcKKridajx/+da26vvZRqhK
7LgdOmHlUp3Xp6zTKy2xKdUbEm1YfeITdg3VpGobprOmvzyPWjc+Jq8aYDfXJ9Xs
gx84HrTteZREgI3Zlc0qd+DjLHHfu0/6X0cVBgp6c3Hs7bFwQG9zuOxbVCNoQnPV
YQcekzRHK39JU2/oR3AWH/as0UaXzntaBNZAOY3DBxXm3CsXseF0tFne4hQ/FroC
vk/jfkSYSjFgWA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to:x-me-sender
:x-me-sender:x-sasl-enc; s=fm1; bh=S4hXgGSSRIXl2TBGf0XL/+sBoBB+i
tLGspyBtlmaQSQ=; b=DYIj5o9gGuccMS4FqLT2Lpo1N0PgT623k7r/WYeizHAB1
bUKUaDbd9/aWOc+2fxm/MYDbRIr/QmMDxsMiKxT48tRZ2uHptUYZ1+8ZrRD6IXVY
TW+nhpSbaC0AN9dPXm4X5uH918mLYi9eiQGt4v9p3+CJW+qLUrz+X+tGNoLUXvEs
GCuVEuRd7kN1Esn/EzX0u8DtnBL7GB3AVZm98+mgDwM4go0JUc2JmkpgDw8tYSUf
0z7R8WFI4mCKR8Zo4Hhhghq6OVlhjoPpwcSVJ9ovG2VXpBFPCiisrInDAYjvxIfU
ipLMsRgXeWJHECrH33FMrzf4CuoXDBurwRcxnUgrA==
X-ME-Sender: <xms:GcIEWiSs7Ao4Xa_NuP_nntKgHrkzNVX0OMOhj_aB-2TvqtrhrCpnfA>
Received: from [192.168.178.108] (54693d0f.cm-12-2a.dynamic.ziggo.nl
[84.105.61.15])
by mail.messagingengine.com (Postfix) with ESMTPA id 0BE0C2469F;
Thu, 9 Nov 2017 16:01:12 -0500 (EST)
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>
X-Mailer: Apple Mail (2.3445.4.7)
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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: Thu, 09 Nov 2017 21:03:34 +0000
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 <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: Thu, 09 Nov 2017 21:01:16 -0000
--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--
|
