Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4C193C0859; Wed, 6 May 2020 09:21:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 396C1204D8; Wed, 6 May 2020 09:21:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59M97BxhUr9K; Wed, 6 May 2020 09:21:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by silver.osuosl.org (Postfix) with ESMTPS id 658AA24C8F; Wed, 6 May 2020 09:21:30 +0000 (UTC) Received: by mail-pl1-f177.google.com with SMTP id k19so237322pll.9; Wed, 06 May 2020 02:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hTA+czHivxCTsILSakeUB6zzAZtLhdK3663QqqfVsGQ=; b=C9izuxUxA+9DGdNtECXP8qA+osopVG8dgd2zl1zdHcnETOJa3EfAAKLMizkHqO4yoL 1IY4LExGtY/Mu9/KfjVfu//H3CTlbBL1jlJJDgKcRUGVfX68YFc6QB1yOObxox9C2ne6 AYpx57o6DirMDpiRMWem+3feBcifE3WweYN9TChdmVpN1/boGDswaqG8n3BDJ/QzIZBq tbjHLnVxYT9L3PxgHSVo4xkauwW59M0zjhZzTQ5saYwPxhlozpXQ0me1vOWPo1cFDOz9 Y49KI8VjKGXFbjvOsUKYDTrwogsSqUYflxivHQycyUhwCELdk/CMJB5WgtYWPpSiy9Ej F/Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hTA+czHivxCTsILSakeUB6zzAZtLhdK3663QqqfVsGQ=; b=hM+vSWYElkn8VJzDB0SWUsQ0dkyBSnzLsV74LuOjRf2w6nSv7LVsUrg60uy8uTqUlx tN1bcj0aFwX08lYvWXxVETPazr4jF0iKkrcrVT2PxUTrInHeV6HMRhzN3BdzwkHksqOU HjKq0lfvrABA8aXzd1yWjePMrveaYG6/8ekyJAi57qnBPFmDtoxngEzPcmO+Np8ZNQWr YV0Ho8T7O8H39WuPvaeiqQMZFbbtrv7ijLxfWn1gubPzvJV0gB0YWcl7nua5abJ+MTGj AfQYZH5X11zVXQv9yps1zZnpaqEyRMclHHnuGqTV10UzNUjFtt+UEUP4RMz9oHPOKSAR mfCg== X-Gm-Message-State: AGi0PubBK1Eoc5O0kybJfsGz4vPk/siofYyLnA0G6l1tD5eiWWcgGirG 3VtO64SSZa5RQ214RyMpO7mS1N+wq07l1iZ/1KU= X-Google-Smtp-Source: APiQypIZIZJkDezavtME//o630LYwEZzdkWdPPeZfrDzK9F+9xVE4jHcSNkO9t4YLl4mBc1Px4p2j2AHDrniAetFrQQ= X-Received: by 2002:a17:90a:2365:: with SMTP id f92mr7877650pje.117.1588756889882; Wed, 06 May 2020 02:21:29 -0700 (PDT) MIME-Version: 1.0 References: <202005051300.38836.luke@dashjr.org> <0rqLsMOBB7orpGYsND4YHp3y6JBLUxiezAdD11oxcOlpVipbll6Iq8JNiWYTt5MFr8V11DdVgimN8ptvJUr6B-qntHhR4m4MBGiAEiSHG1A=@protonmail.com> In-Reply-To: From: Antoine Riard Date: Wed, 6 May 2020 05:21:17 -0400 Message-ID: To: John Newbery , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000000e534c05a4f74a11" X-Mailman-Approved-At: Wed, 06 May 2020 13:25:00 +0000 Cc: "lightning-dev\\\\\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 09:21:32 -0000 --0000000000000e534c05a4f74a11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 =C3=A0 13:36, John Newbery via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > There doesn't seem to be anything in the original email that's specific t= o > 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 alread= y > use light clients. The choice between whether we offer them a light clien= t > 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 header= s > 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 servic= e > 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=3Dbasic= ` to > build the compact filters index, and set `-peercfilters` to serve them ov= er > 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 b= y >> 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 BI= P >> 157 in >> > Core. >> >> BIP 157 can be implemented as a separate daemon that processes the block= s >> 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 servi= ce >> BIP157 clients, in the hope that a BIP157 client can contact any arbitra= ry >> 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 clien= ts >> 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 ma= jor >> 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 > --0000000000000e534c05a4f74a11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> 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=C2=A0mar. 5 mai 2020 =C3=A0=C2=A013:3= 6, John Newbery via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9cri= t=C2=A0:
There doesn't seem to be anything in the original email that&= #39;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&= #39;t be enough full nodes to serve them
- people might build products t= hat depend on altruistic nodes serving data, which is unsustainable
- ma= ybe at some point in the future, light clients will need to pay for service= s

The choice isn't between=C2=A0people usi= ng light clients or not. People already use light clients. The choice betwe= en 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 availabl= e elsewhere, but to summarize:

- they're uniqu= e for a block, which means they can easily be cached. Serving a filter requ= ires no computation, just i/o (or memory access for cached filter/header da= ta) and bandwidth. There are plenty of other services that a full node offe= rs that=C2=A0use i/o and bandwidth, such as serving blocks.
- unique-for= -block means clients can download from multiple sources
- the lin= ked-headers/filters model allows hybrid approaches, where headers checkpoin= ts 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

>=C2=A0The intention, as I understood it, of putting BIP157 dir= ectly into bitcoind was to essentially force all `bitcoind` users to possib= ly service BIP157 clients

Please. No-one is forcin= g anyone to do anything. To serve filters, a node user=C2=A0needs to downlo= ad the latest version, set `-blockfilterindex=3Dbasic` 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 b= itcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Good morning ariard and= luke-jr


> > Trust-minimization of Bitcoin security model has always relied fi= rst and
> > above on running a full-node. This current paradigm may be shifte= d by LN
> > where fast, affordable, confidential, censorship-resistant paymen= t services
> > may attract a lot of adoption without users running a full-node.<= br> >
> 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 po= int
> where Bitcoin's future seems quite bleak. Without serious improvem= ents to the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" exper= ience are harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less us= age,
> while providing no real benefits to full node users (compared to more<= br> > efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BI= P 157 in
> Core.

BIP 157 can be implemented as a separate daemon that processes the blocks d= ownloaded 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 c= lients, 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, whe= re 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?=C2=A0 We hope?

It seems to me that the thing that *could* be done would be to have watchto= wers provide light-client services, since that seems to be the major busine= ss 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/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000000e534c05a4f74a11--