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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1YxsbT-0002tY-So
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 07:51:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.51 as permitted sender)
client-ip=209.85.215.51;
envelope-from=decker.christian@gmail.com;
helo=mail-la0-f51.google.com;
Received: from mail-la0-f51.google.com ([209.85.215.51])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxsbS-0007fZ-LH
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 07:51:47 +0000
Received: by labpy14 with SMTP id py14so13417232lab.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 00:51:40 -0700 (PDT)
X-Received: by 10.112.137.99 with SMTP id qh3mr1444710lbb.108.1432799500308;
Thu, 28 May 2015 00:51:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBg5TqQ=zjyZ7dp-d1oBGp31Krnix3zyt9suP4-AGbxW=Q@mail.gmail.com>
<201505270346.17014.luke@dashjr.org>
<CABm2gDoriDaQ1AjRDFxCT9zCNPQakJd9xRxfWkOJBf4v22hndQ@mail.gmail.com>
<CAE-z3OVAKyppLVEWR=qNX-_p5yVAj_0Y7Kw76o4qaywf2DKtVw@mail.gmail.com>
<20150527101516.GB25814@savin.petertodd.org>
<CAE-z3OVskd1JAE5g-WW2eDiPcxysYhbv-NsOYu7yKZvzu88VSg@mail.gmail.com>
<55664AA2.7020206@certimix.com> <556669C4.50406@gmail.com>
In-Reply-To: <556669C4.50406@gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Thu, 28 May 2015 07:51:39 +0000
Message-ID: <CALxbBHU3hT7+zOddryE0aW7otmE0OfQWi8WmFuhR_XZRK2VRNQ@mail.gmail.com>
To: Patrick Strateman <patrick.strateman@gmail.com>,
bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e0118279c401a5105171fa189
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(decker.christian[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YxsbS-0007fZ-LH
Subject: Re: [Bitcoin-development] Version bits proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 07:51:49 -0000
--089e0118279c401a5105171fa189
Content-Type: text/plain; charset=UTF-8
Agreed, there is no need to misuse the version field as well. There is more
than enough variability you could roll in the merkle tree including and
excluding transactions, and the scriptSig of the coinbase transaction,
which also influences the merkle root.
I have a fundamental dislike of retroactively changing semantics, and the
version field should be used just for that: a version. I don't even
particularly like flagging support for a fork in the version field, but
since I have no better solution, count me as supporting Sipa's proposal. We
definitely need a more comfortable way of rolling out new features.
Regards,
Chris
On Thu, May 28, 2015 at 3:08 AM Patrick Strateman <
patrick.strateman@gmail.com> wrote:
> There is absolutely no reason to do this.
>
> Any reasonable micro-controller can build merkle tree roots
> significantly faster than is necessary.
>
> 1 Th/s walks the nonce range once every 4.3ms.
>
> The largest valid merkle trees are 14 nodes high.
>
> That translates to 28 SHA256 ops per 4.3ms or 6511 SHA256 ops/second.
>
> For reference an RPi 1 model B does 2451050 SHA256 ops/second.
>
> On 05/27/2015 03:52 PM, Sergio Lerner wrote:
> > I like the idea but I think we should leave at least 16 bits of the
> > version fixed as an extra-nonce.
> > If we don't then miners may use them as a nonce anyway, and mess with
> > the soft-fork voting system.
> > My original proposal was this:
> https://github.com/bitcoin/bitcoin/pull/5102
> >
> > Best regards
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--089e0118279c401a5105171fa189
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Agreed, there is no need to misuse the version field as we=
ll. There is more than enough variability you could roll in the merkle tree=
including and excluding transactions, and the scriptSig of the coinbase tr=
ansaction, which also influences the merkle root.<br><div><br></div><div>I =
have a fundamental dislike of retroactively changing semantics, and the ver=
sion field should be used just for that: a version. I don't even partic=
ularly like flagging support for a fork in the version field, but since I h=
ave no better solution, count me as supporting Sipa's proposal. We defi=
nitely need a more comfortable way of rolling out new features.</div><div><=
br></div><div>Regards,</div><div>Chris</div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr">On Thu, May 28, 2015 at 3:08 AM Patrick Strateman &l=
t;<a href=3D"mailto:patrick.strateman@gmail.com">patrick.strateman@gmail.co=
m</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is absolutel=
y no reason to do this.<br>
<br>
Any reasonable micro-controller can build merkle tree roots<br>
significantly faster than is necessary.<br>
<br>
1 Th/s walks the nonce range once every 4.3ms.<br>
<br>
The largest valid merkle trees are 14 nodes high.<br>
<br>
That translates to 28 SHA256 ops per 4.3ms or 6511 SHA256 ops/second.<br>
<br>
For reference an RPi 1 model B does 2451050 SHA256 ops/second.<br>
<br>
On 05/27/2015 03:52 PM, Sergio Lerner wrote:<br>
> I like the idea but I think we should leave at least 16 bits of the<br=
>
> version fixed as an extra-nonce.<br>
> If we don't then miners may use them as a nonce anyway, and mess w=
ith<br>
> the soft-fork voting system.<br>
> My original proposal was this: <a href=3D"https://github.com/bitcoin/b=
itcoin/pull/5102" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull=
/5102</a><br>
><br>
> Best regards<br>
><br>
><br>
> ----------------------------------------------------------------------=
--------<br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D=
"_blank">Bitcoin-development@lists.sourceforge.net</a><br>
> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>
--089e0118279c401a5105171fa189--
|
