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.christ...@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.strate...@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 > ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
