A guy at btc++ Istanbul had an interesting project. He downloads the blockchain without checking for doublespending. After he has all the data, he does a doublespend check by running an efficient sorting algorithm called MergeSort, which, in his implementation, takes all "input" utxos and "output" utxos, sorts them alphabetically via txid_vout, and removes duplicates. Those are always outputs created in one tx and spent in another

The result is a list only containing unspent outputs, i.e. the result is the utxo set, and this procedure gives him a sync speedup of slightly over 50%. It also does not seem to require storing an "intermediate" utxo set *during* ibd

I wonder if is wise to do ibd with that method, and then apply the utreexo accumulator procedure to the utxo set once it gets created at the end of ibd. The result would be, you only need the full utxo set once during the lifetime of your node: you need it at the end of ibd, and only to construct the utreexo accumulator. After that, you don't need the utxo set, unless you want to help others sync the same way

Reply to this note

Please Login to reply.

Discussion

Interesting approach

If there is a double spend though, you gotta resync everything

Yeah, it has that in common with the swiftsync proposal

if i got it right, he baches the sync by downloading and handling 210000 blocks at a time to avoid to big resync.

Does it check for the other consensus rules along the way though? And is the double spend check really bottlenecking people beyond their internet speed?

I think constructing the utxo set after each block creates a cpu bottleneck

I don't get it. Aren't the transactions in all mined blocks guaranteed to be NOT double spent, except maybe the last dozen?

doublespend protection is not guaranteed unless you check for doublespends

if you don't check for them you are relying on someone else to check for them

if *no one* checks for them then doublespend protection is not guaranteed

Yes, if everyone checks, no blocks containing double spends will propagate to reach me. My node will check them anyway during the IBD I assume. So not sure what that guy's know how is about.

Love algorithms talk like this. Nice.

Stuff like this can help keep nodes efficient and decentralized.