4 ms·
It was the great hope early on, but it turned out to be impractical to implement.
by indolering 9y ago
It 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.