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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1YxsuX-0000qd-WB
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 08:11:30 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.197])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YxsuW-00085a-Ha
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 08:11:29 +0000
Received: from mail-qk0-f174.google.com ([209.85.220.174]) by
mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id
0MhT1A-1Yk5Q82Ho2-00MYXW for
<bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 10:11:22 +0200
Received: by qkx62 with SMTP id 62so20367562qkx.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 01:11:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.102.73 with SMTP id f9mr1769681qco.19.1432800681966;
Thu, 28 May 2015 01:11:21 -0700 (PDT)
Received: by 10.96.112.164 with HTTP; Thu, 28 May 2015 01:11:21 -0700 (PDT)
In-Reply-To: <CALxbBHU3hT7+zOddryE0aW7otmE0OfQWi8WmFuhR_XZRK2VRNQ@mail.gmail.com>
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>
<CALxbBHU3hT7+zOddryE0aW7otmE0OfQWi8WmFuhR_XZRK2VRNQ@mail.gmail.com>
Date: Thu, 28 May 2015 09:11:21 +0100
Message-ID: <CALqxMTEc4K_YQo8aU1RwgJYasPs=bR8ORux8pyp0XDMTmNqNAg@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:5rBx9MFrD9+qwUdE3o8MYagHJMgMv+/oZxY+rA3vBMVKj8yhCZd
VUSwOTpi/cX+64keT5x3RH/hOSUJVXZNzoboX9HllSRFkYaT65/XPLYj7SQjL4XvNE4BH/6
Zwy4ak23fEy8PBvwxq0pBlZcg5hPyL26wtiKTMbNF0S09GLDkT/XR+y+XDhyF8ZbEolz3vy
6p6VEFs5EQ0gLX4tXbEvg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:R5I9iT/9kmE=:lxidSLR/i3+QZzlpIp9MKi
Zc5DYHIM+CfQnoD6a8WxG5mvyhqcpB1VNqiuactEcqWTEh24NmkD/LVuua/RN+7DIP47zpyyK
qnKeeRxn0tjyoYI1CEevVV2aHjf3GYf7QqcegkTcqjAFbQAe9aznzg3Qjd85vE+SmgEO3P/o7
bU1uEyNvRfagHxLMOggN0FJ4JSFWfXzNWp7ZSdVY8z/1AlcMnJ+HieT8QDdfJHUFwMoeXHWLm
1k9wRTDsk97C73Ce6SC2h/yz6LwPDj5k2Sr4++IXNC8m8+Pq9r7duYNVKidKpdYiYLMo3Z7Ah
345qJYx2iM2hrQvcfKVq/HF5Pdz0pY6sQuiudFEob/5dH9c71qPfhR+hqPBWOab0pznXVHMJb
9IvB3qpnqZOPfsgN555x7Y+ua8BIHXDpjXC5ljJKBGG3lK3Ah61cLSz4k7O9pE18lsXyPwHE1
MT2rQLlGsuPi4Da05LSNnh/PF6kKYimFUbMMVh1ufNL/i/S+5s1Lu6+fOiXPT0B/ckVSdZpDi
IqKnKTf2alJfbWGM2SxsoIdsAU+ksmkudfDhdKOxpqVcBGyqIfvkEo5Fw0Nww43AQl5v3q8Dm
JVJMSgBj7fUsWNovCbqP0zfv5Ac/Ic2jbH3xfVNMMmZKcZSv6rVkbZ60zpG8c9A8wL3UX+sm5
/IfSPcf5yjhFjI9Pa/kA2/Xeln5yOtP7zIawbj7WpSMWYbw==
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.197 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
X-Headers-End: 1YxsuW-00085a-Ha
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 08:11:30 -0000
Or as far as that goes, permuting (the non-dependent) transactions in
the block by permuting the internal merkle tree nodes at increasing
depths. (Dependent because transactions that depend on each other
have to come in-order; but one could eg put the n-1 of each n sequence
of in-order transactions in the left-half and unordered in the right
half.)
That makes the tree manipulations maximum depth independent, and even
transaction independent possibly - just need to know enough depth in
the tree of hashes that are permutation safe.
Adam
On 28 May 2015 at 08:51, Christian Decker <decker.christian@gmail.com> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
