{"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:Hey Adam,\n\n\n\u003e Mike had posted a detailed response on the topic on why its complex\n\u003e and becomes bandwidth inefficient to improve it usefully.\n\u003e\n\nTo clarify, we *could* improve privacy and still preserve usefully high\nperformance, it's just a lot of complicated programming work. You need to\nfind out from the OS how much bandwidth you have to play with, for example,\nand do all the very complex tracking to surf the wave and keep yourself in\nroughly the right place.\n\nThe basic summary of which I think is that its not even intended to\n\u003e provide any practical privacy protection, its just about compacting\n\u003e the query for a set of addresses.\n\u003e\n\nThe original intent of Bloom filtering was to allow both. We want our cake\nand we want to eat it.\n\nThe protocol can still do that, with sufficiently smart clients. The\nproblem is that being sufficiently smart in this regard has never come to\nthe top of the TODO list - users are always complaining about other things,\nso those things are what gets priority.\n\nIt's not IMO a protocol issue per se. It's a code complexity and manpower\nissue.\n\n\n\u003e Its seems surprising no one thought of it\n\u003e that way before (as it seems obvious when you hear it) but that seems\n\u003e to address the privacy issues as the user can fetch the block bloom\n\u003e filters and then scan it in complete privacy.\n\n\nAnd then what? So you know the block matches. But with reasonable FP rates\nevery block will match at least a few transactions (this is already the\ncase - the FP rate is low but high enough that we get back FPs on nearly\nevery block). So you end up downloading every block? That won't work.\n\nEventually, wallets need to stop doing linear scans of the entire block\nchain to find tx data. That worked fine when blocks were 10kb, it's still\nworking OK even though we scaled through two orders of magnitude, but we\ncan imagine that if we reach 10mb blocks then this whole approach will just\nbe too slow.\n\nThe main reason wallets are scanning the chain today (beyond lack of\nprotocol support for querying the UTXO set by script), is that they want to\nshow users time-ordered lists of transactions. Financial apps should show\nyou payment histories, everyone knows this, and without knowing roughly\nwhen a tx happened and which inputs/outputs were mine, providing a useful\nrendering is hard. Even with this data the UI is pretty useless, but at\nleast it's not actually missing.\n\nBy combining Subspace and BIP70 we can finally replace the payments list UI\nwith actual proper metadata that isn't extracted from the block chain, and\nat that point non-scanning architectures become a lot more deployable.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150220/3e911e29/attachment.html\u003e"}