maintaining zero-trust with low clean startup cost.

[harik]

Edit: It looks like ultraprune is more similar to this than I thought, so the only question is 'is it feasible to migrate the miners to signing that data every few hundred blocks so that it can be fully trusted no matter where the source?'

Right now, the proof-of-work (block headers only) runs ~20mb.  A full summary of non-zero-balance addresses is another 50mb.   If that balance summary could be generated in a fixed way, miners could include the hash of it as a transaction item and the 50mb summary wouldn't need to be passed around itself, since any node could recreate it from it's own data.

Full block header chain, recent balance summary, and full blocks since the balance summary.  That's on the order of 100mb download, instead of the current 6.5gb blockchain.

Am I missing an attack on this somewhere?  Network-wise, you can request full proof of any archived transaction by requesting the block from a peer, and since you have the sha256 of the merkle root as part of the headers nobody can feed you fake transaction data.  The proof-of-work only is exactly as hard to fake as the full blockchain, and it's trivial to verify that the hash of the balance summary exactly matches the generated balance data.

If the standard is 'sign the balance summary every 100 blocks' the overhead for mining would be insignificant.  Since it's just another transaction, no ASIC/GPU mining code would even have to know about it, and the overhead of running a single sha256 over data you already have to maintain to run a mining pool is insignificant.

This seems a fairly obvious proposal, so I'm sure someone has come up with it before - but googling for bitcoin 'balance summary' is flooded with descriptions of the client's user interface.

[harik]

My estimate of non-zero-balance addresses was wrong, what's required is a summary of unspent transaction outputs, with is a superset of addresses.  Still, serializing UxO into a summary will require a lot less space than the full blockchain, and should still be able to be defined in such a way that the actual summary block never needs to be passed around, except to be generated specifically to bootstrap a client.

[TierNolan]

My estimate of non-zero-balance addresses was wrong, what's required is a summary of unspent transaction outputs, with is a superset of addresses.  Still, serializing UxO into a summary will require a lot less space than the full blockchain, and should still be able to be defined in such a way that the actual summary block never needs to be passed around, except to be generated specifically to bootstrap a client.

There is a thread discussing compressing this data.  The idea is to have a merkle like tree that stores the data. 

If you have the previous value and the list of transaction outputs from the current block (and some extra info about branches), you can prove that the tree was correctly updated.

If one of those was included in each block header, then double spending would be detectable without the whole chain.

[harik]

There is a thread discussing compressing this data.  The idea is to have a merkle like tree that stores the data. 

If you have the previous value and the list of transaction outputs from the current block (and some extra info about branches), you can prove that the tree was correctly updated.

If one of those was included in each block header, then double spending would be detectable without the whole chain.

Ahh, perfect.  I knew the idea was obvious enough I wouldn't have been the first.  Thank you, I had no idea what people called the idea to search for it.

So yeah, that's great.  To bootstrap you ask nearby nodes what their max block is and their current UxO tree and for the block-header-history.  It doesn't matter if the one you ask is a few blocks behind, since once you verify you can just append new blocks to the end.   If you end up happening to bootstrap on a fork you just grab the UxO tree from the split and append the blocks on the longer chain.

[TierNolan]

So yeah, that's great.  To bootstrap you ask nearby nodes what their max block is and their current UxO tree and for the block-header-history.  It doesn't matter if the one you ask is a few blocks behind, since once you verify you can just append new blocks to the end.   If you end up happening to bootstrap on a fork you just grab the UxO tree from the split and append the blocks on the longer chain.

The idea would be to have a root per block.  However, it looks like it actually aux merkle tree for all transactions.

So, if you provided all the transactions for a block, you could prove that the update was correct.  It requires more info per transaction though.  You have to provide the path through the merkle tree.

This is required to make sure that no new money is created.