From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxsbT-0002tY-So for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 07:51:49 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.51 as permitted sender) client-ip=209.85.215.51; envelope-from=decker.christian@gmail.com; helo=mail-la0-f51.google.com; Received: from mail-la0-f51.google.com ([209.85.215.51]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxsbS-0007fZ-LH for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 07:51:47 +0000 Received: by labpy14 with SMTP id py14so13417232lab.0 for ; Thu, 28 May 2015 00:51:40 -0700 (PDT) X-Received: by 10.112.137.99 with SMTP id qh3mr1444710lbb.108.1432799500308; Thu, 28 May 2015 00:51:40 -0700 (PDT) MIME-Version: 1.0 References: <201505270346.17014.luke@dashjr.org> <20150527101516.GB25814@savin.petertodd.org> <55664AA2.7020206@certimix.com> <556669C4.50406@gmail.com> In-Reply-To: <556669C4.50406@gmail.com> From: Christian Decker Date: Thu, 28 May 2015 07:51:39 +0000 Message-ID: To: Patrick Strateman , bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=089e0118279c401a5105171fa189 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YxsbS-0007fZ-LH Subject: Re: [Bitcoin-development] Version bits proposal X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 07:51:49 -0000 --089e0118279c401a5105171fa189 Content-Type: text/plain; charset=UTF-8 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 > --089e0118279c401a5105171fa189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, there is no need to misuse the version field as we= ll. There is more than enough variability you could roll in the merkle tree= including and excluding transactions, and the scriptSig of the coinbase tr= ansaction, which also influences the merkle root.

I = have a fundamental dislike of retroactively changing semantics, and the ver= sion field should be used just for that: a version. I don't even partic= ularly like flagging support for a fork in the version field, but since I h= ave no better solution, count me as supporting Sipa's proposal. We defi= nitely need a more comfortable way of rolling out new features.
<= br>
Regards,
Chris

On Thu, May 28, 2015 at 3:08 AM Patrick Strateman &l= t;patrick.strateman@gmail.co= m> wrote:
There is absolutel= y 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 w= ith
> 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/bitco= in-development



---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--089e0118279c401a5105171fa189--