{"type":"rich","version":"1.0","author_name":"npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6","author_url":"https://nostr.ae/npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-02-23\n📝 Original message:On Wed, Feb 22, 2017 at 5:15 PM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e With that, notice how proving the soundness of the proofs becomes trivial:\n\u003e if\n\u003e validation is deterministic, it is obviously impossible to construct two\n\u003e different proofs that prove contradictory statements, because a proof is\n\u003e simply\n\u003e part of the data structure itself. Contradiction would imply that the two\n\u003e proofs are different, but that's easily rejected by simply checking the\n\u003e hash of\n\u003e the data.\n\u003e\n\nMy code works this way. Proofs are serialization of a subset of the tree,\nand to validate a proof you ask a single function whether a particular\nvalue is included in that tree subset, and it answers yes or no, so\nobviously it's impossible for a single value to both validate and not\nvalidate. The proof code was quite terrifying before I made this change\n(which I did on your suggestion), and it's much cleaner and simpler now. It\nalso in principle supports compact proofs of multiple inclusions and\nexclusions in the same serialization of a subset of the tree because the\nupper branches won't have to be repeated. I haven't written code for\ngenerating those, but the validation code will happily accept them.\n\nI'm not sure what you mean by MMRs though. Are you talking about MMRs where\neach mountain is a set of diffs to the old things and are periodically\nconsolidated? Or do later mountains refer to internals of earlier ones? Or\ndo they have 'maybe' values which mean that the earlier mountain should be\nreferred to? Are these patricia tries or something flatter and more fixed\ndepth?\n\nMy code doesn't keep track of tree size, by the way. It would be trivial to\nadd that functionality to the library, and including it in the hashing\ncreates complexity and doesn't seem to have any benefit over sending that\ndata in a side channel.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170222/4a48d1ae/attachment-0001.html\u003e"}