📅 Original date posted:2016-02-17
📝 Original message:On Tue, Feb 16, 2016 at 6:46 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev wrote:
> > # The feefilter message is defined as a message containing an int64_t
> where
> > pchCommand == "feefilter"
>
> What happened to extensibility? And why waste 64 bits for what is almost
> certainly a small number?
>
I thought that extensibility was already sufficient with the command string
system. If we come up with a better version of the feefilter later we can
just give it a different command name. This seemed to encapsulate a fairly
complete idea for now. As for the 8 bytes, it didn't seem necessary to me
to over optimize with a custom encoding for what amounts to well under 20%
of ping traffic. (pings are sent every 2 mins per peer, feefilters on
average every 10 mins, but when the quantized value to be sent would be the
same it is skipped)
> > # The fee filter is additive with a bloom filter for transactions so if
> an
> > SPV client were to load a bloom filter and send a feefilter message,
> > transactions would only be relayed if they passed both filters.
>
> This seems to make feefilter entirely useless for wallets?
>
>
I don't follow this comment? Transactions aren't synced with the wallet
unless they are accepted into the mempool. Sending feefilter messages
should not reduce the number of transactions that are accepted to the
mempool.
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160216/08d950a6/attachment.html>;
Alex Morcos [ARCHIVE] /
npub10z…3xfzw
2023-06-07 17:49:12
in reply to nevent1q…fqnn
Author Public Key
npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:49:12Event JSON
{
"id": "686805e0b5bcb2969b26c6af3c2b445fcf5039218908c1dc818e578e470ddd4e",
"pubkey": "78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c",
"created_at": 1686160152,
"kind": 1,
"tags": [
[
"e",
"f76e2becbfe733698230f3abcc57efd3b02370c3c0af6e9d5741c130177d6401",
"",
"root"
],
[
"e",
"789f9da0e74e2f98062f094e738d03038443acb9a647ee2c75c44d1a8f945f4e",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-02-17\n📝 Original message:On Tue, Feb 16, 2016 at 6:46 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev wrote:\n\u003e \u003e # The feefilter message is defined as a message containing an int64_t\n\u003e where\n\u003e \u003e pchCommand == \"feefilter\"\n\u003e\n\u003e What happened to extensibility? And why waste 64 bits for what is almost\n\u003e certainly a small number?\n\u003e\n\nI thought that extensibility was already sufficient with the command string\nsystem. If we come up with a better version of the feefilter later we can\njust give it a different command name. This seemed to encapsulate a fairly\ncomplete idea for now. As for the 8 bytes, it didn't seem necessary to me\nto over optimize with a custom encoding for what amounts to well under 20%\nof ping traffic. (pings are sent every 2 mins per peer, feefilters on\naverage every 10 mins, but when the quantized value to be sent would be the\nsame it is skipped)\n\n\n\u003e \u003e # The fee filter is additive with a bloom filter for transactions so if\n\u003e an\n\u003e \u003e SPV client were to load a bloom filter and send a feefilter message,\n\u003e \u003e transactions would only be relayed if they passed both filters.\n\u003e\n\u003e This seems to make feefilter entirely useless for wallets?\n\u003e\n\u003e\nI don't follow this comment? Transactions aren't synced with the wallet\nunless they are accepted into the mempool. Sending feefilter messages\nshould not reduce the number of transactions that are accepted to the\nmempool.\n\n\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160216/08d950a6/attachment.html\u003e",
"sig": "a4715eef0d569bddffbee6f9c720399d52cd35ac27feaa0bca2f99ad675bf57533f58ae0a1db3fa4742d58bc1f04404d6a69d20f217007067a1b140d8a6eb424"
}