From: Christian Decker <decker.christian@gmail.com>
To: Patrick Strateman <patrick.strateman@gmail.com>,
bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Version bits proposal
Date: Thu, 28 May 2015 07:51:39 +0000 [thread overview]
Message-ID: <CALxbBHU3hT7+zOddryE0aW7otmE0OfQWi8WmFuhR_XZRK2VRNQ@mail.gmail.com> (raw)
In-Reply-To: <556669C4.50406@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 2967 bytes --]
next prev parent reply other threads:[~2015-05-28 7:51 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 [this message]
2015-05-28 8:11 ` Adam Back
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=CALxbBHU3hT7+zOddryE0aW7otmE0OfQWi8WmFuhR_XZRK2VRNQ@mail.gmail.com \
--to=decker.christian@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=patrick.strateman@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