David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-18 🗒️ Summary of this message: The ...
📅 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).
🗒️ 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).