<p>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. </p>

<p>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. </p>

<blockquote>
  <p>"UTXO commitment" could eliminate the need for downloading old blocks. </p>
</blockquote>

<p>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. </p>

<p>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. </p>

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

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki" rel="nofollow noreferrer">BIP157</a> allows for wallet rescans without the block data being retained. </p>

CC BY-SA 4.0
2019-01-18T04:00:32.680Z
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
CC BY-SA 4.0
2019-01-18T04:01:53.230Z
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
CC BY-SA 4.0
2019-01-18T04:04:17.363Z
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
CC BY-SA 4.0
2019-01-18T04:04:51.900Z
As for BIP157, I heard it's for lightweight clients. I wonder if it's possible that a malicious full node feeds incorrect data to the client intentionally?
Chris Chen
CC BY-SA 4.0
2019-01-18T04:07:15.063Z
You can make your own 157 filters and discard the blocks, giving you a compact data set to rescan from without trusting anybody else.
Claris
CC BY-SA 4.0
2019-01-18T04:53:01.087Z
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.
Ava Chow
CC BY-SA 4.0
2019-01-18T04:56:28.770Z
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).
Ava Chow
CC BY-SA 4.0
2019-01-18T06:32:40.400Z
@AndrewChow Why minimumchainwork is intended to defend against DoS attack? I see no block height data tied to it.
Chris Chen
CC BY-SA 4.0
2019-01-18T06:33:18.390Z
I also found this: https://bitcoin.stackexchange.com/questions/76018/how-does-headers-first-prevent-fill-disk-attack?noredirect=1&lq=1#comment87815_76021
Chris Chen
CC BY-SA 4.0
2019-01-18T16:32:15.807Z
minimumchainwork does not need to have a block height tied to it. The chainwork is what determines what the best blockchain is. The blockchain that your node uses is the one with the most chainwork, not the one with the most blocks. Otherwise I could trivially make a blockchain that is millions of blocks long with all blocks being difficulty 1. minimumchainwork protects from those kinds of DoS attacks because it immediately ignores those low difficulty blocks since the blockchain they are part of does not have sufficient chainwork.
Ava Chow
CC BY-SA 4.0
2019-01-18T19:34:06.003Z
@AndrewChow According to the link above, I see minimumchainwork doesn't prevent header-fill attacks, since it actually allows the attacker to produce trillions of garbage block headers, which would trick a node into meaningless header validation work.
Chris Chen
CC BY-SA 4.0
2019-01-18T22:36:59.550Z
Checkpoints don't prevent that either. You can make trillions of garbage block headers now and trick a node into meaningless header validation work. Validating headers is not particularly expensive though. Checkpoints make it harder to create a large low work fork, but minimumchainwork prevents your node from being forced to validate all of those blocks (you would still validate the headers).
Ava Chow
CC BY-SA 4.0
2019-01-18T22:37:52.070Z
Validating a header is almost free, fortunately, though connecting them and storing them is not.
Claris
CC BY-SA 4.0
2019-01-18T03:51:50.103Z
2019-01-18T03:51:50.103Z
Claris
<p>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).</p>

<p>I once heard that <a href="https://twitter.com/LukeDashjr/status/944711936595365889" rel="nofollow noreferrer">"backward syncing" might help</a>. I also heard that <a href="https://www.reddit.com/r/btc/comments/7tbtto/utxo_commitments_for_bitcoin_cash/" rel="nofollow noreferrer">"UTXO commitment" could eliminate the need for downloading old blocks</a>. I wonder what exactly are them? Is there any relationship between them? Is there any technical hurdle that is very hard to overcome?</p>

<synchronization><full-node><utxo-committments>
Is backward syncing viable for full nodes?
Chris Chen
# Is backward syncing viable for full nodes?

(Asked by: username_0 on 2019-01-18)

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](https://twitter.com/LukeDashjr/status/944711936595365889). I also heard that ["UTXO commitment" could eliminate the need for downloading old blocks](https://www.reddit.com/r/btc/comments/7tbtto/utxo_commitments_for_bitcoin_cash/). I wonder what exactly are them? Is there any relationship between them? Is there any technical hurdle that is very hard to overcome?

**Tags:** synchronization, full-node, utxo-committments


---

## 1 answers

### Answer by username_1 on 2019-01-18. Score: 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](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) allows for wallet rescans without the block data being retained.

> **Comments:**
> **username_0**: 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.  
> **username_1**: 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.  
> **username_0**: 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.  
> **username_0**: As for BIP157, I heard it's for lightweight clients. I wonder if it's possible that a malicious full node feeds incorrect data to the client intentionally?  
> **username_1**: You can make your own 157 filters and discard the blocks, giving you a compact data set to rescan from without trusting anybody else.  
> **username_2**: 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.  
> **username_2**: 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).  
> **username_0**: @AndrewChow Why minimumchainwork is intended to defend against DoS attack? I see no block height data tied to it.  
> **username_0**: I also found this: https://bitcoin.stackexchange.com/questions/76018/how-does-headers-first-prevent-fill-disk-attack?noredirect=1&lq=1#comment87815_76021  
> **username_2**: minimumchainwork does not need to have a block height tied to it. The chainwork is what determines what the best blockchain is. The blockchain that your node uses is the one with the most chainwork, not the one with the most blocks. Otherwise I could trivially make a blockchain that is millions of blocks long with all blocks being difficulty 1. minimumchainwork protects from those kinds of DoS attacks because it immediately ignores those low difficulty blocks since the blockchain they are part of does not have sufficient chainwork.  
> **username_0**: @AndrewChow According to the link above, I see minimumchainwork doesn't prevent header-fill attacks, since it actually allows the attacker to produce trillions of garbage block headers, which would trick a node into meaningless header validation work.  
> **username_2**: Checkpoints don't prevent that either. You can make trillions of garbage block headers now and trick a node into meaningless header validation work. Validating headers is not particularly expensive though. Checkpoints make it harder to create a large low work fork, but minimumchainwork prevents your node from being forced to validate all of those blocks (you would still validate the headers).  
> **username_1**: Validating a header is almost free, fortunately, though connecting them and storing them is not.  

---

