public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Christian Decker <decker.christian@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Version bits proposal
Date: Thu, 28 May 2015 09:11:21 +0100	[thread overview]
Message-ID: <CALqxMTEc4K_YQo8aU1RwgJYasPs=bR8ORux8pyp0XDMTmNqNAg@mail.gmail.com> (raw)
In-Reply-To: <CALxbBHU3hT7+zOddryE0aW7otmE0OfQWi8WmFuhR_XZRK2VRNQ@mail.gmail.com>

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
>



  reply	other threads:[~2015-05-28  8:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27  1:48 [Bitcoin-development] Version bits proposal Pieter Wuille
2015-05-27  2:31 ` Douglas Roark
2015-05-27  3:46 ` Luke Dashjr
2015-05-27  3:51   ` Jorge Timón
2015-05-27  9:35     ` Tier Nolan
2015-05-27 10:15       ` Peter Todd
2015-05-27 11:26         ` Tier Nolan
2015-05-27 22:52           ` Sergio Lerner
2015-05-28  1:05             ` Patrick Strateman
2015-05-28  7:51               ` Christian Decker
2015-05-28  8:11                 ` Adam Back [this message]
2015-06-01 14:50           ` Potter QQ
2015-05-27 10:15       ` Jorge Timón
2015-06-03 20:42 ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALqxMTEc4K_YQo8aU1RwgJYasPs=bR8ORux8pyp0XDMTmNqNAg@mail.gmail.com' \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=decker.christian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox