Jeff Garzik [ARCHIVE] on Nostr: ๐
Original date posted:2012-06-15 ๐ Original message:On Thu, Jun 14, 2012 at ...
๐
Original date posted:2012-06-15
๐ Original message:On Thu, Jun 14, 2012 at 7:52 AM, Mike Hearn <mike at plan99.net> wrote:
>> filterinit(false positive rate, number of elements): initialize
>> filterload(data): input a serialized bloom filter table metadata and data.
>
> Why not combine these two?
This is a fair point that sipa raised.
Consensus concluded that 'filterload' includes all necessary metadata
required to initialize a bloom filter. That implies 'filterinit'
would only be needed for 'filteradd'. If we don't think 'filteradd'
has a compelling use case, filterinit + filteradd can be dropped.
>> 'filterload' and 'filteradd' enable special behavior changes for
>> 'mempool' and existing P2P commands, whereby only transactions
>> matching the bloom filter will be announced to the connection, and
>> only matching transactions will be sent inside serialized blocks.
>
> Need to specify the format of how these arrive. It means that when a
> new block is found instead of inv<->getdata<->block we'd see something
> like ย inv<->getdata<->merkleblock where a "merkleblock" structure is a
> header + list of transactions + list of merkle branches linking them
> to the root. I think CMerkleTx already knows how to serialize this,
> but it redundantly includes the block hash which would not be
> necessary for a merkleblock message.
Yes, the format is something that must be hashed out (no pun
intended). Need input from potential users about what information
they might need.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
Published at
2023-06-07 10:12:52Event JSON
{
"id": "bd667ace1991c5428aa47f46064b8f01e16864201199bb7b57214f9192d023b3",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686132772,
"kind": 1,
"tags": [
[
"e",
"4ab728f783516dec9c5c5541517c3c7b576e19472778304e55db6fb52442f9a4",
"",
"root"
],
[
"e",
"28c6c18483f5f652f630d57c8ea756a5680d23e84a83c1e253d0368b5f28549e",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "๐
Original date posted:2012-06-15\n๐ Original message:On Thu, Jun 14, 2012 at 7:52 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e filterinit(false positive rate, number of elements): initialize\n\u003e\u003e filterload(data): input a serialized bloom filter table metadata and data.\n\u003e\n\u003e Why not combine these two?\n\nThis is a fair point that sipa raised.\n\nConsensus concluded that 'filterload' includes all necessary metadata\nrequired to initialize a bloom filter. That implies 'filterinit'\nwould only be needed for 'filteradd'. If we don't think 'filteradd'\nhas a compelling use case, filterinit + filteradd can be dropped.\n\n\u003e\u003e 'filterload' and 'filteradd' enable special behavior changes for\n\u003e\u003e 'mempool' and existing P2P commands, whereby only transactions\n\u003e\u003e matching the bloom filter will be announced to the connection, and\n\u003e\u003e only matching transactions will be sent inside serialized blocks.\n\u003e\n\u003e Need to specify the format of how these arrive. It means that when a\n\u003e new block is found instead of inv\u003c-\u003egetdata\u003c-\u003eblock we'd see something\n\u003e like ย inv\u003c-\u003egetdata\u003c-\u003emerkleblock where a \"merkleblock\" structure is a\n\u003e header + list of transactions + list of merkle branches linking them\n\u003e to the root. I think CMerkleTx already knows how to serialize this,\n\u003e but it redundantly includes the block hash which would not be\n\u003e necessary for a merkleblock message.\n\nYes, the format is something that must be hashed out (no pun\nintended). Need input from potential users about what information\nthey might need.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "5a67f47578e673bf13316223375a5fb7d63721f548dbbb60744ee6fb7dfe495a215fa69ca1dbd282bf67dcb2c0157aaa0e27869eb7e24a3ecad17f882cdcc53b"
}