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

Chris Pacia ctpacia at gmail.com
Fri Sep 1 16:15:15 UTC 2017

On 08/30/2017 06:38 PM, Amaury Séchet wrote:
> 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.

So I'd point out that it depends on the goal you want to achieve. If the
purpose is to use the commitment for sharding later on then it's
probably necessary to do something like the patricia tree or at least
wait until scaling issues with it have been resolved. But if the goal is
simply fast sync from checkpoint then you could probably even do ECMH
without committing the hash.

I've had debates with people in the past who have argued that fast sync
offers lower security than syncing from genesis. But consider what
syncing from genesis implies... you must either:

1) Trust the developers to hardcode the correct genesis block otherwise
you could end up on a fraudulent fork.
2) Manually verify the genesis block against a known good copy.

With fast sync you must:

1) Trust the developers hardcoded the correct checkpoint block hash and
utxo set hash (64 bytes in total).
2) Manually verify the 64 bytes against a known good copy.

Very little difference between the two imo. And the benefit from fast
sync can be had without a commitment and without locking the system into
a certain commitment structure.

More information about the bitcoin-ml mailing list