{"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-12\n📝 Original message:\u003e Doesn't the current BIP157 protocol have each filter commit to the filter\n\u003e for the previous block?\n\nYep!\n\n\u003e If that's the case, shouldn't validating the commitment at the tip of the\n\u003e chain (or buried back whatever number of blocks that the SPV client\ntrusts)\n\u003e obliviate the need to validate the commitments for any preceeding blocks\nin\n\u003e the SPV trust model?\n\nYeah, just that there'll be a gap between the p2p version, and when it's\nultimately committed.\n\n\u003e It seems like you're claiming better security here without providing any\n\u003e evidence for it.\n\nWhat I mean is that one allows you to fully verify the filter, while the\nother allows you to only validate a portion of the filter and requires other\nadded heuristics.\n\n\u003e In the case of prevout+output filters, when a client receives\nadvertisements\n\u003e for different filters from different peers, it:\n\nAlternatively, they can decompress the filter and at least verify that\nproper _output scripts_ have been included. Maybe this is \"good enough\"\nuntil its committed. If a command is added to fetch all the prev outs along\nw/ a block (which would let you do another things like verify fees), then\nthey'd be able to fully validate the filter as well.\n\n-- Laolu\n\n\nOn Sat, Jun 9, 2018 at 3:35 AM David A. Harding \u003cdave at dtrt.org\u003e wrote:\n\n\u003e On Fri, Jun 08, 2018 at 04:35:29PM -0700, Olaoluwa Osuntokun via\n\u003e bitcoin-dev wrote:\n\u003e \u003e   2. Since the coinbase transaction is the first in a block, it has the\n\u003e \u003e      longest merkle proof path. As a result, it may be several hundred\n\u003e bytes\n\u003e \u003e      (and grows with future capacity increases) to present a proof to the\n\u003e \u003e      client.\n\u003e\n\u003e I'm not sure why commitment proof size is a significant issue.  Doesn't\n\u003e the current BIP157 protocol have each filter commit to the filter for\n\u003e the previous block?  If that's the case, shouldn't validating the\n\u003e commitment at the tip of the chain (or buried back whatever number of\n\u003e blocks that the SPV client trusts) obliviate the need to validate the\n\u003e commitments for any preceeding blocks in the SPV trust model?\n\u003e\n\u003e \u003e Depending on the composition of blocks, this may outweigh the gains\n\u003e \u003e had from taking advantage of the additional compression the prev outs\n\u003e \u003e allow.\n\u003e\n\u003e I think those are unrelated points.  The gain from using a more\n\u003e efficient filter is saved bytes.  The gain from using block commitments\n\u003e is SPV-level security---that attacks have a definite cost in terms of\n\u003e generating proof of work instead of the variable cost of network\n\u003e compromise (which is effectively free in many situations).\n\u003e\n\u003e Comparing the extra bytes used by block commitments to the reduced bytes\n\u003e saved by prevout+output filters is like comparing the extra bytes used\n\u003e to download all blocks for full validation to the reduced bytes saved by\n\u003e only checking headers and merkle inclusion proofs in simplified\n\u003e validation.  Yes, one uses more bytes than the other, but they're\n\u003e completely different security models and so there's no normative way for\n\u003e one to \"outweigh the gains\" from the other.\n\u003e\n\u003e \u003e So should we optimize for the ability to validate in a particular\n\u003e \u003e model (better security), or lower bandwidth in this case?\n\u003e\n\u003e It seems like you're claiming better security here without providing any\n\u003e evidence for it.  The security model is \"at least one of my peers is\n\u003e honest.\"  In the case of outpoint+output filters, when a client receives\n\u003e advertisements for different filters from different peers, it:\n\u003e\n\u003e     1. Downloads the corresponding block\n\u003e     2. Locally generates the filter for that block\n\u003e     3. Kicks any peers that advertised a different filter than what it\n\u003e        generated locally\n\u003e\n\u003e This ensures that as long as the client has at least one honest peer, it\n\u003e will see every transaction affecting its wallet.  In the case of\n\u003e prevout+output filters, when a client receives advertisements for\n\u003e different filters from different peers, it:\n\u003e\n\u003e     1. Downloads the corresponding block and checks it for wallet\n\u003e        transactions as if there had been a filter match\n\u003e\n\u003e This also ensures that as long as the client has at least one honest\n\u003e peer, it will see every transaction affecting its wallet.  This is\n\u003e equivilant security.\n\u003e\n\u003e In the second case, it's possible for the client to eventually\n\u003e probabalistically determine which peer(s) are dishonest and kick them.\n\u003e The most space efficient of these protocols may disclose some bits of\n\u003e evidence for what output scripts the client is looking for, but a\n\u003e slightly less space-efficient protocol simply uses randomly-selected\n\u003e outputs saved from previous blocks to make the probabalistic\n\u003e determination (rather than the client's own outputs) and so I think\n\u003e should be quite private.  Neither protocol seems significantly more\n\u003e complicated than keeping an associative array recording the number of\n\u003e false positive matches for each peer's filters.\n\u003e\n\u003e -Dave\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180612/295d1a52/attachment.html\u003e"}