3

For example, every 10,000 blocks, the new block would propose an opening balance for all addresses that are still being mentioned in the blockchain with non-zero unspent outputs. It would be an opening-balance transaction.

All validating nodes must then recompute the opening-balance transaction and verify that it is correct, after which all previous transactions in the blockchain can be deleted/forgotten. It would effectively be a new genesis block.

It should allow validating nodes to free a lot of disk space and permit nodes with less capacity to participate in the network.

Is there a reason that prevents us from introducing this?

2 Answers 2

1

Is there a reason that prevents us from introducing this?

How will you download and validate the full blockchain if nobody around you has the full blockchain but has only "pruned" version of it started from block #xx0000?

7
  • Maybe you dont need to validate full blockchain only the last 10000 blocks everybody agrees upon?
    – croraf
    Commented Nov 2, 2017 at 0:34
  • 1
    How does everyone agree on those blocks? You can't be sure whether the "opening transaction" that someone gave you and then a few thousand blocks mined after that are for Bitcoin and not some malicious chain.
    – Ava Chow
    Commented Nov 2, 2017 at 0:59
  • We could separately blockchain the opening balances too: level 4 (every 10,000) bals4/1 --> bals4/2 --> ... bals4/N4 // level 5 (every 100,000) bals5/1 --> bals5/2 --> ... bals5/N5 // level 6 (every 1,000,000) ... // The very first balances block is chained against the genesis block During a download, we ask for the genesis block and the latest balances block of the highest level N. Next, we ask for the chain of subsequent N-1 balances, until we reach the chain of level 4, after which we download the transactions themselves that follow the latest lowest-level opening balances.
    – erik
    Commented Nov 2, 2017 at 7:10
  • @AndrewChow How are you nowadays sure that the opening block is indeed true and not a malicious genesis block with 1000 blocks given on top or that peers provided you with malicious side chain? This fits for a separate question I will post later, but you probably wait to recieve longer chain.
    – croraf
    Commented Nov 2, 2017 at 8:38
  • 1
    @erik Yes, look up Mimblewimble. It's a radically different design than Bitcoin though. Commented Dec 26, 2017 at 12:20
0

No, and such a thing has been proposed. A better way to do it would be to include the hash of the UTXO tree tip in every block header. Early bitcoin developers have described the failure to do this as an oversight and other systems (such as Ripple) do this.

It's actually kind of scary that we don't have this. Think about it -- how do we really know that existing bitcoin full nodes actually agree on the set of UTXOs? Suppose there was a bug somewhere that caused non-deterministic behavior in transaction execution. There might be some servers that think a UTXO is valid and some that think it's not despite agreeing on the blockchain.

Fortunately, bitcoin transactions are simple enough that this concern is pretty far fetched. But for more complex systems, it's a serious concern.

6
  • Can you explain why opening-balance is not feasible to do or point to discussion?
    – croraf
    Commented Nov 2, 2017 at 0:31
  • It is feasible. As I said, it only wasn't done because of an oversight. Commented Nov 2, 2017 at 7:55
  • So this ledger restart is done in Ripple? And is done using UTXO hash?
    – croraf
    Commented Nov 2, 2017 at 8:31
  • @croraf It's a little bit difficult to explain. Ripple doesn't really have UTXOs, but it does have some state that persists from ledger to ledger unless it changes (such as what accounts have what balances). The hash of the Merkle tree of this state is included in the header for each ledger. So you can walk the state tree of ledger 3,000,000 without any historical data at all just by following the tree of hashes. Commented Nov 2, 2017 at 8:33
  • 1
    @croraf The ledger does not need to be restarted -- data that is no longer usable (such as spent balances) just fall out of the ledger by being no longer referenced. If you want to understand a particular ledger, you just walk its Merkle tree -- the tree of all the data reachable from that particular ledger header. Commented Nov 2, 2017 at 8:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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