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
|
Return-Path: <vincent.truong@procabiak.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E33EBAD0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 12:27:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
[209.85.213.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1ED5AAF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 12:27:28 +0000 (UTC)
Received: by igl9 with SMTP id 9so94879486igl.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Dec 2015 04:27:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=procabiak.com; s=procabiakindustries;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=7EICnuQaQHclPR7o8qxbEllA4fwrlyPdL7Ezj3f5I0U=;
b=ZFhFxYIQEs4BdMhJ2NqTRzOZVfJHxpik7c9m6EcZaWTZY+cRtX/8FCCBMrwnLTfK1H
mRXCChwdDmQMQ3DbskALERbq/5nr/3XhMZuZZp7inox9ukcidW8uARFS/AivkEpwOCsw
hG91SMfxTorFZRxS5zXnniTCpw8got0TBH52o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type;
bh=7EICnuQaQHclPR7o8qxbEllA4fwrlyPdL7Ezj3f5I0U=;
b=CxKygPww65CN1oej5jwPUG43R6PfG6X3xbAqMY0EBC9Veo1QKGly+ffMDNPHDmoPTs
pEhEcYvr94XdQJlHHLIoFITQbgxSb5m+GK7VwUCN/OEtm7wcMjpp2H1fQUvhS11hBeYQ
1n//+70nGkic0yJEJG2BbT6fSXPVt3uLmHSFos5oyPd5Juou84A1a2z0+r8eSuRRdjb7
hrbnvr9N1P0z5z5Sjk+YvVNyZarop7ACCBFNqKtkDKIACb+3kdpsed7KURioJa8vEK3K
kRlapLflJmgkk3lNVrlrMahAroxcm7vSHjp5nAt78ndTcgcT7BhkhRGOdfcfb050qy8o
ZDyA==
X-Gm-Message-State: ALoCoQmGNW8HKBP1b0WofFOTwUftyd1YltmlIPwE6+e3nPthplqVJCocrmS8AjU22LnIYs5aOnz4/oai62oe9o1Tm9rVORv1ZQ==
MIME-Version: 1.0
X-Received: by 10.50.33.20 with SMTP id n20mr21461231igi.17.1449577647618;
Tue, 08 Dec 2015 04:27:27 -0800 (PST)
Received: by 10.36.129.10 with HTTP; Tue, 8 Dec 2015 04:27:27 -0800 (PST)
X-Originating-IP: [14.202.127.219]
Received: by 10.36.129.10 with HTTP; Tue, 8 Dec 2015 04:27:27 -0800 (PST)
Date: Tue, 8 Dec 2015 23:27:27 +1100
Message-ID: <CACrzPenvAWdkgRG3Y7P31JiNEVRYvd+f1nMp=QRhAp5P_eGRow@mail.gmail.com>
From: Vincent Truong <vincent.truong@procabiak.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e01537a54c2d46d0526621803
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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
X-Mailman-Approved-At: Tue, 08 Dec 2015 14:27:20 +0000
Subject: [bitcoin-dev] BIP 9 style version bits for txns
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, 08 Dec 2015 12:27:29 -0000
--089e01537a54c2d46d0526621803
Content-Type: text/plain; charset=UTF-8
So I have been told more than once that the version announcement in blocks
is not a vote, but a signal for readiness, used in isSupermajority().
Basically, if soft forks (and hard forks) won't activate unless a certain %
of blocks have been flagged with the version up (or bit flipped when
versionbits go live) to signal their readiness, that is a vote against
implementation if they never follow up. I don't like this politically
correct speech because in reality it is a vote... But I'm not here to argue
about that... I would like to see if there are any thoughts on
extending/copying isSupermajority() for a new secondary/non-critical
function to also look for a similar BIP 9 style version bit in txns.
Apologies if already proposed, haven't heard of it anywhere.
If we are looking for a signal of readiness, it is unfair to wallet
developers and exchanges that they are unable to signal if they too are
ready for a change. As more users are going into use SPV or SPV-like
wallets, when a change occurs that makes them incompatible/in need of
upgrade we need to make sure they aren't going to break or introduce
security flaws for users.
If a majority of transactions have been sent are flagged ready, we know
that they're also good to go.
Would you implement the same versionbits for txn's version field, using 3
bits for versioning and 29 bits for flags? This indexing of every txn might
sound insane and computationally expensive for bitcoin Core to run, but if
it isn't critical to upgrade with soft forks, then it can be watched
outside the network by enthusiasts. I believe this is the most politically
correct way to get wallet devs and exchanges involved. (If it were me I
would absolutely try figure out a way to stick it in isSupermajority...)
Miners can watch for readiness flagged by wallets before they themselves
flag ready. We will have to trust miners to not jump the gun, but that's
the trade off.
Thoughts?
--089e01537a54c2d46d0526621803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">So I have been told more than once that the version announce=
ment in blocks is not a vote, but a signal for readiness, used in isSuperma=
jority(). Basically, if soft forks (and hard forks) won't activate unle=
ss a certain % of blocks have been flagged with the version up (or bit flip=
ped when versionbits go live) to signal their readiness, that is a vote aga=
inst implementation if they never follow up. I don't like this politica=
lly correct speech because in reality it is a vote... But I'm not here =
to argue about that... I would like to see if there are any thoughts on ext=
ending/copying isSupermajority() for a new secondary/non-critical function =
to also look for a similar BIP 9 style version bit in txns. Apologies if al=
ready proposed, haven't heard of it anywhere.</p>
<p dir=3D"ltr">If we are looking for a signal of readiness, it is unfair to=
wallet developers and exchanges that they are unable to signal if they too=
are ready for a change. As more users are going into use SPV or SPV-like w=
allets, when a change occurs that makes them incompatible/in need of upgrad=
e we need to make sure they aren't going to break or introduce security=
flaws for users.</p>
<p dir=3D"ltr">If a majority of transactions have been sent are flagged rea=
dy, we know that they're also good to go.</p>
<p dir=3D"ltr">Would you implement the same versionbits for txn's versi=
on field, using 3 bits for versioning and 29 bits for flags? This indexing =
of every txn might sound insane and computationally expensive for bitcoin C=
ore to run, but if it isn't critical to upgrade with soft forks, then i=
t can be watched outside the network by enthusiasts. I believe this is the =
most politically correct way to get wallet devs and exchanges involved. (If=
it were me I would absolutely try figure out a way to stick it in isSuperm=
ajority...)</p>
<p dir=3D"ltr">Miners can watch for readiness flagged by wallets before the=
y themselves flag ready. We will have to trust miners to not jump the gun, =
but that's the trade off.</p>
<p dir=3D"ltr">Thoughts?</p>
--089e01537a54c2d46d0526621803--
|
