From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ABD6340D for ; Sat, 10 Dec 2016 21:42:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2C73E15C for ; Sat, 10 Dec 2016 21:42:44 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id C37AA38AB7A1; Sat, 10 Dec 2016 21:42:01 +0000 (UTC) X-Hashcash: 1:25:161210:bitcoin-dev@lists.linuxfoundation.org::=Y/HI5xHPdPI0iV9:cULiU X-Hashcash: 1:25:161210:tier.nolan@gmail.com::mPaqze257Z9qU8d4:a=MkA From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Tier Nolan Date: Sat, 10 Dec 2016 21:41:57 +0000 User-Agent: KMail/1.13.7 (Linux/4.4.36-gentoo-r1; KDE/4.14.24; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201612102141.58206.luke@dashjr.org> X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 21:42:44 -0000 On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote: > On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Something not yet done: > > 1. The new merkle root algorithm described in the MMHF BIP > > Any new merkle algorithm should use a sum tree for partial validation and > fraud proofs. PR welcome. > Is there something special about 216 bits? I guess at most 448 bits total > means only one round of SHA256. 16 bits for flags would give 216 for each > child. See https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki#Merkle_tree_algorithm But yes, the 448 bits total target is to optimise the tree-building. > Even better would be to make the protocol extendable. Allow blocks to > indicate new trees and legacy nodes would just ignore the extra ones. If > Bitcoin supported that then the segregated witness tree could have been > added as a easier soft fork. It already is. This is a primary goal of the new protocol. > The sum-tree could be added later as an extra tree. Adding new trees means more hashing to validate blocks, so it'd be better to keep it at a minimum. Luke