3 ms·
> How do you prove that a coin has validly been spent? First, prove that it hasn’t already been spent! How do you do that if you don’t have the blockchain data?
by mrb 9y ago
> How do you prove that a coin has validly been spent? First, prove that it hasn’t already been spent! How do you do that if you don’t have the blockchain data? You can't
There is actually a trivial way to do it. We could prune ~98% of the blockchain data by committing to a UTXO set. We call this UTXO set commitment. Here is a very brief overview of how it works (this is not classic "pruning", and this is something I wrote before being aware of UTXO set commitment, but still it's a good introduction to the general concept):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015296.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...
I'm actually surprised Peter doesn't touch the subject since he's been researching this idea himself. IMHO, UTXO set commitment is one of the most promising, if not most promising way to scale the blockchain. Sadly it seems to be under-researched compared to other alternatives.
- indolering 9y agoIt was the great hope early on, but it turned out to be impractical to implement.
- rocqua 9y agoWhat are the practical issues? Serialization of the UTXO set? Dealing with large rollbacks? Time spent computing the hash? None of those seem impractical.
- apo 9y agoThere's some detail here: TXO commitments aren’t a new idea - the author proposed them years ago2 in response to UTXO commitments. However it’s critical for small miners’ orphan rates that block validation be fast, and so far it has proven difficult to create (U)TXO implementations with acceptable performance; updating and recalculating cryptographicly hashed merkelized datasets is inherently more work than not doing so. Fortunately if we maintain a UTXO set for recent outputs, TXO commitments are only needed when spending old, archived, outputs. We can take advantage of this by delaying the commitment, allowing it to be calculated well in advance of it actually being used, thus changing a latency-critical task into a much easier average throughput problem. https://petertodd.org/2016/delayed-txo-commitments https://petertodd.org/2016/delayed-txo-commitments
- rocqua 9y agoThanks! That is pretty much what I was looking for.