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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5057394B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 17:42:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 87406180
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 17:42:00 +0000 (UTC)
Received: from [IPv6:2607:fb90:1f0f:c5e:8efa:6107:8cb6:b944] (unknown
[172.56.19.90])
by mail.bluematt.me (Postfix) with ESMTPSA id BCE8B136B7E;
Thu, 26 Jan 2017 17:41:57 +0000 (UTC)
Date: Thu, 26 Jan 2017 17:41:55 +0000
In-Reply-To: <CABsx9T0PcbMxjfBJZYveQayhTUb1C3YNZCEMA1T=f9mAfxHypg@mail.gmail.com>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
<93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com>
<CABsx9T0PcbMxjfBJZYveQayhTUb1C3YNZCEMA1T=f9mAfxHypg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----GXR9I0B4MGVXTLB30PGIIWH1KG5YZR"
Content-Transfer-Encoding: 7bit
To: Gavin Andresen <gavinandresen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <CC8A4B24-7620-4D61-AE93-D60C7096CFAE@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
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, 26 Jan 2017 17:42:01 -0000
------GXR9I0B4MGVXTLB30PGIIWH1KG5YZR
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Excuse me, yes, for previously-signed transactions this is required=2E We m=
ight consider some limits on UTXO-chain-from-before-the-fork-length and lik=
ely something like move towards only allowing one transaction per block fro=
m the old mode over time=2E
I highly disagree that compatibility with existing transaction signing sof=
tware should be considered (but for hardware which cannot be upgraded easil=
y we do need to consider it)=2E Wallets which can upgrade should, as much a=
s possible, upgrade to a new form to maximize chain divergence and are goin=
g to end up having to upgrade to know a new header format anyway, so am ext=
ra few lines of code to change a transaction version should be trivial=2E
On January 26, 2017 12:21:37 PM EST, Gavin Andresen <gavinandresen@gmail=
=2Ecom> wrote:
>On Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <
>bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>
>> To maximize fork divergence, it might make sense to require this=2E Any
>> sensible proposal for a hard fork would include a change to the
>sighash
>> anyway, so might as well make it required, no?
>>
>
>Compatibility with existing transaction-signing software and hardware
>should be considered=2E
>
>I think any hard fork proposal should support a reasonable number of
>reasonable-size old-sighash transactions, to allow a smooth transaction
>of
>wallet software and hardware and to support anybody who might have a
>hardware wallet locked away in a safe deposit box for years=2E
>
>--=20
>--
>Gavin Andresen
------GXR9I0B4MGVXTLB30PGIIWH1KG5YZR
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Excuse me, yes, for previously-signed transactions=
this is required=2E We might consider some limits on UTXO-chain-from-befor=
e-the-fork-length and likely something like move towards only allowing one =
transaction per block from the old mode over time=2E<br>
<br>
I highly disagree that compatibility with existing transaction signing sof=
tware should be considered (but for hardware which cannot be upgraded easil=
y we do need to consider it)=2E Wallets which can upgrade should, as much a=
s possible, upgrade to a new form to maximize chain divergence and are goin=
g to end up having to upgrade to know a new header format anyway, so am ext=
ra few lines of code to change a transaction version should be trivial=2E<b=
r><br><div class=3D"gmail_quote">On January 26, 2017 12:21:37 PM EST, Gavin=
Andresen <gavinandresen@gmail=2Ecom> wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On =
Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <span dir=3D"lt=
r"><<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=2Eorg" target=
=3D"_blank">bitcoin-dev@lists=2Elinuxfoundation=2Eorg</a>></span> wrote:=
<br /><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =2E8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div id=3D":1m6" class=3D"a3s aXjCH =
m159d8d262b0da180">To maximize fork divergence, it might make sense to requ=
ire this=2E Any<br />
sensible proposal for a hard fork would include a change to the sighash<br=
/>
anyway, so might as well make it required, no?</div></blockquote></div><br=
/>Compatibility with existing transaction-signing software and hardware sh=
ould be considered=2E</div><div class=3D"gmail_extra"><br /></div><div clas=
s=3D"gmail_extra">I think any hard fork proposal should support a reasonabl=
e number of reasonable-size old-sighash transactions, to allow a smooth tra=
nsaction of wallet software and hardware and to support anybody who might h=
ave a hardware wallet locked away in a safe deposit box for years=2E</div><=
div class=3D"gmail_extra"><div><br /></div>-- <br /><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr"><div dir=3D"ltr"><div>--<br />Gavin Andresen<br /></div><div><br /=
></div></div></div></div></div></div>
</div></div>
</blockquote></div></body></html>
------GXR9I0B4MGVXTLB30PGIIWH1KG5YZR--
|
