{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-06-03\n📝 Original message:On Sat, Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Lighter but SPV secure nodes (filter committed) would help the network\n\u003e (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW.\n\u003e\n\u003e On longer term most users' security will be determined by either trusted\n\u003e hubs or POW.\n\u003e I do not know which is worse, but we should at least offer the choice to\n\u003e the user, therefore commit filters.\n\u003e\n\nI don't think that's the point of discussion here. Of course, in order to\nhave filters that verifiably don't lie by omission, the filters need to be\ncommitted to by blocks.\n\nThe question is what data that filter should contain.\n\nThere are two suggestions:\n(a) The scriptPubKeys of the block's outputs, and prevouts of the block's\ninputs.\n(b) The scriptPubKeys of the block's outputs, and scriptPubKeys of outputs\nbeing spent by the block's inputs.\n\nThe advantage of (a) is that it can be verified against a full block\nwithout access to the outputs being spent by it. This allows light clients\nto ban nodes that give them incorrect filters, but they do need to actually\nsee the blocks (partially defeating the purpose of having filters in the\nfirst place).\n\nThe advantage of (b) is that it is more compact (scriot reuse, and outputs\nspent within the same block as they are created). It also had the advantage\nof being more easily usable for scanning of a wallet's transactions. Using\n(a) for that in some cases may need to restart and refetch when an output\nis discovered, to go test for its spending (whose outpoint is not known\nahead of time). Especially when fetching multiple filters at a time this\nmay be an issue.\n\nI think both of these potentially good arguments. However, once a committed\nfilter exists, the advantage of (a) goes away completely - validation of\ncommitted filters is trivial and can be done without needing the full\nblocks in the first place.\n\nSo I think the question is do we aim for an uncommitted (a) first and a\ncommitted (b) later, or go for (b) immediately?\n\nCheers,\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180602/ddc0b29e/attachment-0001.html\u003e"}