[Bitcoin-ml] On the security of fast syncing the UTXO set

[Jared Lee Richardson]

Nailed it.  Completely agree.

Also, a UTXO model that allowed the fast sync user to select how far back
in time they wished to sync to and then full sync from there would be for
all practical purposes trusts and completely protected by the proof of work
system.

Jared

On Mar 1, 2018 5:55 AM, "Tomas via bitcoin-ml" <
bitcoin-ml at lists.linuxfoundation.org> wrote:

> With a UTXO commitment it becomes possible to synchronize a full node
> using only a few GB.
>
> Some seem to think that such a fast-sync is useful for full nodes that do
> not need to "fully validate history", providing an optional "compromise"
> between trust and download requirements. After all they would need to trust
> the commitment?
>
> This is incorrect. A UTXO commitment makes syncing from genesis completely
> obsolete, save for historians. Fast sync doesn't change the trust model.
>
> I will explain in two steps, and follow with a rather bold claim.
>
> First of all, current full nodes use a hardcoded "assumevalid=X" block by
> default. Any ancestor of this is assumed valid and signatures aren't
> verified. This means that the *only* reason for such default full node to
> download old blocks is to generate the UTXO set. With a UTXO commitment it
> can do so in 2GB without additional trust.
>
> Next, you could doubt "assumevalid". Surely if you really want to "fully
> validate" you should set "assumevalid=0" to start from the beginning?
>
> Not really. Assumevalid=X does not prescribe which chain or blocks to use.
> This is determined by accumulated work; "Assumevalid=X" is included in the
> source code  *only* to state that all parents of X pass the validity checks
> of *that very piece of source code*. It is akin to a "compile time"
> evaluation of the blocks and does not introduce more trust than the trust
> in the software already required.
>
>
> Now for the bold claim, let us first make a pragmatic assessment: Reorgs
> of more than 20000 blocks cannot happen. Although in theory reorgs are
> unlimited, we can "proof" this assessment by contradiction: If a reorg of
> 20000 blocks *would* happen it immediately becomes clear that the currency
> is useless, worthless, and that Satoshi's invention doesn't work after all.
>
> Now let Y be the block 20000 blocks back. There is a lot of code in the
> codebase that is only relevant for blocks before Y and not used for blocks
> after Y and new blocks. If we take above reorg-assumption as fact, and
> follow the logic laid out we must conclude:
>
> ** All this historical validation code is *completely redundant* with a
> single clause stating Y is valid ! **
>
> This is counter-intuitive as it seemingly contradicts the "verify don't
> trust" idea some cryptographers have been pushing. But only seemingly so;
> with the max-20000 reorg assumption, this old validation code serves no
> purpose and doesn't decrease trust or increase security.
>
> I am not proposing that we should rush removing old validation code; it
> certainly has some elegance to include it. But I wanted to share
> nonetheless this perspective on security and trust which seems so often
> misunderstood.
>
>
> Tomas van der Wansem
> bitcrust
> _______________________________________________
> 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/20180301/02462188/attachment.html>