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
158
159
160
161
162
163
164
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 213899C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Aug 2015 18:56:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com
[209.85.213.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 748AD1BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Aug 2015 18:56:33 +0000 (UTC)
Received: by igk11 with SMTP id 11so49378705igk.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 08 Aug 2015 11:56:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=feYxGM/pRqp0480ruYrKB23wA3/mVlKK7U2pSulBWo0=;
b=N3goBB3G+eozxeXrCQxgwm8AorKtfiEaisemz44Xe51/JRHNYwbcDiH/V3FyPWyk0C
o3HaShhkhOwmnGwuVdmfX8etdogqyT4OL+Oy/zk93onaPQs7WTFgYX9QIcvgtEqul2cp
71RxcAyCZQlx8Y7/rAT3z99GBmIvFn0WIkelBmr2ZucxZ7RR8uEUj8Mo997Ubb6Ixck9
MqbZnHpWPQrVpOUA5PFTqMrGiWq1fggYeQMudoEpZYOazGbRELNixeKv+TgDzqJA6fuq
/6Ao7c3hkfxtgVrCKzJ0w8Wv92VmCcQMuSojACovmPRpkAiwpu+/9MOlb7fvC9tkm0HN
aJ3Q==
X-Gm-Message-State: ALoCoQlr/KNjC0FtTkP0uebw7V4HSAE/iom0cvVDjuPDKfFkgoJ7AB83yMR7h+lIGhzt68PO+KXV
MIME-Version: 1.0
X-Received: by 10.50.112.229 with SMTP id it5mr4383676igb.46.1439060192897;
Sat, 08 Aug 2015 11:56:32 -0700 (PDT)
Received: by 10.107.158.140 with HTTP; Sat, 8 Aug 2015 11:56:32 -0700 (PDT)
X-Originating-IP: [172.56.17.136]
Received: by 10.107.158.140 with HTTP; Sat, 8 Aug 2015 11:56:32 -0700 (PDT)
In-Reply-To: <bcebe52e7f66f2065d48e089d773156b@xbt.hk>
References: <bcebe52e7f66f2065d48e089d773156b@xbt.hk>
Date: Sat, 8 Aug 2015 11:56:32 -0700
Message-ID: <CAOG=w-twsTpVKzycPt_ZEFKzjnnTX1n83vdXcyxWsx11gSH5Tw@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=089e0118417e9bc66c051cd14f1a
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
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 18:56:34 -0000
--089e0118417e9bc66c051cd14f1a
Content-Type: text/plain; charset=UTF-8
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
>
--089e0118417e9bc66c051cd14f1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">It is not a bug that you are unable to selectively choose th=
ese features with higher version numbers. The version selection is in there=
at all because there is a possibility that there exists already signed tra=
nsactions which would violate these new rules. We wouldn't want these t=
ransactions to become unspendable. However moving forward there is no reaso=
n to selectively pick and choose which of these new consensus rules you wan=
t to apply your transaction.</p>
<div class=3D"gmail_quote">On Aug 8, 2015 11:51 AM, "jl2012 via bitcoi=
n-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">BIP68 rules and some of the BIP62 rules are =
applied only if the tx version is >=3D2 and >=3D3 respectively. There=
fore, 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.<br>
<br>
Some rules, e.g. "scriptPubKey evaluation will be required to result i=
n a single non-zero value" in BIP62, will cause trouble when we try to=
introduce a new script system with softfork.<br>
<br>
I suggest to divide the tx version field into 2 parts: the higher 4 bits an=
d lower 28 bits.<br>
<br>
BIP62 is active for a tx if its highest bits are 0000, and the second lowes=
t bit is 1.<br>
<br>
BIP68 is active for a tx if its highest bits are 0000, and the third lowest=
bit is 1.<br>
<br>
So it will be easier for us to re-purpose the nSequence, or to take advanta=
ge of malleability in the future. If this is adopted, the nSequence high bi=
t requirement in BIP68 becomes unnecessary as we could easily switch it off=
.<br>
<br>
The low bits will allow 28 independent BIPs and should be ample for many ye=
ars. When they are exhausted, we can switch the high bits to a different nu=
mber (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.<br>
<br>
(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)<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--089e0118417e9bc66c051cd14f1a--
|
