{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-06-01\n📝 Original message:\u003e A typical network attacker (e.g.  someone on your lan or wifi segmet, or\n\u003e someone who has compromised or operates an upstream router) can be all of\n\u003e your peers.\n\nThis is true, but it cannot make us accept any invalid filters unless the\nattacker is also creating invalid blocks w/ valid PoW.\n\n\u003e The original propsal for using these kinds of maps was that their digests\n\u003e could eventually be commited and then checked against the commitment,\n\u003e matching the same general security model used otherwise in SPV.\n\nIndeed, but no such proposal for committing the filters has emerged yet.\nSlinging filters with new p2p messages requires much less coordination that\nadding a new committed structure to Bitcoin. One could imagine that if\nconsensus exists to add new committed structures, then there may also be\ninitiatives to start to commit sig-ops, block weight, utxo's etc. As a\nresult one could imagine a much longer deployment cycle compared to a pure\np2p roll out in the near term, and many applications are looking for a\nviable alternative to BIP 37.\n\n\u003e Unfortunately, using the scripts instead of the outpoints takes us further\n\u003e away from a design that is optimized for committing (or, for that matter,\n\u003e use purely locally by a wallet)...\n\nI agree that using the prev input scripts would indeed be optimal from a\nsize perspective when the filters are to be committed. The current proposal\nmakes way for future filter types and it's likely the case that only the\nmost optimal filters should be committed (while other more niche filters\nperhaps, remain only on the p2p level).\n\n-- Laolu\n\n\nOn Thu, May 31, 2018 at 9:14 PM Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e One notable thing that I left off is the proposed change to use the\n\u003e previous\n\u003e \u003e output script rather than the outpoint. Modifying the filters in this\n\u003e \u003e fashion would be a downgrade in the security model for light clients, as\n\u003e it\n\u003e\n\u003e Only if you make a very strong assumption about the integrity of the\n\u003e nodes the client is talkign to. A typical network attacker (e.g.\n\u003e someone on your lan or wifi segmet, or someone who has compromised or\n\u003e operates an upstream router) can be all of your peers.\n\u003e\n\u003e The original propsal for using these kinds of maps was that their\n\u003e digests could eventually be commited and then checked against the\n\u003e commitment, matching the same general security model used otherwise in\n\u003e SPV.\n\u003e\n\u003e Unfortunately, using the scripts instead of the outpoints takes us\n\u003e further away from a design that is optimized for committing (or, for\n\u003e that matter, use purely locally by a wallet)...\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180601/12faacf0/attachment.html\u003e"}