{"type":"rich","version":"1.0","author_name":"npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8","author_url":"https://nostr.ae/npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-06-02\n📝 Original message:Without block commitment mobiles would have to use trusted filter provider or implement a complex data hungry algorithm and still remain as insecure as with BIP 37.\n\nYears of experience implementing wallets with BIP 37 taught us that an outpoint + output script filter is useful. Committing such a filter to the block can not be an error.\n\nWe could roll this out on P2P prior to a soft fork adding the commitment, but I would not expect its use to pick up before that.\nTherafter BIP 37 could be rightfully decommissioned, herby offering both security and privacy enhancement at modest data cost.\n\nTamas Blummer\n\n\u003e On Jun 2, 2018, at 14:41, David A. Harding via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On Fri, Jun 01, 2018 at 07:02:38PM -0700, Jim Posen via bitcoin-dev wrote:\n\u003e\u003e Without the ability to verify filter validity, a client would have to stop\n\u003e\u003e syncing altogether in the presence of just one malicious peer, which is\n\u003e\u003e unacceptable.\n\u003e \n\u003e I'm confused about why this would be the case.  If Alice's node\n\u003e generates filters accurately and Mallory's node generates filters\n\u003e inaccurately, and they both send their filters to Bob, won't Bob be able\n\u003e to download any blocks either filter indicates are relevant to his\n\u003e wallet?\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 529 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/6623601b/attachment.sig\u003e"}