4 ms·
this is pretty good. Key line for me: > 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
by davidgerard 9y ago
this is pretty good. Key line for me:
> 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.
- janitor61 9y agoWhy couldn't you use a sufficiently large bloom filter to determine if a coin has been spent?
- deleted 9y ago[deleted]
- thinkloop 9y agoHow do you verify the authenticity of the bloom filter?
- teddyh 9y agoThat’s not really a problem – anyone could verify it by downloading the full blockchain. The important thing is that you don’t need the full blockchain to get a negative answer from a bloom filter, which helps. 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.
- deleted 9y ago[deleted]
- 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.