public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: John Newbery <john@johnnewbery.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 6 May 2020 05:21:17 -0400	[thread overview]
Message-ID: <CALZpt+E9A6uNJrcjz7GGz_dh6BosJybu4YRyJ4PvCB++c2Ocfg@mail.gmail.com> (raw)
In-Reply-To: <CAOV-6Td2M-zSCrPvUKVOD39C2dMf5ORFR-+YiSjUddULKkHpxA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5362 bytes --]

> The choice between whether we offer them a light client technology that
is better or worse for privacy and scalability.

And offer them a solution which would scale in the long-term.

Again it's not an argumentation against BIP 157 protocol in itself, the
problem I'm interested in is how implementing BIP157 in Core will address
this issue ?

Le mar. 5 mai 2020 à 13:36, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> There doesn't seem to be anything in the original email that's specific to
> BIP 157. It's a restatement of the arguments against light clients:
>
> - light clients are a burden on the full nodes that serve them
> - if light clients become more popular, there won't be enough full nodes
> to serve them
> - people might build products that depend on altruistic nodes serving
> data, which is unsustainable
> - maybe at some point in the future, light clients will need to pay for
> services
>
> The choice isn't between people using light clients or not. People already
> use light clients. The choice between whether we offer them a light client
> technology that is better or worse for privacy and scalability.
>
> The arguments for why BIP 157 is better than the existing light client
> technologies are available elsewhere, but to summarize:
>
> - they're unique for a block, which means they can easily be cached.
> Serving a filter requires no computation, just i/o (or memory access for
> cached filter/header data) and bandwidth. There are plenty of other
> services that a full node offers that use i/o and bandwidth, such as
> serving blocks.
> - unique-for-block means clients can download from multiple sources
> - the linked-headers/filters model allows hybrid approaches, where headers
> checkpoints can be fetched from trusted/signed nodes, with intermediate
> headers and filters fetched from untrusted sources
> - less possibilities to DoS/waste resources on the serving node
> - better for privacy
>
> > The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients
>
> Please. No-one is forcing anyone to do anything. To serve filters, a node
> user needs to download the latest version, set `-blockfilterindex=basic` to
> build the compact filters index, and set `-peercfilters` to serve them over
> P2P. This is an optional, off-by-default feature.
>
> Regards,
> John
>
>
> On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning ariard and luke-jr
>>
>>
>> > > Trust-minimization of Bitcoin security model has always relied first
>> and
>> > > above on running a full-node. This current paradigm may be shifted by
>> LN
>> > > where fast, affordable, confidential, censorship-resistant payment
>> services
>> > > may attract a lot of adoption without users running a full-node.
>> >
>> > No, it cannot be shifted. This would compromise Bitcoin itself, which
>> for
>> > security depends on the assumption that a supermajority of the economy
>> is
>> > verifying their incoming transactions using their own full node.
>> >
>> > The past few years has seen severe regressions in this area, to the
>> point
>> > where Bitcoin's future seems quite bleak. Without serious improvements
>> to the
>> > full node ratio, Bitcoin is likely to fail.
>> >
>> > Therefore, all efforts to improve the "full node-less" experience are
>> harmful,
>> > and should be actively avoided. BIP 157 improves privacy of fn-less
>> usage,
>> > while providing no real benefits to full node users (compared to more
>> > efficient protocols like Stratum/Electrum).
>> >
>> > For this reason, myself and a few others oppose merging support for BIP
>> 157 in
>> > Core.
>>
>> BIP 157 can be implemented as a separate daemon that processes the blocks
>> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>>
>> The intention, as I understood it, of putting BIP157 directly into
>> bitcoind was to essentially force all `bitcoind` users to possibly service
>> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
>> fullnode to get BIP157 service.
>> This is supposed to improve to the situation relative to e.g. Electrum,
>> where there are far fewer Electrum servers than fullnodes.
>>
>> Of course, as ariard computes, deploying BIP157 could lead to an
>> effective DDoS on the fullnode network if a large number of BIP157 clients
>> arise.
>> Though maybe this will not occur very fast?  We hope?
>>
>> It seems to me that the thing that *could* be done would be to have
>> watchtowers provide light-client services, since that seems to be the major
>> business model of watchtowers, as suggested by ariard as well.
>> This is still less than ideal, but maybe is better than nothing.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6571 bytes --]

  reply	other threads:[~2020-05-06  9:21 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 [this message]
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
     [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=CALZpt+E9A6uNJrcjz7GGz_dh6BosJybu4YRyJ4PvCB++c2Ocfg@mail.gmail.com \
    --to=antoine.riard@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=john@johnnewbery.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