Quote from: NotATether on Today at 06:26:39 AM

Note: merge all of your consecutive replies into one post.

Quote from: sha420hashcollision on May 02, 2023, 10:14:48 PM

Quote from: NotATether on May 02, 2023, 11:22:50 AM

Quote from: zezaiement on May 02, 2023, 09:40:20 AM

By creating a UTXO that aggregates other UTXOs, you would be able to greatly reduce the size of the UTXO set on the blockchain. This could potentially lead to faster and more efficient transactions.
However, this approach may lead to increased complexity in the verification process. In order to verify that a UTXO is valid and can be spent, the blockchain would need to verify not only the inclusion proof of the aggregate UTXO, but also the inclusion proofs of all of the individual UTXOs that make up the aggregate UTXO.
Can you make up a solution to this problem?

All a UTXO is, is a pair of a hex string (in this case, of a 32-byte transaction hash) and an integer which denotes output number (which usually can be represented in just 1 byte with an unsigned uint8_t, though even if that overflows, a 2-byte uint16_t will definitely be enough. Either way, its a numbers problem of other areas.

Suppose you have billions of UTXOs - this will equate to several GB of UTXO data. You can't simply just compress the UTXO set as that will only delay the inevitable.

So perhaps, a shredding algorithm could be implemented, where the oldest set of UTXOs past a particular threshold are ruthlessly shredded from the UTXO set (even if it represents thousands of bitcoins), and spending such a UTXO would require any node to scan for it from the beginning of the blockchain - in other words, we don't cache extremely old UTXOs.

And in case blockchain culling is also implemented - where instead of the Genesis block and the first X thousand blocks, you have a "coinbase transaction" of output UTXOs from those X blocks - there still isn't any fear of UTXOs being wiped out of the blockchain because they would still be there.

I think what you are suggesting is a commitment based pruning of very old utxos which I think might be efficient for things that are not considered full nodes but I think would be controversial to push into a full node. My idea may be controversial also but not for the reason that it would require old UTXO owners to maintain their chainstate, but more-so because it implies a new convolution in the way that an output can be spent. However I want to be clear my idea does not include altering the way old chainstate is processed, it would only affect blocks that adopt it.

Edit: Although on second thought, I think there could be a way this model is used to scale old chainstate at the discretion of the node operator

Pushing it to Bitcoin Core? Oh yeah, most features proposed for it are definitely controversial. That's why a new full node client with these features could be created instead, bypassing the Core dev status quo. And, if the full node is any good, new people who want to get into the network will run this new pruning full node, while the old guard continues to run Bitcoin Core to avoid permanently losing old blocks.

Even a 10:1 ratio of these new nodes against Bitcoin Core nodes would be good for the network as it would have the adoption equivalent to L2 layers, and even these L2 features can be incorporated directly inside the node.

Generally speaking though a one way compression to the UTXO set would likely be considered a lite client not a full node regardless of if it was in Core or not. My feature ideally would be full node compatible.