{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-06-09\n📝 Original message:On Fri, Jun 08, 2018 at 04:35:29PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote:\n\u003e   2. Since the coinbase transaction is the first in a block, it has the\n\u003e      longest merkle proof path. As a result, it may be several hundred bytes\n\u003e      (and grows with future capacity increases) to present a proof to the\n\u003e      client.\n\nI'm not sure why commitment proof size is a significant issue.  Doesn't\nthe current BIP157 protocol have each filter commit to the filter for\nthe previous block?  If that's the case, shouldn't validating the\ncommitment at the tip of the chain (or buried back whatever number of\nblocks that the SPV client trusts) obliviate the need to validate the\ncommitments for any preceeding blocks in the SPV trust model?\n\n\u003e Depending on the composition of blocks, this may outweigh the gains\n\u003e had from taking advantage of the additional compression the prev outs\n\u003e allow.\n\nI think those are unrelated points.  The gain from using a more\nefficient filter is saved bytes.  The gain from using block commitments\nis SPV-level security---that attacks have a definite cost in terms of\ngenerating proof of work instead of the variable cost of network\ncompromise (which is effectively free in many situations).\n\nComparing the extra bytes used by block commitments to the reduced bytes\nsaved by prevout+output filters is like comparing the extra bytes used\nto download all blocks for full validation to the reduced bytes saved by\nonly checking headers and merkle inclusion proofs in simplified\nvalidation.  Yes, one uses more bytes than the other, but they're\ncompletely different security models and so there's no normative way for\none to \"outweigh the gains\" from the other.\n\n\u003e So should we optimize for the ability to validate in a particular\n\u003e model (better security), or lower bandwidth in this case?\n\nIt seems like you're claiming better security here without providing any\nevidence for it.  The security model is \"at least one of my peers is\nhonest.\"  In the case of outpoint+output filters, when a client receives\nadvertisements for different filters from different peers, it:\n\n    1. Downloads the corresponding block\n    2. Locally generates the filter for that block\n    3. Kicks any peers that advertised a different filter than what it\n       generated locally\n\nThis ensures that as long as the client has at least one honest peer, it\nwill see every transaction affecting its wallet.  In the case of\nprevout+output filters, when a client receives advertisements for\ndifferent filters from different peers, it:\n\n    1. Downloads the corresponding block and checks it for wallet\n       transactions as if there had been a filter match\n\nThis also ensures that as long as the client has at least one honest\npeer, it will see every transaction affecting its wallet.  This is\nequivilant security.\n\nIn the second case, it's possible for the client to eventually\nprobabalistically determine which peer(s) are dishonest and kick them.\nThe most space efficient of these protocols may disclose some bits of\nevidence for what output scripts the client is looking for, but a\nslightly less space-efficient protocol simply uses randomly-selected\noutputs saved from previous blocks to make the probabalistic\ndetermination (rather than the client's own outputs) and so I think\nshould be quite private.  Neither protocol seems significantly more\ncomplicated than keeping an associative array recording the number of\nfalse positive matches for each peer's filters.\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/ff14b111/attachment.sig\u003e"}