Nathaniel
Member
What do you think about creating UTXO-based blocks? I mean, instead of including single transactions, having a block format like this: output (base-58 160-bit hash or anything else accepted by current protocol) + amount of unspent coins + rest needed info...; next output, next amount, etc.
1A...1 1.23456789 BTC
1A...2 0.56789012 BTC
...
1Z...9 8.90123456 BTC
In this way the most recent block will contain the state of the whole system. Of course, it would be huge, so we can organize it in some kind of tree-like structure (for example binary tree, but not necessary). All addresses will be always sorted to improve updating. Every entry could be 512-bits aligned (or any else "nice" size for hashing functions like SHA-256). Then, we could use hash of such huge block for mining.
What are advantages of this model? Firstly, we would have the whole system state in the latest block "out of the box", without processing some redundant information. Latest block hash would be based on simple hash of all entries, so we could easily download this latest huge block and have everything we need if running full node. Also we could start cutting some earlier blocks at some point of time, because it would be pointless to change some block mined 5 years ago or earlier. In this way we could preserve for example last N blocks and delete earlier information as changing it after many years (or many confirmations) will never be accepted by miners.
Secondly, it is true for all blocks, so all such blocks hashes would be made in the same way. But we would not need to upload and download everything, we could optimize identical fragments by sending hash starting with given IV and ending with given hash for any continuous amount of entries. So if we want for example to change two entries, we could do it in this way:
IV and exit hash for entries from 1 to 999
1m...x 0.54321098 BTC
IV and exit hash for entries from 1001 to 2345
1s...w 0.22223333 BTC
IV and exit hash for entries from 2347 to the end
This would be enough to calculate correct hash of the new block without knowing every unspent transaction output. In this way we could send diffs between blocks without sending the same info over and over again. And full node would need only one huge block and diffs between this block and other blocks. Light nodes also could optimize it further and download only selected outputs and keep an eye on hashes between them.
Of course for completeness all amount of coins should match, so we also need all input addresses and all signatures in such block, but we would need them once, because next block would probably contain another input addresses and of course different signatures.
Any ideas, improvements and suggestions are welcome.
1A...1 1.23456789 BTC
1A...2 0.56789012 BTC
...
1Z...9 8.90123456 BTC
In this way the most recent block will contain the state of the whole system. Of course, it would be huge, so we can organize it in some kind of tree-like structure (for example binary tree, but not necessary). All addresses will be always sorted to improve updating. Every entry could be 512-bits aligned (or any else "nice" size for hashing functions like SHA-256). Then, we could use hash of such huge block for mining.
What are advantages of this model? Firstly, we would have the whole system state in the latest block "out of the box", without processing some redundant information. Latest block hash would be based on simple hash of all entries, so we could easily download this latest huge block and have everything we need if running full node. Also we could start cutting some earlier blocks at some point of time, because it would be pointless to change some block mined 5 years ago or earlier. In this way we could preserve for example last N blocks and delete earlier information as changing it after many years (or many confirmations) will never be accepted by miners.
Secondly, it is true for all blocks, so all such blocks hashes would be made in the same way. But we would not need to upload and download everything, we could optimize identical fragments by sending hash starting with given IV and ending with given hash for any continuous amount of entries. So if we want for example to change two entries, we could do it in this way:
IV and exit hash for entries from 1 to 999
1m...x 0.54321098 BTC
IV and exit hash for entries from 1001 to 2345
1s...w 0.22223333 BTC
IV and exit hash for entries from 2347 to the end
This would be enough to calculate correct hash of the new block without knowing every unspent transaction output. In this way we could send diffs between blocks without sending the same info over and over again. And full node would need only one huge block and diffs between this block and other blocks. Light nodes also could optimize it further and download only selected outputs and keep an eye on hashes between them.
Of course for completeness all amount of coins should match, so we also need all input addresses and all signatures in such block, but we would need them once, because next block would probably contain another input addresses and of course different signatures.
Any ideas, improvements and suggestions are welcome.
