Why Scaling Bitcoin with Sharding Is Very Hard (2015)
petertodd.org
petertodd.org
> 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, and no amount of fancy math can change that.
and also, something Bitcoin devs realise that Bitcoin fans often don't seem to:
> On the other hand, decentralization isn’t cheap: using PayPal is one or two orders of magnitude simpler than the Bitcoin protocol.
The problem happens when you get a positive answer from the bloom filter; i.e. a coin might have been previously spent. As far as I know you then still need the full blockchain to verify.
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...
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.
Serialization of the UTXO set? Dealing with large rollbacks? Time spent computing the hash?
None of those seem impractical.
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.
(though it does offer some nice improvements, we're taking factors of 2-5, not 100-1000)