{"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:Hi sipa,\n\n\u003e The advantage of (a) is that it can be verified against a full block\nwithout\n\u003e access to the outputs being spent by it\n\u003e\n\u003e The advantage of (b) is that it is more compact (scriot reuse, and outputs\n\u003e spent within the same block as they are created).\n\nThanks for this breakdown. I think you've accurately summarized the sole\nremaining discussing point in this thread.\n\nAs someone who's written and reviews code integrating the proposal all the\nway up the stack (from node to wallet, to application), IMO, there's no\nimmediate cost to deferring the inclusion/creation of a filter that includes\nprev scripts (b) instead of the outpoint as the \"regular\" filter does now.\nSwitching to prev script in the _short term_ would be costly for the set of\napplications already deployed (or deployed in a minimal or flag flip gated\nfashion) as the move from prev script to outpoint is a cascading one that\nimpacts wallet operation, rescans, HD seed imports, etc.\n\nMaintaining the outpoint also allows us to rely on a \"single honest peer\"\nsecurity model in the short term. In the long term the main barrier to\ncommitting the filters isn't choosing what to place in the filters (as once\nyou have the gcs code, adding/removing elements is a minor change), but the\nactual proposal to add new consensus enforced commitments to Bitcoin in the\nfirst place. Such a proposal would need to be generalized enough to allow\nseveral components to be committed, likely have versioning, and also provide\nthe necessary extensibility to allow additional items to be committed in the\nfuture. To my knowledge no such soft-fork has yet been proposed in a serious\nmanner, although we have years of brainstorming on the topic. The timeline\nof the drafting, design, review, and deployment of such a change would\nlikely be measures in years, compared to the immediate deployment of the\ncurrent p2p filter model proposed in the BIP.\n\nAs a result, I see no reason to delay the p2p filter deployment (with the\noutpoint) in the short term, as the long lead time a soft-fork to add\nextensible commitments to Bitcoin would give application+wallet authors\nample time to switch to the new model. Also there's no reason that full-node\nwallets which wish to primarily use the filters for rescan purposes can't\njust construct them locally for this particular use case independent of\nwhat's currently deployed on the p2p network.\n\nFinally, I've addressed the remaining comments on my PR modifying the BIP\nfrom my last message.\n\n-- Laolu\n\nOn Sat, Jun 2, 2018 at 11:12 PM Pieter Wuille via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Sat, Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Lighter but SPV secure nodes (filter committed) would help the network\n\u003e\u003e (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW.\n\u003e\u003e\n\u003e\u003e On longer term most users' security will be determined by either trusted\n\u003e\u003e hubs or POW.\n\u003e\u003e I do not know which is worse, but we should at least offer the choice to\n\u003e\u003e the user, therefore commit filters.\n\u003e\u003e\n\u003e\n\u003e I don't think that's the point of discussion here. Of course, in order to\n\u003e have filters that verifiably don't lie by omission, the filters need to be\n\u003e committed to by blocks.\n\u003e\n\u003e The question is what data that filter should contain.\n\u003e\n\u003e There are two suggestions:\n\u003e (a) The scriptPubKeys of the block's outputs, and prevouts of the block's\n\u003e inputs.\n\u003e (b) The scriptPubKeys of the block's outputs, and scriptPubKeys of outputs\n\u003e being spent by the block's inputs.\n\u003e\n\u003e The advantage of (a) is that it can be verified against a full block\n\u003e without access to the outputs being spent by it. This allows light clients\n\u003e to ban nodes that give them incorrect filters, but they do need to actually\n\u003e see the blocks (partially defeating the purpose of having filters in the\n\u003e first place).\n\u003e\n\u003e The advantage of (b) is that it is more compact (scriot reuse, and outputs\n\u003e spent within the same block as they are created). It also had the advantage\n\u003e of being more easily usable for scanning of a wallet's transactions. Using\n\u003e (a) for that in some cases may need to restart and refetch when an output\n\u003e is discovered, to go test for its spending (whose outpoint is not known\n\u003e ahead of time). Especially when fetching multiple filters at a time this\n\u003e may be an issue.\n\u003e\n\u003e I think both of these potentially good arguments. However, once a\n\u003e committed filter exists, the advantage of (a) goes away completely -\n\u003e validation of committed filters is trivial and can be done without needing\n\u003e the full blocks in the first place.\n\u003e\n\u003e So I think the question is do we aim for an uncommitted (a) first and a\n\u003e committed (b) later, or go for (b) immediately?\n\u003e\n\u003e Cheers,\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180607/835cc319/attachment-0001.html\u003e"}