MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Version bits proposal
Precedence: list

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
>