Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-19 📝 Original message:On Mon, Jun 19, 2017 at ...
📅 Original date posted:2017-06-19
📝 Original message:On Mon, Jun 19, 2017 at 12:26 PM, bfd--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Several times. It's been debated if unconfirmed transactions are necessary,
> methods of doing more private filtering have been suggested, along with
> simply not filtering unconfirmed transactions at all. My collected data
> suggests that there is very little use of BIP37 at present, based on
> incoming connections to nodes I know end up in the DNS seed responses (no
> "SPV" clients do their own peer management).
Sending just the output addresses of each transaction would use about
1 kilobit/s of data. Sending the entire transactions would use
~14kbit/sec data. These don't seem to be a unsustainable tremendous
amount of data to use while an application is running.
Doubly so for SPV wallets which are highly vulnerable to unconfirmed
transactions, and many which last I heard testing reports on became
pretty severely corrupted once given a fake transaction.
Can someone make a case why saving no more than those figures would
justify the near total loss of privacy that filtering gives?
"Because they already do it" isn't a good argument when talking about
a new protocol feature; things which already do BIP37 will presumably
continue to already do BIP37.
Published at
2023-06-07 18:02:13Event JSON
{
"id": "495788491b41d87f4b57cd83620ce1b83d216a126bc5dac8896e36868e18f8f6",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686160933,
"kind": 1,
"tags": [
[
"e",
"55a56c7ebba05dd9613a9ae00ae6d5bbfa4f7fd0155fa447a7d09d61ff658a4b",
"",
"root"
],
[
"e",
"9d9f01315b086d0e4a4725cf3e0db0fa88838484d9430fcde06d882251e0f434",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2017-06-19\n📝 Original message:On Mon, Jun 19, 2017 at 12:26 PM, bfd--- via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Several times. It's been debated if unconfirmed transactions are necessary,\n\u003e methods of doing more private filtering have been suggested, along with\n\u003e simply not filtering unconfirmed transactions at all. My collected data\n\u003e suggests that there is very little use of BIP37 at present, based on\n\u003e incoming connections to nodes I know end up in the DNS seed responses (no\n\u003e \"SPV\" clients do their own peer management).\n\nSending just the output addresses of each transaction would use about\n1 kilobit/s of data. Sending the entire transactions would use\n~14kbit/sec data. These don't seem to be a unsustainable tremendous\namount of data to use while an application is running.\n\nDoubly so for SPV wallets which are highly vulnerable to unconfirmed\ntransactions, and many which last I heard testing reports on became\npretty severely corrupted once given a fake transaction.\n\nCan someone make a case why saving no more than those figures would\njustify the near total loss of privacy that filtering gives?\n\n\"Because they already do it\" isn't a good argument when talking about\na new protocol feature; things which already do BIP37 will presumably\ncontinue to already do BIP37.",
"sig": "35c316b488d9fe96861140e08a6c4619a6899f7658c57076325a1e8291a5b19d06eeaae55506b32c8a86aedf1f0803de86e83a7f50f8acb9bef6dfc9eaa33d24"
}