public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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





  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] On the scalability issues of onboarding millions of LN mobile clients 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.io \
    --cc=antoine.riard@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=laolu32@gmail.com \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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