summaryrefslogtreecommitdiff
path: root/fc/0b36b6c6be080c7c07493eeb8fdace4d269122
blob: cb0fd24b2f0f3ebec957c486f6f746a2bac1837c (plain)
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
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 5219A267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Aug 2015 19:18:58 +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 9119C1A0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Aug 2015 19:18:56 +0000 (UTC)
Received: from localhost ([::1]:33290 helo=server47.web-hosting.com)
	by server47.web-hosting.com with esmtpa (Exim 4.85)
	(envelope-from <jl2012@xbt.hk>)
	id 1ZO9du-001je6-SO; Sat, 08 Aug 2015 15:18:54 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 08 Aug 2015 15:18:54 -0400
From: jl2012@xbt.hk
To: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAOG=w-twsTpVKzycPt_ZEFKzjnnTX1n83vdXcyxWsx11gSH5Tw@mail.gmail.com>
References: <bcebe52e7f66f2065d48e089d773156b@xbt.hk>
	<CAOG=w-twsTpVKzycPt_ZEFKzjnnTX1n83vdXcyxWsx11gSH5Tw@mail.gmail.com>
Message-ID: <44dcb2c03d0bc344ca7a32ee0ddf1f8d@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] The use of tx version field in BIP62 and 68
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: Sat, 08 Aug 2015 19:18:58 -0000

I think I have explained my motivation but let me try to make it 
clearer.

For example, BIP62 says "scriptPubKey evaluation will be required to 
result in a single non-zero value". If we had BIP62 before BIP16, P2SH 
could not be done in the current form because BIP16 leaves more than one 
element on the stake for non-upgrading nodes. BIP17 also violates BIP62.

BIP68 is "only enforced if the most significant bit of the sequence 
number field is set.", so it is optional, anyway. All I do is to move 
the flag from sequence number to version number.

The blocksize debate shows how a permanent softfork may cause trouble 
later. We need to be very careful when doing further softforks, making 
sure we will have enough flexibility for further development.

Mark Friedenbach 於 2015-08-08 14:56 寫到:
> It is not a bug that you are unable to selectively choose these
> features with higher version numbers. The version selection is in
> there at all because there is a possibility that there exists already
> signed transactions which would violate these new rules. We wouldn't
> want these transactions to become unspendable. However moving forward
> there is no reason to selectively pick and choose which of these new
> consensus rules you want to apply your transaction.
> On Aug 8, 2015 11:51 AM, "jl2012 via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> BIP68 rules and some of the BIP62 rules are applied only if the tx
>> version is >=2 and >=3 respectively. Therefore, it is not possible
>> to create a tx which follows BIP62 but not BIP68. If we introduce v4
>> tx later, BIP62 and BIP68 will all become mandatory.
>> 
>> Some rules, e.g. "scriptPubKey evaluation will be required to
>> result in a single non-zero value" in BIP62, will cause trouble when
>> we try to introduce a new script system with softfork.
>> 
>> I suggest to divide the tx version field into 2 parts: the higher 4
>> bits and lower 28 bits.
>> 
>> BIP62 is active for a tx if its highest bits are 0000, and the
>> second lowest bit is 1.
>> 
>> BIP68 is active for a tx if its highest bits are 0000, and the
>> third lowest bit is 1.
>> 
>> So it will be easier for us to re-purpose the nSequence, or to take
>> advantage of malleability in the future. If this is adopted, the
>> nSequence high bit requirement in BIP68 becomes unnecessary as we
>> could easily switch it off.
>> 
>> The low bits will allow 28 independent BIPs and should be ample for
>> many years. When they are exhausted, we can switch the high bits to
>> a different number (1-15) and redefine the meaning of low bits. By
>> that time, some of the 28 BIPs might have become obsoleted or could
>> be merged.
>> 
>> (I'm not sure if there are other draft BIPs with similar
>> interpretation of tx version but the comments above should also
>> apply to them)
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
> 
> 
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev