Compressed blocks in blockchain only with unspent TXs

[Perlover]

Hi all,

Sorry for my English if it's not good for understanding

I am ordinary user if Bitcoin. I am concerned about the increasing size of blockchain. Now in the Bitcoin not so much amount of tansactions but if the Bitcoin will be bery popular the Bitcoin blockchain will be unreal biggest for ordinary users and for using.

I want to suggest an approximate solution fot decrease blockchain of Bitcoin.

As i think now the blockchain to be need for checking all not spent outputs of transactions. Some not spent outputs deeply submerged under blocks. Some transactions with unspent outputs can be in the block number 123, other in the block number 128523 and so on. By this reason a client software needs scan and check all blockchain from up to down for balances of client's addresses and so on. I want to suggest simply solution. Details are skipped. This is a very rough description, sorry for it

I think the blockchain can have a special block to be mined and to be checked by miners (difficulty can be more strong and to be based from current difficulty). This block can be mined through 2016 blocks for example (every two weeks) as the difficulty to be changed. This will be special block without current live transactions. It will have only transactions with unspent outputs. For example i will call this block "the compressed block". This block should have only unspent outputs of transactions to be happened from previously "the compressed block". Because now the blockchain doesn't have same blocks first block should have all last unspent transactions from genesis block for example. Same special blocks should be checked by miners (miners will have whole blockchain in first time) and to be mined by same algorithms as normal blocks with transactions. I don't know how to use there coinbase. May be the reward for this block same as normal and reward will be devided to two after 210,000 blocks but these blocks take into account in total mined blocks.

When same "compressed blocks" will be there client software can download blockchain from up plain blocks down to first compressed blocks then it can load only old compressed blocks. I think now that this information about unspent transactions could be enough for the normal functioning of the network. But these blocks will resolve main future problem of biggest size of blockchain in future. All made transactions will be eliminated from memory of clients and client's blockains.

What do you think about this?

[DeathAndTaxes]

The problem with that is an attacker (even one with 51% of hashrate) currently has limited capabilities.  They can't give themselves coins, or steal coins.   With a "super block" an attacker could simply rewrite history.   Nodes which didn't validate the entire chain would be unable to tell the truth from fiction.  If nodes need to download the entire chain anyways to validate the super block then you haven't gained anything.

The reality is most users will not be running full nodes.

[Perlover]

Ok, i see

But please other question, please read:

https://en.bitcoin.it/wiki/Scalability#Storage

In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent.

I have read Satoshi's paper and there pruning to be used for Merkle tree. Merkle tree to be needed only for quickly searching and checking "Is there transaction in block or not". I think there is error in wiki that Satoshi described pruning as "way to delete unnecessary data about transactions that are fully spent"

Ok, i understood you. May be this will be dangerous but this "compressed block" should be checked by miners and to be accepted by network. In first time full nodes will have a whole blockchain data in start time. Then if compressed block checked by other nodes and is approved by finding a nounce for the target hash this block can be basis for unspent transactions. After this through some time (for example after 100 confirmations) full nodes can forget about olddest blocks. If attacker will want to rewrite history he to be needed to make same job as to generate 100 confirmation for example. I think it will be hard to do as well as to rewrite blockchain from this place.

Now we have two protocol: full node and simplified protocol. I suggest to improve full node protocol.

Maybe I am much mistaken for these "compressed blocks"

But if the Bitcoin will be very popular and there will be ~ 2000 tps (https://en.bitcoin.it/wiki/Scalability#Network) then full nodes as it to be today should have: 2000 * 512 * 86400 = 82G per day (30 TB per year). And there (in blockchain) will be 90% of spent transactions. Now the Bitcoin Core should to be runned whole day from bootstrap file. What will be through 2-4 years?

[Perlover]

My mistake about pruning (from Satoshi's paper):

7. Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space. To facilitate this without breaking the block's hash,
transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do
not need to be stored.

So if i understood right now the Bitcoin Core even now could have a feature don't keep spent transactions?
That is, when it loads blockchain it can find spent transactions and eliminate theirs and keep only Merkle tree?

[Perlover]

I think i understood why Merkle tree was made by Satoshi

Yes, when client software loads/checks the blockchain it can find spent/unspent transactions. The data of these transactions can be needed only for checking a transaction chain to genesis block. So client software starts to check from output tips of every transaction from upper block to down, and bodies (payloads) of most old transactions can be eliminated from local blockchain data at disk but we have a hashed Merkle root in every header block and we can check is there transaction id in same block or not. Because unspent (and spent) transactions has inputs as transaction id + output index I think this info will be enough to trust because transaction id checked by miners and approved by them by hashing block header with Merkle root. But after compressing same method as i understood we cannot to make fully checking again because we will not have payload (array of inputs [ txid, output_index ] ) of oldest eliminated trafnsactions we will have only info - "is there tx or not in such block".

So in future the Bitcoin Core can compress the local blockchain and eliminate all old spent transactions.

Right?

[onchain.io]

So in future the Bitcoin Core can compress the local blockchain and eliminate all old spent transactions.

Right?

You can eliminate spent outputs yes. It's generally called blockchain pruning and there have been several discussion on this. i.e. https://bitcointalk.org/index.php?topic=96644.0

Enjoy.

[DeathAndTaxes]

So in future the Bitcoin Core can compress the local blockchain and eliminate all old spent transactions.

Yes but it is important to consider the impact that will have on other nodes. The current protocol only supports relaying "full blocks" so if your node only contained pruned blocks then you would not be able to support the bootstrapping of other nodes.  In essence you would no longer be a full node.  You would internally have the security of a full node however you would appear more like an SPV (lite) node to other nodes on the network.

What is needed is a more robust set of internode messages so that nodes can request and relay pruned blocks.  Also this has less of an impact than you might imagine.  Today your node doesn't really "use" blocks beyond building the UTXO.   Your node stores them for archival purposes (and to bootstrap other nodes) but the blocks are only used to build and update the UTXO.  All validation of new txns and blocks is done against the UTXO.  The UTXO is much smaller than the blockchain (0.4 GB vs 20 GB) and it is the more critical resource. Pruning blocks won't change the performance, size, or resource requirements of the UTXO.