Braydon Fuller [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-08 📝 Original message: On 5/5/20 5:31 PM, ...
📅 Original date posted:2020-05-08
📝 Original message:
On 5/5/20 5:31 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> Hi Antoine,
>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/headers,
>> that means you're asking 1PB/month of traffic to the backbone network. If
>> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
>> signal BIP 157, that's an increase of 100GB/month for each. Which is
>> consequent with regards to the estimated cost of 350GB/month for running
>> an actual public node
> One really dope thing about BIP 157+158, is that the protocol makes serving
> light clients now _stateless_, since the full node doesn't need to perform
> any unique work for a given client. As a result, the entire protocol could
> be served over something like HTTP, taking advantage of all the established
> CDNs and anycast serving infrastructure, which can reduce syncing time
> (less latency to
> fetch data) and also more widely distributed the load of light clients using
> the existing web infrastructure. Going further, with HTTP/2's server-push
> capabilities, those serving this data can still push out notifications for
> new headers, etc.
The statelessness of compact block filters does look useful. Bloom
filters for
blocks can be inefficient, during a scan with a BIP37 wallet, it's
necessary to
discard already received merkle blocks as the filter has been updated
and the
previous results may have missed transactions. Both bitcoinj [1] and
breadwallet-core [2] handle it using a similar method. The alternative of
synchronizing and alternating between requesting blocks and filter
updates leads
to slow scan times. With compact block filters, a separate wallet
process (from
the full node) can make adjustments necessary to what it needs to filter
without
having to communicate with the full node.
[1]:
https://github.com/bitcoinj/bitcoinj/blob/806afa04419ebdc3c15d5adf065979aa7303e7f6/core/src/main/java/org/bitcoinj/core/Peer.java#L1076-L1079
[2]:
https://github.com/breadwallet/breadwallet-core/blob/8eb05454df3e2d5cca248b4e24eeffa420c97e3a/bitcoin/BRPeer.c#L83-L85
📝 Original message:
On 5/5/20 5:31 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> Hi Antoine,
>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/headers,
>> that means you're asking 1PB/month of traffic to the backbone network. If
>> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
>> signal BIP 157, that's an increase of 100GB/month for each. Which is
>> consequent with regards to the estimated cost of 350GB/month for running
>> an actual public node
> One really dope thing about BIP 157+158, is that the protocol makes serving
> light clients now _stateless_, since the full node doesn't need to perform
> any unique work for a given client. As a result, the entire protocol could
> be served over something like HTTP, taking advantage of all the established
> CDNs and anycast serving infrastructure, which can reduce syncing time
> (less latency to
> fetch data) and also more widely distributed the load of light clients using
> the existing web infrastructure. Going further, with HTTP/2's server-push
> capabilities, those serving this data can still push out notifications for
> new headers, etc.
The statelessness of compact block filters does look useful. Bloom
filters for
blocks can be inefficient, during a scan with a BIP37 wallet, it's
necessary to
discard already received merkle blocks as the filter has been updated
and the
previous results may have missed transactions. Both bitcoinj [1] and
breadwallet-core [2] handle it using a similar method. The alternative of
synchronizing and alternating between requesting blocks and filter
updates leads
to slow scan times. With compact block filters, a separate wallet
process (from
the full node) can make adjustments necessary to what it needs to filter
without
having to communicate with the full node.
[1]:
https://github.com/bitcoinj/bitcoinj/blob/806afa04419ebdc3c15d5adf065979aa7303e7f6/core/src/main/java/org/bitcoinj/core/Peer.java#L1076-L1079
[2]:
https://github.com/breadwallet/breadwallet-core/blob/8eb05454df3e2d5cca248b4e24eeffa420c97e3a/bitcoin/BRPeer.c#L83-L85