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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E95928A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Oct 2015 14:06:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com
[209.85.215.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 223F679
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Oct 2015 14:06:24 +0000 (UTC)
Received: by lffz202 with SMTP id z202so4223747lff.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Oct 2015 07:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=l/I54WJXUsnlVfjwwF4vzI73FFhFIyaAZ1kp0pa7NK0=;
b=d4A0M9esKiAGTX1PM6spBNTdoLS4bIBLqUWbk1q810vCDZ3xubkd1EwvgzzynFzVlZ
xUiAHpiiKJ9JUqo7PEmd6voooPOrLX7/IIUwyiUi5DUViZJw9U7UpPoWZjq9md41GQD7
OorjddU1aVrx4XtpiAflg1CNBf+s6N47UC+BcC5yLLRaqOFKBF8boT0pXIVJnBuI3dW5
x0J0lHBFFDS+V/gqYaG6Pyyxt+f/Fiw0tIYEQPoRSURMwgIZG+Y0M7DckG6ZpdYeqtpX
RFXh+QdjgicjfEE+ihNc/xL31whwOtegZH/Exfbcj0qlJneshEkxtPD8XA9F8RAE44Xt
3oPg==
MIME-Version: 1.0
X-Received: by 10.25.13.74 with SMTP id 71mr7833560lfn.113.1446041182258; Wed,
28 Oct 2015 07:06:22 -0700 (PDT)
Received: by 10.25.22.146 with HTTP; Wed, 28 Oct 2015 07:06:22 -0700 (PDT)
Date: Wed, 28 Oct 2015 10:06:22 -0400
Message-ID: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113eaaa4ffd24505232ab290
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Compatibility requirements for hard or soft forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 28 Oct 2015 14:06:25 -0000
--001a113eaaa4ffd24505232ab290
Content-Type: text/plain; charset=UTF-8
I'm hoping this fits under the moderation rule of "short-term changes to
the Bitcoin protcol" (I'm not exactly clear on what is meant by
"short-term"; it would be lovely if the moderators would start a thread on
bitcoin-discuss to clarify that):
Should it be a requirement that ANY one-megabyte transaction that is valid
under the existing rules also be valid under new rules?
Pro: There could be expensive-to-validate transactions created and given a
lockTime in the future stored somewhere safe. Their owners may have no
other way of spending the funds (they might have thrown away the private
keys), and changing validation rules to be more strict so that those
transactions are invalid would be an unacceptable confiscation of funds.
Con: It is extremely unlikely there are any such large, timelocked
transactions, because the Core code has had a clear policy for years that
100,000-byte transactions are "standard" and are relayed and
mined, and
larger transactions are not. The requirement should be relaxed so that only
valid 100,000-byte transaction under old consensus rules must be valid
under new consensus rules (larger transactions may or may not be valid).
I had to wrestle with that question when I implemented BIP101/Bitcoin XT
when deciding on a limit for signature hashing (and decided the right
answer was to support any "non-attack"1MB transaction; see
https://bitcoincore.org/~gavin/ValidationSanity.pdf for more details).
--
--
Gavin Andresen
--001a113eaaa4ffd24505232ab290
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm hoping this fits under the moderation rule of &quo=
t;short-term changes to the Bitcoin protcol" (I'm not exactly clea=
r on what is meant by "short-term"; it would be lovely if the mod=
erators would start a thread on bitcoin-discuss to clarify that):<div><br><=
br>Should it be a requirement that ANY one-megabyte transaction that is val=
id<br>under the existing rules also be valid under new rules?<br><br>Pro: =
=C2=A0There could be expensive-to-validate transactions created and given a=
<br>lockTime in the future stored somewhere safe. Their owners may have no<=
br>other way of spending the funds (they might have thrown away the private=
<br>keys), and changing validation rules to be more strict so that those<br=
>transactions are invalid would be an unacceptable confiscation of funds.<b=
r><br>Con: It is extremely unlikely there are any such large, timelocked<br=
>transactions, because the Core code has had a clear policy for years that<=
br>100,000-byte transactions are &quot;standard&quot; and are relay=
ed and mined, and<br>larger transactions are not. The requirement should be=
relaxed so that only<br>valid 100,000-byte transaction under old consensus=
rules must be valid<br>under new consensus rules (larger transactions may =
or may not be valid).<br><br><br>I had to wrestle with that question when I=
implemented BIP101/Bitcoin XT<br>when deciding on a limit for signature ha=
shing (and decided the right<br>answer was to support any "non-attack&=
quot;1MB transaction; see<br><a href=3D"https://bitcoincore.org/~gavin/Vali=
dationSanity.pdf">https://bitcoincore.org/~gavin/ValidationSanity.pdf</a> f=
or more details).<br><br>-- <br><div class=3D"gmail_signature">--<br>Gavin =
Andresen<br></div>
</div></div>
--001a113eaaa4ffd24505232ab290--
|
