[Bitcoin-ml] What i would like to see in the next HF + timeline

[Amaury Séchet]

Yes we should reserve a space for a UTXO set commitment. Right now there is
a ton of research done in cryptographic data structure for such a role and
they all fall short in some way. For instance, ECMH can be updated with
each block easily, but cannot be used to generate proof that an element is
in the set and makes weaker cryptographic assumption than the rest of the
blocks make. Structures such as Merklix tries or patricia tries have poor
cache locality when updating them (this is the #1 problem to scale ETH ,
the state root is a patricia trie) which cause poor performance once they
do not fit in memory anymore. There is active research in the area of
cryptographic accumulators that seems promising, but still they all come
with different tradeof.

You also want to make sure that miner can mine right away once they got the
previous block header, so hashrate is not lost.

Considering we are aiming for scale with Bitcoin Cash, I would go for
something like ECMH , and make it optional if the block is fairly small,
which give time to the node to recompute the set while mining has started
and not having the commitment for small blocks is not a big deal anyway,
because it is easy to bootstrap from an earlier commitment and then a few
small blocks can be synced cheaply.

But considering the shortcoming of ECMH, or other techniques, we probably
want to include these in a way that ensure the technique used can be
updated in the future without an emergency upgrade to the whole system.
This is not clear how that is achieved at this point in time.

As a result, I would just reserve a space for it in the tree for now, and
not check the value at this point in time (or maybe validate it is 0, but
accept other value if enough PoW piles up on top of it ? Not sure.)




2017-08-30 22:17 GMT+02:00 Chris Pacia via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org>:

> Apologies for a new thread for this topic, just subscribed.
>
> I think restructuring the merkle root the way deadalnix described would
> be a pretty big win. Along those same lines I would look into committing
> the UTXO set as well. This is something that would likely be necessary
> for any sharding scheme later on but in the interim it would enable a
> fast sync from checkpoint and would eliminate sync time as one of the
> major criticisms of larger blocks.
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170831/7f61a30a/attachment.html>