📅 Original date posted:2023-04-18
🗒️ Summary of this message: The `savemempool` RPC can be used to load the mempool directly by the client, minimizing data transfer for lite clients on metered or bandwidth-limited connections.
📝 Original message:> When serving trusted clients one alternative might be to use the
> `savemempool` RPC, which can then be loaded directly (in whole) by the
> client.
It was common in the past for lightweight clients to load a BIP37 filter
and then send a `getdata` for requesting `mempool`. In that case, the
node would filter the mempool transactions and only send transactions
matching the filter to the client (plus false positives, which the
client could choose to keep very low).
The above approach minimized the amount of data that needed to be
transferred, which can be very important for lite clients on metered or
bandwidth-limited connections---especially considering that lite clients
on poor connections (e.g. mobile) might get disconnected frequently and
so need to re-request the filtered mempool every time they reconnect to
acquire any new unconfirmed transactions that arrived while they were
disconnected.
By comparison, during a period of backlog (the natural state, we hope),
the mempool contents in the `savemempool` format are about 300 MB. I
think that's a bit much to potentially be sending to lite clients just
so they can learn about any unconfirmed transactions which arrived since
they last connected.
Although I understand and support the desire to remove problematic
public interfaces like BIP37 and BIP35, I think we should also be aiming
to build interfaces which make it easier for people to use third-party
wallets with their own trusted nodes. Right now, it's possible to
use[*]
`getheaders`, BIP157/8, and `getdata(block)` with your own node to learn
about all confirmed transactions affecting your wallet. It's also
possible now to use BIP37 and BIP35 to get unconfirmed transactions in
a bandwidth-efficient manner, if your connection is allowlisted.
I would personally like to see lite clients that use a trusted node
receive a replacement for BIP35/7 support before those protocols are
removed. (Of course, I'd also like to see support for BIP324 and for
something like countersign so that authenticated and encrypted
connections from a lite client to a trusted node are easy to setup.)
Thanks,
-Dave
[*]: Requires an authenticated connection to be secure (and should
ideally be encrypted).
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-07 23:20:33
in reply to nevent1q…vltf
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:20:33Event JSON
{
"id": "ac6eba38ba4a9edbfdacfd80cc16da0e8d99e74a8929ba64bf7350e54741664d",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686180033,
"kind": 1,
"tags": [
[
"e",
"296cc26a141f097a3c7c0ba48a2e41ce84cdca00a4cb80bca4396b9808f37f4d",
"",
"root"
],
[
"e",
"474909faadb196f23d5ed2a1d5259199334edd73eb5c9870c37c4cda1e32f42a",
"",
"reply"
],
[
"p",
"54f1e8732767f848d9e10c672fec6ba5ec3628aa9c7307f9a90019a163b1dee8"
]
],
"content": "📅 Original date posted:2023-04-18\n🗒️ Summary of this message: The `savemempool` RPC can be used to load the mempool directly by the client, minimizing data transfer for lite clients on metered or bandwidth-limited connections.\n📝 Original message:\u003e When serving trusted clients one alternative might be to use the\n\u003e `savemempool` RPC, which can then be loaded directly (in whole) by the\n\u003e client.\n\nIt was common in the past for lightweight clients to load a BIP37 filter\nand then send a `getdata` for requesting `mempool`. In that case, the\nnode would filter the mempool transactions and only send transactions\nmatching the filter to the client (plus false positives, which the\nclient could choose to keep very low).\n\nThe above approach minimized the amount of data that needed to be\ntransferred, which can be very important for lite clients on metered or\nbandwidth-limited connections---especially considering that lite clients\non poor connections (e.g. mobile) might get disconnected frequently and\nso need to re-request the filtered mempool every time they reconnect to\nacquire any new unconfirmed transactions that arrived while they were\ndisconnected.\n\nBy comparison, during a period of backlog (the natural state, we hope),\nthe mempool contents in the `savemempool` format are about 300 MB. I\nthink that's a bit much to potentially be sending to lite clients just\nso they can learn about any unconfirmed transactions which arrived since\nthey last connected.\n\nAlthough I understand and support the desire to remove problematic\npublic interfaces like BIP37 and BIP35, I think we should also be aiming\nto build interfaces which make it easier for people to use third-party\nwallets with their own trusted nodes. Right now, it's possible to \nuse[*]\n`getheaders`, BIP157/8, and `getdata(block)` with your own node to learn\nabout all confirmed transactions affecting your wallet. It's also\npossible now to use BIP37 and BIP35 to get unconfirmed transactions in\na bandwidth-efficient manner, if your connection is allowlisted.\n\nI would personally like to see lite clients that use a trusted node\nreceive a replacement for BIP35/7 support before those protocols are\nremoved. (Of course, I'd also like to see support for BIP324 and for\nsomething like countersign so that authenticated and encrypted\nconnections from a lite client to a trusted node are easy to setup.)\n\nThanks,\n\n-Dave\n\n[*]: Requires an authenticated connection to be secure (and should\n ideally be encrypted).",
"sig": "da3cc5fdc0760d97e81493f763e8ae1ed4b1ef34d53945002cafdc1e8cc175bdcd3a044d7d0d1e5a12cae59963352854cb82ef2c3fccc8a341bf0ecf6a66db5e"
}