From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxsuX-0000qd-WB for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 08:11:30 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.197]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YxsuW-00085a-Ha for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 08:11:29 +0000 Received: from mail-qk0-f174.google.com ([209.85.220.174]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0MhT1A-1Yk5Q82Ho2-00MYXW for ; Thu, 28 May 2015 10:11:22 +0200 Received: by qkx62 with SMTP id 62so20367562qkx.3 for ; Thu, 28 May 2015 01:11:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.102.73 with SMTP id f9mr1769681qco.19.1432800681966; Thu, 28 May 2015 01:11:21 -0700 (PDT) Received: by 10.96.112.164 with HTTP; Thu, 28 May 2015 01:11:21 -0700 (PDT) In-Reply-To: References: <201505270346.17014.luke@dashjr.org> <20150527101516.GB25814@savin.petertodd.org> <55664AA2.7020206@certimix.com> <556669C4.50406@gmail.com> Date: Thu, 28 May 2015 09:11:21 +0100 Message-ID: From: Adam Back To: Christian Decker Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:5rBx9MFrD9+qwUdE3o8MYagHJMgMv+/oZxY+rA3vBMVKj8yhCZd VUSwOTpi/cX+64keT5x3RH/hOSUJVXZNzoboX9HllSRFkYaT65/XPLYj7SQjL4XvNE4BH/6 Zwy4ak23fEy8PBvwxq0pBlZcg5hPyL26wtiKTMbNF0S09GLDkT/XR+y+XDhyF8ZbEolz3vy 6p6VEFs5EQ0gLX4tXbEvg== X-UI-Out-Filterresults: notjunk:1;V01:K0:R5I9iT/9kmE=:lxidSLR/i3+QZzlpIp9MKi Zc5DYHIM+CfQnoD6a8WxG5mvyhqcpB1VNqiuactEcqWTEh24NmkD/LVuua/RN+7DIP47zpyyK qnKeeRxn0tjyoYI1CEevVV2aHjf3GYf7QqcegkTcqjAFbQAe9aznzg3Qjd85vE+SmgEO3P/o7 bU1uEyNvRfagHxLMOggN0FJ4JSFWfXzNWp7ZSdVY8z/1AlcMnJ+HieT8QDdfJHUFwMoeXHWLm 1k9wRTDsk97C73Ce6SC2h/yz6LwPDj5k2Sr4++IXNC8m8+Pq9r7duYNVKidKpdYiYLMo3Z7Ah 345qJYx2iM2hrQvcfKVq/HF5Pdz0pY6sQuiudFEob/5dH9c71qPfhR+hqPBWOab0pznXVHMJb 9IvB3qpnqZOPfsgN555x7Y+ua8BIHXDpjXC5ljJKBGG3lK3Ah61cLSz4k7O9pE18lsXyPwHE1 MT2rQLlGsuPi4Da05LSNnh/PF6kKYimFUbMMVh1ufNL/i/S+5s1Lu6+fOiXPT0B/ckVSdZpDi IqKnKTf2alJfbWGM2SxsoIdsAU+ksmkudfDhdKOxpqVcBGyqIfvkEo5Fw0Nww43AQl5v3q8Dm JVJMSgBj7fUsWNovCbqP0zfv5Ac/Ic2jbH3xfVNMMmZKcZSv6rVkbZ60zpG8c9A8wL3UX+sm5 /IfSPcf5yjhFjI9Pa/kA2/Xeln5yOtP7zIawbj7WpSMWYbw== X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.208.4.197 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record X-Headers-End: 1YxsuW-00085a-Ha Cc: Bitcoin Dev 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 08:11:30 -0000 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 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 > 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 >