Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2016-12-10 📝 Original message:On Saturday, December 10, ...
📅 Original date posted:2016-12-10
📝 Original message: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 at 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
📝 Original message: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 at 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