{"type":"rich","version":"1.0","author_name":"npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2n","author_url":"https://nostr.ae/npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-05-17\n📝 Original message:\u003e\n\u003e It isn't a question of 'some lite clients' -- I am aware of no\n\u003e implementation of these kinds of measures in any cryptocurrency ever.\n\u003e\n\nDoesn't mean there can't or shouldn't be a first. :-)\n\n\n\u003e The same kind of comparison to the block could have been done with\n\u003e BIP37 filtering, but no one has implemented that. (similarly, the\n\u003e whitepaper suggests doing that for all network rules when a\n\u003e disagreement has been seen, though that isn't practical for all\n\u003e network rules it could be done for many of them-- but again no\n\u003e implementation or AFAIK any interest in implementing that)\n\n\nCorrect me if I'm wrong, but I don't think it's true that the same could be\ndone for BIP 37. With BIP 37, one would have to download every partial\nblock from every peer to determine if there is a difference between them.\nWith BIP 157, you only download a 32 byte filter header from every peer\n(because filters are deterministic), and using that commitment can\ndetermine whether there's a conflict requiring further interrogation. The\ndifference in overhead makes checking for conflicts with BIP 157 practical,\nwhereas it's not as practical with BIP 37.\n\n\n\u003e Sure, but at what cost?   And \"additional\" while nice doesn't\n\u003e necessarily translate into a meaningful increase in delivered security\n\u003e for any particular application.\n\u003e\n\u003e I think we might be speaking too generally here.\n\u003e\n\nSure. The security model that BIP 157 now allows is that a light client with*\nat least one honest peer serving filters* can get the correct information\nabout the chain. No, this does not prevent against total eclipse attacks,\nbut I think it's a much stronger security guarantee than requiring all\npeers or even a majority of peers to be honest. In a decentralized network\nthat stores money, I think there's a big difference between those security\nmodels.\n\n\n\u003e But in exchange the filters for a given FP rate would be probably\n\u003e about half the current size (actual measurements would be needed\n\u003e because the figure depends on much scriptpubkey reuse there is, it\n\u003e probably could be anywhere between 1/3 and 2/3rd).\n\u003e\n\nThis does not seem right. Let's assume txids are removed because they are\nnot relevant to this particular point. The difference as I understand it is\nwhether to include in the filter serialized outpoints for inputs or\nserialized prev scriptPubkeys for inputs. When hashed these are the same\nsize, and there's an equal number of them (one per input in a block). So\nthe only savings comes from deduping the prev scriptPubkeys with each other\nand with the scriptPubkeys in the block's outputs. So it comes down\nentirely to how much address reuse there is on the chain.\n\n\n\u003e Monitoring inputs by scriptPubkey vs input-txid also has a massive\n\u003e advantage for parallel filtering:  You can usually known your pubkeys\n\u003e well in advance, but if you have to change what you're watching block\n\u003e  N+1 for based on the txids that paid you in N you can't filter them\n\u003e in parallel.\n\u003e\n\nYes, I'll grant that this is a benefit of your suggestion.\n\n\n\u003e I think Peter missed Matt's point that you can monitor for a specific\n\u003e transaction's confirmation by monitoring for any of the outpoints that\n\u003e transaction contains. Because the txid commits to the outpoints there\n\u003e shouldn't be any case where the txid is knowable but (an) outpoint is\n\u003e not.  Removal of the txid and monitoring for any one of the outputs\n\u003e should be a strict reduction in the false positive rate for a given\n\u003e filter size (the filter will contain strictly fewer elements and the\n\u003e client will match for the same (or usually, fewer) number).\n\u003e\n\u003e I _think_ dropping txids as matt suggests is an obvious win that costs\n\u003e nothing.  Replacing inputs with scripts as I suggested has some\n\u003e trade-offs.\n\u003e\n\nI may have interpreted this differently. So wallets need a way to know when\nthe transactions they send get confirmed (for obvious usability reasons and\nso for automatic fee-bumping). One way is to match the spent outpoints\nagainst the filter, which I think of as the standard. Another would be to\nmatch the txid of the spending transaction against the first, which only\nworks if the transaction is not malleable. Another would be to match the\nchange output script against the first, assuming the wallet does not reuse\nchange addresses and that the spending transaction does in fact have a\nchange output.\n\nNow lets say these pieces of data, txids, output scripts, and spent\noutpoints are in three separate filters that a wallet can download\nseparately or choose not to download. The spent outpoint method is the most\nreliable and has no caviats. It also allows for theft detection as Peter\nnotes, which is a very nice property indeed. If the wallet uses the txid\nmatching though, the txid filter would be smaller because there are fewer\ntxids per block than inputs. So there could be some bandwidth savings to\nthat approach. The change output watching is probably the nicest in some\nways because the client needs the output filter anyway. If the transaction\nhas no change output with a unique script, the client could watch for any\nof the other outputs on the spending tx, but may get more false positives\ndepending on the degree of address reuse.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180517/01b8298f/attachment-0001.html\u003e"}