From: Braydon Fuller <braydon@purse•io>
To: Olaoluwa Osuntokun <laolu32@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Antoine Riard <antoine.riard@gmail•com>
Cc: "lightning-dev\\\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Date: Fri, 8 May 2020 12:33:55 -0700 [thread overview]
Message-ID: <6bd0f6ff-9c99-d5c8-f6ae-7f604ad3e273@purse.io> (raw)
In-Reply-To: <CAO3Pvs8rkouxQY912VW04pmn-hdAhMNL_6E_nXDmkeibBegwkA@mail.gmail.com>
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
next prev parent reply other threads:[~2020-05-08 20:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 10:17 [bitcoin-dev] " Antoine Riard
2020-05-05 13:00 ` Luke Dashjr
2020-05-05 13:49 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2020-05-05 17:09 ` John Newbery
2020-05-06 9:21 ` Antoine Riard
2020-05-05 15:16 ` [bitcoin-dev] " Lloyd Fournier
2020-05-12 21:05 ` Chris Belcher
2020-05-13 19:51 ` [bitcoin-dev] [Lightning-dev] " Antoine Riard
2020-05-14 4:02 ` ZmnSCPxj
[not found] ` <45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk>
2020-05-14 15:25 ` Keagan McClelland
2020-05-17 9:11 ` Christopher Allen
2020-05-14 15:27 ` William Casarin
2020-05-17 3:37 ` Antoine Riard
2020-05-06 9:06 ` [bitcoin-dev] " Antoine Riard
2020-05-06 16:00 ` [bitcoin-dev] [Lightning-dev] " Keagan McClelland
2020-05-07 3:56 ` Antoine Riard
2020-05-07 4:07 ` Keagan McClelland
2020-05-08 19:51 ` Braydon Fuller
2020-05-08 20:01 ` Keagan McClelland
2020-05-08 20:22 ` Braydon Fuller
2020-05-08 21:29 ` Christopher Allen
2020-05-09 7:48 ` Antoine Riard
2020-05-06 0:31 ` Olaoluwa Osuntokun
2020-05-06 9:40 ` Antoine Riard
[not found] ` <CACJVCgL4fAs7-F2O+T-gvTbpjsHhgBrU73FaC=EUHG5iTi2m2Q@mail.gmail.com>
2020-05-11 5:44 ` ZmnSCPxj
2020-05-12 10:09 ` Richard Myers
2020-05-12 15:48 ` ZmnSCPxj
2020-05-08 19:33 ` Braydon Fuller [this message]
[not found] ` <CAGKT+VcZsMW_5jOqT2jxtbYTEPZU-NL8v3gZ8VJAP-bMe7iLSg@mail.gmail.com>
2020-05-06 8:27 ` Antoine Riard
2020-05-07 16:40 ` Igor Cota
2020-05-09 7:22 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6bd0f6ff-9c99-d5c8-f6ae-7f604ad3e273@purse.io \
--to=braydon@purse$(echo .)io \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laolu32@gmail$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox