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