<blockquote>
  <p>Is there a reason that prevents us from introducing this?</p>
</blockquote>

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

CC BY-SA 3.0
2017-11-02T00:34:44.803Z
Maybe you dont need to validate full blockchain only the last 10000 blocks everybody agrees upon?
croraf
CC BY-SA 3.0
2017-11-02T00:59:40.243Z
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
CC BY-SA 3.0
2017-11-02T07:10:46.567Z
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
CC BY-SA 3.0
2017-11-02T08:38:55.950Z
@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
CC BY-SA 3.0
2017-11-03T05:02:27.680Z
The genesis block is hard coded into the software itself. It is not something that is received from peers.
Ava Chow
CC BY-SA 3.0
2017-11-04T04:24:12.107Z
Ok, maybe I should rephrase my question: Is there a cryptographic feat possible that would allow us to drop lots of history?
erik
CC BY-SA 3.0
2017-12-26T12:20:41.433Z
@erik Yes, look up Mimblewimble. It's a radically different design than Bitcoin though.
Pieter Wuille
CC BY-SA 3.0
2017-11-01T21:30:28.010Z
2017-11-01T21:30:28.010Z
amaclin
<p>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.</p>

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

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

CC BY-SA 3.0
2017-11-02T00:31:19.430Z
Can you explain why opening-balance is not feasible to do or point to discussion?
croraf
CC BY-SA 3.0
2017-11-02T07:55:14.143Z
It is feasible. As I said, it only wasn't done because of an oversight.
David Schwartz
CC BY-SA 3.0
2017-11-02T08:31:32.027Z
So this ledger restart is done in Ripple? And is done using UTXO hash?
croraf
CC BY-SA 3.0
2017-11-02T08:33:18.430Z
@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.
David Schwartz
CC BY-SA 3.0
2017-11-02T08:34:37.003Z
And the ledger does not grow indefinitely in Ripple but is restarted from time to time?
croraf
CC BY-SA 3.0
2017-11-02T08:35:53.920Z
@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.
David Schwartz
CC BY-SA 3.0
2017-11-01T21:22:19.683Z
2017-11-01T21:22:19.683Z
David Schwartz
<p>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.</p>

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

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

<p>Is there a reason that prevents us from introducing this?</p>

<blockchain>
Would there be a problem introducing opening-balance transactions in bitcoin?
erik
# Would there be a problem introducing opening-balance transactions in bitcoin?

(Asked by: username_0 on 2017-11-01)

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?

**Tags:** blockchain


---

## 2 answers

### Answer by username_1 on 2017-11-01. Score: 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?

> **Comments:**
> **username_2**: Maybe you dont need to validate full blockchain only the last 10000 blocks everybody agrees upon?  
> **username_3**: 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.  
> **username_0**: 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.  
> **username_2**: @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.  
> **username_3**: The genesis block is hard coded into the software itself. It is not something that is received from peers.  
> **username_0**: Ok, maybe I should rephrase my question: Is there a cryptographic feat possible that would allow us to drop lots of history?  
> **username_4**: @username_0 Yes, look up Mimblewimble. It's a radically different design than Bitcoin though.  

---

### Answer by username_5 on 2017-11-01. Score: 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.

> **Comments:**
> **username_2**: Can you explain why opening-balance is not feasible to do or point to discussion?  
> **username_5**: It is feasible. As I said, it only wasn't done because of an oversight.  
> **username_2**: So this ledger restart is done in Ripple? And is done using UTXO hash?  
> **username_5**: @username_2 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.  
> **username_2**: And the ledger does not grow indefinitely in Ripple but is restarted from time to time?  
> **username_5**: @username_2 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.  

---

