📅 Original date posted:2018-05-22
📝 Original message:>
> My suggestion was to advertise a bitfield for each filter type the node
> serves,
> where the bitfield indicates what elements are part of the filters. This
> essentially
> removes the notion of decided filter types and instead leaves the decision
> to
> full-nodes.
>
I think it makes more sense to construct entirely separate filters for the
different types of elements and allow clients to download only the ones
they care about. If there are enough elements per filter, the compression
ratio shouldn't be much worse by splitting them up. This prevents the
exponential blowup in the number of filters that you mention, Johan, and it
works nicely with service bits for advertising different filter types
independently.
So if we created three separate filter types, one for output scripts, one
for input outpoints, and one for TXIDs, each signaled with a separate
service bit, are people good with that? Or do you think there shouldn't be
a TXID filter at all, Matt? I didn't include the option of a prev output
script filter or rolling that into the block output script filter because
it changes the security model (cannot be proven to be correct/incorrect
succinctly).
Then there's the question of whether to separate or combine the headers.
I'd lean towards keeping them separate because it's simpler that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180522/328a953f/attachment-0001.html>;
Jim Posen [ARCHIVE] /
npub1nc…lqt2n
2023-06-07 18:12:14
in reply to nevent1q…x2nn
Author Public Key
npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2nPublished at
2023-06-07 18:12:14Event JSON
{
"id": "c9cbe2d0874d5cdd162d68161300c676a98567b4234ea3aac93f161752f8f26d",
"pubkey": "9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1",
"created_at": 1686161534,
"kind": 1,
"tags": [
[
"e",
"aefee7e3913729b7ef736d47c6f2a24954de10011f27b89dcaeaac62c51b6a6f",
"",
"root"
],
[
"e",
"e3e4cc1468eba29570cea6798608633f7ee85db68f0c5ecf24b8b794bec4ab7f",
"",
"reply"
],
[
"p",
"0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f"
]
],
"content": "📅 Original date posted:2018-05-22\n📝 Original message:\u003e\n\u003e My suggestion was to advertise a bitfield for each filter type the node\n\u003e serves,\n\u003e where the bitfield indicates what elements are part of the filters. This\n\u003e essentially\n\u003e removes the notion of decided filter types and instead leaves the decision\n\u003e to\n\u003e full-nodes.\n\u003e\n\nI think it makes more sense to construct entirely separate filters for the\ndifferent types of elements and allow clients to download only the ones\nthey care about. If there are enough elements per filter, the compression\nratio shouldn't be much worse by splitting them up. This prevents the\nexponential blowup in the number of filters that you mention, Johan, and it\nworks nicely with service bits for advertising different filter types\nindependently.\n\nSo if we created three separate filter types, one for output scripts, one\nfor input outpoints, and one for TXIDs, each signaled with a separate\nservice bit, are people good with that? Or do you think there shouldn't be\na TXID filter at all, Matt? I didn't include the option of a prev output\nscript filter or rolling that into the block output script filter because\nit changes the security model (cannot be proven to be correct/incorrect\nsuccinctly).\n\nThen there's the question of whether to separate or combine the headers.\nI'd lean towards keeping them separate because it's simpler that way.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180522/328a953f/attachment-0001.html\u003e",
"sig": "7e60968b34ba21d500c909633ba2f58af0524c3a225fd1019e6a95f38c53c26e7dca3495e58bcfac1ade76aa6b157448e8404efe19de27081bbe15903711444b"
}