{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-20\n📝 Original message:Ah, I see, I didn't catch that this scheme relies on UTXO commitments\n(presumably with Mark's PATRICIA tree system?).\n\nIf you're doing a binary search over block contents then does that imply\nmultiple protocol round trips per synced block? I'm still having trouble\nvisualising how this works. Perhaps you could write down an example run for\nme.\n\nHow does it interact with the need to download chains rather than\nindividual transactions, and do so without round-tripping to the remote\nnode for each block? Bloom filtering currently pulls down blocks in batches\nwithout much client/server interaction and that is useful for performance.\n\nLike I said, I'd rather just junk the whole notion of chain scanning and\nget to a point where clients are only syncing headers. If nodes were\ncalculating a script-\u003e(outpoint, merkle branch) map in LevelDB and allowing\nrange queries over it, then you could quickly pull down relevant UTXOs\nalong with the paths that indicated they did at one point exist. Nodes can\nstill withhold evidence that those outputs were spent, but the same is true\ntoday and in practice this doesn't seem to be an issue.\n\nThe primary advantage of that approach is it does not require a change to\nthe consensus rules. But there are lots of unanswered questions about how\nit interacts with HD lookahead and so on.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150220/f8a10aca/attachment.html\u003e"}