Topic: UTXO-based blocks (Read 250 times)

Bitcoin Core is a foundation of the network. And you're right, a full validation of transaction history is necessary to ensure that all of UTXO entries are valid. You don't need to actually store this data, but you have to validate it.

Otherwise you'll be forced to trust some third party, which is not acceptable. Just look at Ripple, most of p2p nodes aren't bothering to perform full validation of history. They're simply verifying few hundred of most recent blocks and the rest part of blockchain is not even downloaded. Instead, they're trusting the Ripple Labs and Ripple Labs approved set of validators.

Is this what you want for bitcoin?

How else can you be sure that no coins outside of the schedule were introduced (e.g. due to a bug)? How else can you be sure that there wasn't any double spend throughout history? Most importantly, how else you can keep an account of how much coins each address has (without depending on a trusted 3rd-party)?

Miners do download the full transaction history and it's expected that they'd want to keep pools going. But it's not just mines, many people keep nodes running, you don't have to store the whole chain either, you can prune the chain but in order to keep a trustworthy source of data and remain connected to the network, you have to validate the blocks you accept from miners/other nodes.

Can I suggest the current blockchain as an improvement?

It's trustless so you can verify everything for yourself you can provably still download the chain online and parse it but you should be able to run your own node (if you want to) and have it sync within 200 hours (200 hours is based on my 10 year old computer, newer machines are much faster).

Bitcoin isn't worth so much because Ripple is better... Look at the market cap comparisons.

Congratulations, you've just invented Ripple.

https://twitter.com/tuurdemeester/status/1028262924987637760

This is what you will get as the result.

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.