0

Currently, Every Bitcoin Core full node has to download the whole blockchain at least once. This situation is even worse if pruning is enabled - the user has to download the whole gigantic blockchain all over again if a rescan is required (typically after importing privkeys/addresses/wallet.dat).

I once heard that "backward syncing" might help. I also heard that "UTXO commitment" could eliminate the need for downloading old blocks. I wonder what exactly are them? Is there any relationship between them? Is there any technical hurdle that is very hard to overcome?

Improve this question

1 Answer 1

Reset to default
1

In bitcoin we add unspent entries to the UTXO when created inside a block, and delete them when they are spent. Syncing “in reverse” would be a messy process that wouldn’t allow for the verification of authenticity of the blocks being imported until the sync was entirely complete, where going forwards we have complete confidence in blocks as they progress.

The software can reverse blocks to undo changes to the state during a block reorganization, but this is excruciating slow as it requires going back to the older blocks using a reference list and reinserting the UTXO entries that were previously removed.

"UTXO commitment" could eliminate the need for downloading old blocks.

UTXO commitments don’t remove the need for full validation, they introduce a new weaker level of node operation where they trust that miners have included valid commitments.

UTXO commitments also require an extremely large amount of hashing to achieve, which makes them implausible for use in the production network without other changes.

the user has to download the whole gigantic blockchain all over again if a rescan is required (typically after importing privkeys/addresses/wallet.dat).

BIP157 allows for wallet rescans without the block data being retained.

Improve this answer
13
  • I see Bitcoin Core enables assumevalid by default, so by default it doesn't actually fully validate old blocks independently, right? In other words, the user trusts the developer who hardcoded the block hash if he never sets assumevalid to 0.
    – Chris Chen
    Jan 18, 2019 at 4:00
  • This is to prevent a denial of service where you produce infinitely large numbers of difficulty 1 blocks. Only signature validation is skipped, and this peg hasn’t been updated in many years.
    – Claris
    Jan 18, 2019 at 4:01
  • Checkpoints, instead of assumevalid, are intended to defend against DoS attacks, which is a legacy that hasn't been updated in many years as far as I know.
    – Chris Chen
    Jan 18, 2019 at 4:04
  • 1
    assumevalid only disables script verification as that is expensive. Everything else (PoW, UTXOs, merkle root, etc.) is still checked. Assumevalid and checkpoints are actually very similar, they even share the same code. That's because assumevalid was designed to have the performance benefits of checkpoints without the requirement of blocks needing to be in the blockchain. Neither really defend against DoS attacks; rather that's what minimumchainwork is for. It requires that the cumulative chainwork must be at least that value.
    – Andrew Chow ♦
    Jan 18, 2019 at 4:53
  • 1
    When Bitcoin Core starts using BIP 157, it won't be for syncing faster. Rather it will generate the filters for every block it receives and store that. The filters allow rescans to happen much faster, regardless of whether the node is pruned or not. In both cases, the filter will indicate whether a block contains a transaction pertaining to the wallet so the block can be fetched (either from disk or over the network) and the necessary transactions pulled out. BIP 157 helps both pruned and archival nodes at no security risk. It only affects disk space and sync time (making filters takes time).
    – Andrew Chow ♦
    Jan 18, 2019 at 4:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.