📅 Original date posted:2017-06-19 📝 Original message:On Mon, Jun 19, 2017 at ...

Gregory Maxwell [ARCHIVE] /

npub1f2n…rwet

2023-06-07 18:02:13

in reply to nevent1q…4rxu

📅 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.

Author Public Key

npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet

Show more details

Published at

2023-06-07 18:02:13

Kind type

1 Short Text Note

Event 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" }