rich1.0npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdhttps://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdnjumphttps://nostr.ae📅 Original date posted:2018-06-09 📝 Original message:On Fri, Jun 08, 2018 at 04:35:29PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote: > 2. Since the coinbase transaction is the first in a block, it has the > longest merkle proof path. As a result, it may be several hundred bytes > (and grows with future capacity increases) to present a proof to the > client. I'm not sure why commitment proof size is a significant issue. Doesn't the current BIP157 protocol have each filter commit to the filter for the previous block? If that's the case, shouldn't validating the commitment at the tip of the chain (or buried back whatever number of blocks that the SPV client trusts) obliviate the need to validate the commitments for any preceeding blocks in the SPV trust model? > Depending on the composition of blocks, this may outweigh the gains > had from taking advantage of the additional compression the prev outs > allow. I think those are unrelated points. The gain from using a more efficient filter is saved bytes. The gain from using block commitments is SPV-level security---that attacks have a definite cost in terms of generating proof of work instead of the variable cost of network compromise (which is effectively free in many situations). Comparing the extra bytes used by block commitments to the reduced bytes saved by prevout+output filters is like comparing the extra bytes used to download all blocks for full validation to the reduced bytes saved by only checking headers and merkle inclusion proofs in simplified validation. Yes, one uses more bytes than the other, but they're completely different security models and so there's no normative way for one to "outweigh the gains" from the other. > So should we optimize for the ability to validate in a particular > model (better security), or lower bandwidth in this case? It seems like you're claiming better security here without providing any evidence for it. The security model is "at least one of my peers is honest." In the case of outpoint+output filters, when a client receives advertisements for different filters from different peers, it: 1. Downloads the corresponding block 2. Locally generates the filter for that block 3. Kicks any peers that advertised a different filter than what it generated locally This ensures that as long as the client has at least one honest peer, it will see every transaction affecting its wallet. In the case of prevout+output filters, when a client receives advertisements for different filters from different peers, it: 1. Downloads the corresponding block and checks it for wallet transactions as if there had been a filter match This also ensures that as long as the client has at least one honest peer, it will see every transaction affecting its wallet. This is equivilant security. In the second case, it's possible for the client to eventually probabalistically determine which peer(s) are dishonest and kick them. The most space efficient of these protocols may disclose some bits of evidence for what output scripts the client is looking for, but a slightly less space-efficient protocol simply uses randomly-selected outputs saved from previous blocks to make the probabalistic determination (rather than the client's own outputs) and so I think should be quite private. Neither protocol seems significantly more complicated than keeping an associative array recording the number of false positive matches for each peer's filters. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/ff14b111/attachment.sig>