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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8055892B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Nov 2015 05:32:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCDB7187
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Nov 2015 05:32:34 +0000 (UTC)
Received: from localhost ([::1]:52750 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZtUCg-00157i-MS; Tue, 03 Nov 2015 00:32:18 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 03 Nov 2015 00:32:18 -0500
From: jl2012@xbt.hk
To: Gavin Andresen <gavinandresen@gmail.com>
In-Reply-To: <CABsx9T3w-=bqbfmG=gVxJ8SQZCoEXA7vQbFD+kC2CH36bd=xPw@mail.gmail.com>
References: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com>
<df48a2c44441f39c71579aa5e474ec38@xbt.hk>
<CAE-z3OWJ8YvXU5aGqgs9VJnW99va=0=FoObmpHS3irg4Kh6wrQ@mail.gmail.com>
<CABsx9T3w-=bqbfmG=gVxJ8SQZCoEXA7vQbFD+kC2CH36bd=xPw@mail.gmail.com>
Message-ID: <ceb486d3be77383158b15be98bfdc11f@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Tue, 03 Nov 2015 05:32:35 -0000
The other strategy is to have an informational BIP to define "safe" use
of Bitcoin.
1. scriptPubKey must be one of the following types: P2PK, P2PKH, P2SH,
n-of-m multisig with m < 4 (with or without CLTV or CSV, we should
define standard use of CLTV and CSV)
2. For P2SH, the serialized script must be one of the standard type
3. No use of unknown transaction version
4. Tx size < 100k
5. If conditions 1-4 are all satisfied, the locktime must not be longer
than 4 years from the creation of the tx
6. If at least one of the conditions 1-4 is not satisfied, the lock time
must not be longer than 6 months from the creation of the tx
7. A chain of unconfirmed transactions is unsafe due the malleability
8. Tx created by wallet software last updated 1 year ago is unsafe
9. Permanently deleting a private key is unsafe (that might be safe if
stricter practice is followed)
We must not introduce a new rule that may permanently invalidate a safe
tx, unless in emergency. Even in emergency, we should try to preserve
backward compatibility as much as possible (see the example at the end
of my message)
Being unsafe means there is a chance that the tx may become
unconfirmable, outputs become unspendable, or funds may be stolen
without a private key.
A grace period of 5 years must be given for "soft-fork" type change of
any of the rules. For example it is ok to introduce new standard script
anytime but not to remove.
----------------------
Back to Gavin's original question. If you want to somehow keep backward
compatibility for expensive-to-validate transactions in the future, you
may have rules like there could only be at most one
expensive-to-validate transaction in every 10 blocks, until year 2025. I
know this is over-complicated but it's a possible way to address your
concern.
Gavin Andresen via bitcoin-dev 於 2015-11-02 15:33 寫到:
> On Sun, Nov 1, 2015 at 6:46 PM, Tier Nolan via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> For guidelines
>>
>> * Transaction version numbers will be increased, if possible
>>
>> * Transactions with unknown/large version numbers are unsafe to use
>> with locktime
>>
>> * Reasonable notice is given that the change is being contemplated
>>
>> * Non-opt-in changes will only be to protect the integrity of the
>> network
>>
>> Locked transaction that can be validated without excessive load on
>> the network should be safe to use, even if non-standard.
>>
>> An OP_CAT script that requires TBs of RAM to validate crosses the
>> threshold of reasonableness.
>
> I like those guidelines, although I'm sure there may be lots of
> arguing over what fits under "protects the integrity of the network"
> or what constitutes "reasonable notice" (publish a BIP at least 30
> days before rolling out a change? 60 days? a year?)
>
> --
>
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
