{"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-08\n📝 Original message:\u003e That in argument against adopting the inferior version, as that will\n\u003e contribute more momentum to doing it in a way that doesn't make sense long\n\u003e term.\n\nThat was moreso an attempt at a disclosure, rather than may argument. But\nalso as noted further up in the thread, both approaches have a trade off:\none is better for light clients in a p2p \"one honest peer mode\", while the\nother is more compact, but is less verifiable for the light clients. They're\n\"inferior\" in different ways.\n\nMy argument goes more like: moving to prev scripts means clients cannot\nverify in full unless a block message is added to include the prev outs.\nThis is a downgrade assuming a \"one honest peer\" model for the p2p\ninteractions. A commitment removes this drawback, but ofc requires a soft\nfork. Soft forks take a \"long\" time to deploy. So what's the cost in using\nthe current filter (as it lets the client verify the filter if they want to,\nor in an attempted \"bamboozlement\" scenario) in the short term (as we don't\nyet have a proposal for committing the filters) which would allow us to\nexperiment more with the technique on mainnet before making the step up to\ncommitting the filter. Also, depending on the way the commitment is done,\nthe filters themselves would need to be modified.\n\n\u003e I don't agree at all, and I can't see why you say so.\n\nSure it doesn't _have_ to, but from my PoV as \"adding more commitments\" is\non the top of every developers wish list for additions to Bitcoin, it would\nmake sense to coordinate on an \"ultimate\" extensible commitment once, rather\nthan special case a bunch of distinct commitments. I can see arguments for\neither really.\n\n\u003e This is inherent in how e.g. the segwit commitment is encoded, the initial\n\u003e bytes are an identifying cookies. Different commitments would have\ndifferent\n\u003e cookies.\n\nIndeed, if the filter were to be committed, using an output on the coinbase\nwould be a likely candidate. However, I see two issues with this:\n\n  1. The current filter format (even moving to prevouts) cannot be committed\n     in this fashion as it indexes each of the coinbase output scripts. This\n     creates a circular dependency: the commitment is modified by the\n     filter, which is modified by the commitment (the filter atm indexes the\n     commitment). So we'd need to add a special case to skip outputs with a\n     particular witness magic. However, we don't know what that witness\n     magic looks like (as there's no proposal). As a result, the type\n     filters that can be served over the p2p network may be distinct from\n     the type of filters that are to be committed, as the commitment may\n     have an impact on the filter itself.\n\n  2. Since the coinbase transaction is the first in a block, it has the\n     longest merkle proof path. As a result, it may be several hundred bytes\n     (and grows with future capacity increases) to present a proof to the\n     client. Depending on the composition of blocks, this may outweigh the\n     gains had from taking advantage of the additional compression the prev\n     outs allow.\n\nIn regards to the second item above, what do you think of the old Tier Nolan\nproposal [1] to create a \"constant\" sized proof for future commitments by\nconstraining the size of the block and placing the commitments within the\nlast few transactions in the block?\n\n\u003e but with an added advantage of permitting expirementation ahead of the\n\u003e commitment.\n\nIndeed! To my knowledge, lnd is the only software deployed that even has\ncode to experiment with the filtering proposal in general. Also, as I\npointed out above, we may require an additional modification in order to be\nable to commit the filter. The nature of that modification may depend on how\nthe filter is to be committed. As a result, why hinder experimentation today\n(since it might need to be changed anyway, and as you point out the filter\nbeing committed can even be swapped) by delaying until we know what the\ncommitment will look like?\n\n\u003e You can still scan blocks directly when peers disagree on the filter\n\u003e content, regardless of how the filter is constructed\n\nBut the difference is that one options lets you fully construct the filter\nfrom a block, while the other requires additional data.\n\n\u003e but it makes the attack ineffective and using outpoints considerably\nincreases\n\u003e bandwidth for everyone without an attack\n\nSo should we optimize for the ability to validate in a particular model\n(better\nsecurity), or lower bandwidth in this case? It may also be the case that the\noverhead of receiving proofs of the commitment outweigh the savings\ndepending\non block composition (ofc entire block that re-uses the same address is\nsuper\nsmall).\n\n\u003e It seems to me this point is being overplayed, especially considering the\n\u003e current state of non-existing validation in SPV software (if SPV software\n\u003e doesn't validate anything else they could be validating, why would they\n\u003e implement a considerable amount of logic for this?).\n\nI don't think its fair to compare those that wish to implement this proposal\n(and actually do the validation) to the legacy SPV software that to my\nknowledge is all but abandoned. The project I work on that seeks to deploy\nthis proposal (already has, but mainnet support is behind a flag as I\nanticipated further modifications) indeed has implemented the \"considerable\"\namount of logic to check for discrepancies and ban peers trying to bamboozle\nthe light clients. I'm confident that the other projects seeking to\nimplement\nthis (rust-bitcoin-spv, NBitcoin, bcoin, maybe missing a few too) won't\nfind it\ntoo difficult to implement \"full\" validation, as they're bitcoin developers\nwith quite a bit of experience.\n\nI think we've all learned from the past defects of past light clients, and\ndon't seek to repeat history by purposefully implementing as little\nvalidation\nas possible. With these new projects by new authors, I think we have an\nopprotunity to implement light clients \"correctly\" this time around.\n\n[1]:\nhttps://github.com/TierNolan/bips/blob/00a8d3e1ac066ce3728658c6c40240e1c2ab859e/bip-aux-header.mediawiki\n\n-- Laolu\n\n\nOn Fri, Jun 8, 2018 at 9:14 AM Gregory Maxwell \u003cgreg at xiph.org\u003e wrote:\n\n\u003e On Fri, Jun 8, 2018 at 5:03 AM, Olaoluwa Osuntokun via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e As someone who's written and reviews code integrating the proposal all\n\u003e the\n\u003e \u003e way up the stack (from node to wallet, to application), IMO, there's no\n\u003e \u003e immediate cost to deferring the inclusion/creation of a filter that\n\u003e includes\n\u003e \u003e prev scripts (b) instead of the outpoint as the \"regular\" filter does\n\u003e now.\n\u003e \u003e Switching to prev script in the _short term_ would be costly for the set\n\u003e of\n\u003e \u003e applications already deployed (or deployed in a minimal or flag flip\n\u003e gated\n\u003e \u003e fashion) as the move from prev script to outpoint is a cascading one that\n\u003e \u003e impacts wallet operation, rescans, HD seed imports, etc.\n\u003e\n\u003e It seems to me that you're making the argument against your own case\n\u003e here: I'm reading this as a \"it's hard to switch so it should be done\n\u003e the inferior way\".  That in argument against adopting the inferior\n\u003e version, as that will contribute more momentum to doing it in a way\n\u003e that doesn't make sense long term.\n\u003e\n\u003e \u003e Such a proposal would need to be generalized enough to allow several\n\u003e components to be committed,\n\u003e\n\u003e I don't agree at all, and I can't see why you say so.\n\u003e\n\u003e \u003e likely have versioning,\n\u003e\n\u003e This is inherent in how e.g. the segwit commitment is encoded, the\n\u003e initial bytes are an identifying cookies. Different commitments would\n\u003e have different cookies.\n\u003e\n\u003e \u003e and also provide the necessary extensibility to allow additional items\n\u003e to be committed in the future\n\u003e\n\u003e What was previously proposed is that the commitment be required to be\n\u003e consistent if present but not be required to be present.  This would\n\u003e allow changing whats used by simply abandoning the old one.  Sparsity\n\u003e in an optional commitment can be addressed when there is less than\n\u003e 100% participation by having each block that includes a commitment\n\u003e commit to the missing filters ones from their immediate ancestors.\n\u003e\n\u003e Additional optionality can be provided by the other well known\n\u003e mechanisms,  e.g. have the soft fork expire at a block 5 years out\n\u003e past deployment, and continue to soft-fork it in for a longer term so\n\u003e long as its in use (or eventually without expiration if its clear that\n\u003e it's not going away).\n\u003e\n\u003e \u003e wallets which wish to primarily use the filters for rescan purposes can't\n\u003e \u003e just construct them locally for this particular use case independent of\n\u003e \u003e what's currently deployed on the p2p network.\n\u003e\n\u003e Absolutely, but given the failure of BIP37 on the network-- and the\n\u003e apparent strong preference of end users for alternatives that don't\n\u003e scan (e.g. electrum and web wallets)-- supporting making this\n\u003e available via P2P was already only interesting to many as a nearly\n\u003e free side effect of having filters for local scanning.  If it's a\n\u003e different filter, it's no longer attractive.\n\u003e\n\u003e It seems to me that some people have forgotten that this whole idea\n\u003e was originally proposed to be a committed data-- but with an added\n\u003e advantage of permitting expirementation ahead of the commitment.\n\u003e\n\u003e \u003e Maintaining the outpoint also allows us to rely on a \"single honest\n\u003e peer\"security model in the short term.\n\u003e\n\u003e You can still scan blocks directly when peers disagree on the filter\n\u003e content, regardless of how the filter is constructed-- yes, it uses\n\u003e more bandwidth if you're attacked, but it makes the attack ineffective\n\u003e and using outpoints considerably increases bandwidth for everyone\n\u003e without an attack.  These ineffective (except for increasing\n\u003e bandwidth) attacks would have to be common to offset the savings. It\n\u003e seems to me this point is being overplayed, especially considering the\n\u003e current state of non-existing validation in SPV software (if SPV\n\u003e software doesn't validate anything else they could be validating, why\n\u003e would they implement a considerable amount of logic for this?).\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180608/347a6539/attachment-0001.html\u003e"}