{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-06-08\n📝 Original message:On Fri, Jun 8, 2018 at 5:03 AM, Olaoluwa Osuntokun via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e As someone who's written and reviews code integrating the proposal all the\n\u003e way up the stack (from node to wallet, to application), IMO, there's no\n\u003e immediate cost to deferring the inclusion/creation of a filter that includes\n\u003e prev scripts (b) instead of the outpoint as the \"regular\" filter does now.\n\u003e Switching to prev script in the _short term_ would be costly for the set of\n\u003e applications already deployed (or deployed in a minimal or flag flip gated\n\u003e fashion) as the move from prev script to outpoint is a cascading one that\n\u003e impacts wallet operation, rescans, HD seed imports, etc.\n\nIt seems to me that you're making the argument against your own case\nhere: I'm reading this as a \"it's hard to switch so it should be done\nthe inferior way\".  That in argument against adopting the inferior\nversion, as that will contribute more momentum to doing it in a way\nthat doesn't make sense long term.\n\n\u003e Such a proposal would need to be generalized enough to allow several components to be committed,\n\nI don't agree at all, and I can't see why you say so.\n\n\u003e likely have versioning,\n\nThis is inherent in how e.g. the segwit commitment is encoded, the\ninitial bytes are an identifying cookies. Different commitments would\nhave different cookies.\n\n\u003e and also provide the necessary extensibility to allow additional items to be committed in the future\n\nWhat was previously proposed is that the commitment be required to be\nconsistent if present but not be required to be present.  This would\nallow changing whats used by simply abandoning the old one.  Sparsity\nin an optional commitment can be addressed when there is less than\n100% participation by having each block that includes a commitment\ncommit to the missing filters ones from their immediate ancestors.\n\nAdditional optionality can be provided by the other well known\nmechanisms,  e.g. have the soft fork expire at a block 5 years out\npast deployment, and continue to soft-fork it in for a longer term so\nlong as its in use (or eventually without expiration if its clear that\nit's not going away).\n\n\u003e wallets which wish to primarily use the filters for rescan purposes can't\n\u003e just construct them locally for this particular use case independent of\n\u003e what's currently deployed on the p2p network.\n\nAbsolutely, but given the failure of BIP37 on the network-- and the\napparent strong preference of end users for alternatives that don't\nscan (e.g. electrum and web wallets)-- supporting making this\navailable via P2P was already only interesting to many as a nearly\nfree side effect of having filters for local scanning.  If it's a\ndifferent filter, it's no longer attractive.\n\nIt seems to me that some people have forgotten that this whole idea\nwas originally proposed to be a committed data-- but with an added\nadvantage of permitting expirementation ahead of the commitment.\n\n\u003e Maintaining the outpoint also allows us to rely on a \"single honest peer\"security model in the short term.\n\nYou can still scan blocks directly when peers disagree on the filter\ncontent, regardless of how the filter is constructed-- yes, it uses\nmore bandwidth if you're attacked, but it makes the attack ineffective\nand using outpoints considerably increases bandwidth for everyone\nwithout an attack.  These ineffective (except for increasing\nbandwidth) attacks would have to be common to offset the savings. It\nseems to me this point is being overplayed, especially considering the\ncurrent state of non-existing validation in SPV software (if SPV\nsoftware doesn't validate anything else they could be validating, why\nwould they implement a considerable amount of logic for this?)."}