[bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

[bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

Hi,

(cross-posting as it's really both layers concerned)

Ongoing advancement of BIP 157 implementation in Core maybe the opportunity
to reflect on the future of light client protocols and use this knowledge
to make better-informed decisions about what kind of infrastructure is
needed to support mobile clients at large scale.

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. Assuming a
user adoption path where a full-node is required to benefit for LN may
deprive a lot of users, especially those who are already denied a real
financial infrastructure access. It doesn't mean we shouldn't foster node
adoption when people are able to do so, and having a LN wallet maybe even a
first-step to it.

Designing a mobile-first LN experience opens its own gap of challenges
especially in terms of security and privacy. The problem can be scoped as
how to build a scalable, secure, private chain access backend for millions
of LN clients ?

Light client protocols for LN exist (either BIP157 or Electrum are used),
although their privacy and security guarantees with regards to
implementation on the client-side may still be an object of concern
(aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
estimation). That said, one of the bottlenecks is likely the number of
full-nodes being willingly to dedicate resources to serve those clients.
It's not about _which_ protocol is deployed but more about _incentives_ for
node operators to dedicate long-term resources to client they have lower
reasons to care about otherwise.

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. Widening full-node adoption, specially in term of
geographic distribution means as much as we can to bound its operational
cost.

Obviously,  deployment of more efficient tx-relay protocol like Erlay will
free up some resources but it maybe wiser to dedicate them to increase
health and security of the backbone network like deploying more outbound
connections.

Unless your light client protocol is so ridiculous cheap to rely on
niceness of a subset of node operators offering free resources, it won't
scale. And it's likely you will always have a ratio disequilibrium between
numbers of clients and numbers of full-node, even worst their growth rate
won't be the same, first ones are so much easier to setup.

It doesn't mean servicing filters for free won't work for now, numbers of
BIP157 clients is still pretty low, but what is worrying is  wallet vendors
building such chain access backend, hitting a bandwidth scalability wall
few years from now instead of pursuing better solutions. And if this
happen, maybe suddenly, isn't the quick fix going to be to rely on
centralized services, so much easier to deploy ?

Of course, it may be brought that actually current full-node operators
don't get anything back from servicing blocks, transactions, addresses...
It may be replied that you have an indirect incentive to participate in
network relay and therefore guarantee censorship-resistance, instead of
directly connecting to miners. You do have today ways to select your
resources exposure like pruning, block-only or being private but the wider
point is the current (non?)-incentives model seems to work for the base
layer. For light clients data, are node operators going to be satisfied to
serve this new *class* of traffic en masse ?

This doesn't mean you won't find BIP157 servers, ready to serve you with
unlimited credit, but it's more likely their intentions maybe not aligned,
like spying on your transaction broadcast or block fetched. And you do want
peer diversity to avoid every BIP157 servers being on few ASNs for
fault-tolerance. Do people expect a scenario a la Cloudflare, where
everyone connections is to far or less the same set of entities ?

Moreover, the LN security model diverges hugely from basic on-chain
transactions. Worst-case attack on-chain a malicious light client server
showing a longest, invalid, PoW-signed chain to double-spend the user. On
LN, the *liveliness* requirement means the entity owning your view of the
chain can lie to you on whether your channel has been spent by a revoked
commitment, the real tip of the blockchain or even dry-up block
announcement to trigger unexpected behavior in the client logic. A
malicious light client server may just drop any filters/utxos spends, what
your LN client should do in this case ? [1]

Therefore, you may want to introduce monetary compensation in exchange of
servicing filters. Light client not dedicating resources to maintain the
network but free-riding on it, you may use their micro-payment capabilities
to price chain access resources [3]. This proposition may suit within the
watchtower paradigm, where another entity is delegated some part of
protocol execution, alleviating client onliness requirement. It needs
further analysis but how your funds may be compromised by a watchtower are
likely to be the same scenario that how a chain validation provider can
compromise you. That said, how do you avoid such "chain access" market
turning as an oligopoly is an open question. You may "bind" them to
internet topology or ask for fidelity bonds and create some kind of
scarcity but still...

Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
just rely on few thousands of full-node operators being nice and servicing
friendly millions of LN mobiles clients. But just in case it may be good to
consider a reasonable alternative.

Thanks Gleb for many points exposed here but all mistakes are my own.

Cheers,

Antoine

[0] UTXO set size may be a bottleneck, but still if you have 2 channels by
clients that's 20M utxos, just roughly ~x3 than today.

[1] And committing filters as part of headers may not solve everything as
an attacker can just delay or slow announcements to you, so you still need
network access to at least one honest node.

[2]  It maybe argue that distinction client-vs-peer doesn't hold because
you may start as a client and start synchronizing the chain, relaying
blocks, etc. AFAIK, there is no such hybrid implementation and that's not
what you want to run in a mobile.

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

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

[Luke Dashjr]

On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> 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.

> Assuming a user adoption path where a full-node is required to benefit for
> LN may deprive a lot of users, especially those who are already denied a
> real financial infrastructure access.

If Bitcoin can't do it, then Bitcoin can't do it.
Bitcoin can't solve *any* problem if it becomes insecure itself.

Luke

P.S. See also
https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[ZmnSCPxj]

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

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

[Lloyd Fournier]

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

On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > 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.
>

Hi Luke,

I have heard this claim made several times but have never understood the
argument behind it. The question I always have is: If I get scammed by not
verifying my incoming transactions properly how can this affect anyone
else? It's very unintuative.  I've been scammed several times in my life in
fiat currency transactions but as far as I could tell it never negatively
affected the currency overall!

The links you point and from what I've seen you say before refer to "miner
control" as the culprit. My only thought is that this is because a light
client could follow a dishonest majority of hash power chain. But this just
brings me back to the question. If, instead of BTC, I get a payment in some
miner scamcoin on their dishonest fork (but I think it's BTC because I'm
running a light client) that still seems to only to damage me. Where does
the side effect onto others on the network come from?

Cheers,

LL

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[John Newbery]

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

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
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Olaoluwa Osuntokun]

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

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.

> Therefore, you may want to introduce monetary compensation in exchange of
> servicing filters. Light client not dedicating resources to maintain the
> network but free-riding on it, you may use their micro-payment
> capabilities to price chain access resources [3]

Piggy backing off the above idea, if the data starts being widely served
over HTTP, then LSATs[1][2] can be used to add a lightweight payment
mechanism by inserting a new proxy server in front of the filter/header
infrastructure. The minted tokens themselves may allow a user to purchase
access to a single header/filter, a range of them in the past, or N headers
past the known chain tip, etc, etc.

-- Laolu

[1]: https://lsat.tech/
[2]: https://lightning.engineering/posts/2020-03-30-lsat/


On Tue, May 5, 2020 at 3:17 AM Antoine Riard <antoine.riard@gmail.com>
wrote:

> Hi,
>
> (cross-posting as it's really both layers concerned)
>
> Ongoing advancement of BIP 157 implementation in Core maybe the
> opportunity to reflect on the future of light client protocols and use this
> knowledge to make better-informed decisions about what kind of
> infrastructure is needed to support mobile clients at large scale.
>
> 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. Assuming a
> user adoption path where a full-node is required to benefit for LN may
> deprive a lot of users, especially those who are already denied a real
> financial infrastructure access. It doesn't mean we shouldn't foster node
> adoption when people are able to do so, and having a LN wallet maybe even a
> first-step to it.
>
> Designing a mobile-first LN experience opens its own gap of challenges
> especially in terms of security and privacy. The problem can be scoped as
> how to build a scalable, secure, private chain access backend for millions
> of LN clients ?
>
> Light client protocols for LN exist (either BIP157 or Electrum are used),
> although their privacy and security guarantees with regards to
> implementation on the client-side may still be an object of concern
> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
> estimation). That said, one of the bottlenecks is likely the number of
> full-nodes being willingly to dedicate resources to serve those clients.
> It's not about _which_ protocol is deployed but more about _incentives_ for
> node operators to dedicate long-term resources to client they have lower
> reasons to care about otherwise.
>
> 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. Widening full-node adoption, specially in term of
> geographic distribution means as much as we can to bound its operational
> cost.
>
> Obviously,  deployment of more efficient tx-relay protocol like Erlay will
> free up some resources but it maybe wiser to dedicate them to increase
> health and security of the backbone network like deploying more outbound
> connections.
>
> Unless your light client protocol is so ridiculous cheap to rely on
> niceness of a subset of node operators offering free resources, it won't
> scale. And it's likely you will always have a ratio disequilibrium between
> numbers of clients and numbers of full-node, even worst their growth rate
> won't be the same, first ones are so much easier to setup.
>
> It doesn't mean servicing filters for free won't work for now, numbers of
> BIP157 clients is still pretty low, but what is worrying is  wallet vendors
> building such chain access backend, hitting a bandwidth scalability wall
> few years from now instead of pursuing better solutions. And if this
> happen, maybe suddenly, isn't the quick fix going to be to rely on
> centralized services, so much easier to deploy ?
>
> Of course, it may be brought that actually current full-node operators
> don't get anything back from servicing blocks, transactions, addresses...
> It may be replied that you have an indirect incentive to participate in
> network relay and therefore guarantee censorship-resistance, instead of
> directly connecting to miners. You do have today ways to select your
> resources exposure like pruning, block-only or being private but the wider
> point is the current (non?)-incentives model seems to work for the base
> layer. For light clients data, are node operators going to be satisfied to
> serve this new *class* of traffic en masse ?
>
> This doesn't mean you won't find BIP157 servers, ready to serve you with
> unlimited credit, but it's more likely their intentions maybe not aligned,
> like spying on your transaction broadcast or block fetched. And you do want
> peer diversity to avoid every BIP157 servers being on few ASNs for
> fault-tolerance. Do people expect a scenario a la Cloudflare, where
> everyone connections is to far or less the same set of entities ?
>
> Moreover, the LN security model diverges hugely from basic on-chain
> transactions. Worst-case attack on-chain a malicious light client server
> showing a longest, invalid, PoW-signed chain to double-spend the user. On
> LN, the *liveliness* requirement means the entity owning your view of the
> chain can lie to you on whether your channel has been spent by a revoked
> commitment, the real tip of the blockchain or even dry-up block
> announcement to trigger unexpected behavior in the client logic. A
> malicious light client server may just drop any filters/utxos spends, what
> your LN client should do in this case ? [1]
>
> Therefore, you may want to introduce monetary compensation in exchange of
> servicing filters. Light client not dedicating resources to maintain the
> network but free-riding on it, you may use their micro-payment capabilities
> to price chain access resources [3]. This proposition may suit within the
> watchtower paradigm, where another entity is delegated some part of
> protocol execution, alleviating client onliness requirement. It needs
> further analysis but how your funds may be compromised by a watchtower are
> likely to be the same scenario that how a chain validation provider can
> compromise you. That said, how do you avoid such "chain access" market
> turning as an oligopoly is an open question. You may "bind" them to
> internet topology or ask for fidelity bonds and create some kind of
> scarcity but still...
>
> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
> just rely on few thousands of full-node operators being nice and servicing
> friendly millions of LN mobiles clients. But just in case it may be good to
> consider a reasonable alternative.
>
> Thanks Gleb for many points exposed here but all mistakes are my own.
>
> Cheers,
>
> Antoine
>
> [0] UTXO set size may be a bottleneck, but still if you have 2 channels by
> clients that's 20M utxos, just roughly ~x3 than today.
>
> [1] And committing filters as part of headers may not solve everything as
> an attacker can just delay or slow announcements to you, so you still need
> network access to at least one honest node.
>
> [2]  It maybe argue that distinction client-vs-peer doesn't hold because
> you may start as a client and start synchronizing the chain, relaying
> blocks, etc. AFAIK, there is no such hybrid implementation and that's not
> what you want to run in a mobile.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

I didn't trust myself and verify. In fact the [3] is the real [2].

Le mar. 5 mai 2020 à 06:28, Andrés G. Aragoneses <knocte@gmail.com> a
écrit :

> Hey Antoine, just a small note, [3] is missing in your footnotes, can you
> add it? Thanks
>
> On Tue, 5 May 2020 at 18:17, Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use this
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> 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. Assuming a
>> user adoption path where a full-node is required to benefit for LN may
>> deprive a lot of users, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a mobile-first LN experience opens its own gap of challenges
>> especially in terms of security and privacy. The problem can be scoped as
>> how to build a scalable, secure, private chain access backend for millions
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum are used),
>> although their privacy and security guarantees with regards to
>> implementation on the client-side may still be an object of concern
>> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
>> estimation). That said, one of the bottlenecks is likely the number of
>> full-nodes being willingly to dedicate resources to serve those clients.
>> It's not about _which_ protocol is deployed but more about _incentives_ for
>> node operators to dedicate long-term resources to client they have lower
>> reasons to care about otherwise.
>>
>> 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. Widening full-node adoption, specially in term of
>> geographic distribution means as much as we can to bound its operational
>> cost.
>>
>> Obviously,  deployment of more efficient tx-relay protocol like Erlay
>> will free up some resources but it maybe wiser to dedicate them to increase
>> health and security of the backbone network like deploying more outbound
>> connections.
>>
>> Unless your light client protocol is so ridiculous cheap to rely on
>> niceness of a subset of node operators offering free resources, it won't
>> scale. And it's likely you will always have a ratio disequilibrium between
>> numbers of clients and numbers of full-node, even worst their growth rate
>> won't be the same, first ones are so much easier to setup.
>>
>> It doesn't mean servicing filters for free won't work for now, numbers of
>> BIP157 clients is still pretty low, but what is worrying is  wallet vendors
>> building such chain access backend, hitting a bandwidth scalability wall
>> few years from now instead of pursuing better solutions. And if this
>> happen, maybe suddenly, isn't the quick fix going to be to rely on
>> centralized services, so much easier to deploy ?
>>
>> Of course, it may be brought that actually current full-node operators
>> don't get anything back from servicing blocks, transactions, addresses...
>> It may be replied that you have an indirect incentive to participate in
>> network relay and therefore guarantee censorship-resistance, instead of
>> directly connecting to miners. You do have today ways to select your
>> resources exposure like pruning, block-only or being private but the wider
>> point is the current (non?)-incentives model seems to work for the base
>> layer. For light clients data, are node operators going to be satisfied to
>> serve this new *class* of traffic en masse ?
>>
>> This doesn't mean you won't find BIP157 servers, ready to serve you with
>> unlimited credit, but it's more likely their intentions maybe not aligned,
>> like spying on your transaction broadcast or block fetched. And you do want
>> peer diversity to avoid every BIP157 servers being on few ASNs for
>> fault-tolerance. Do people expect a scenario a la Cloudflare, where
>> everyone connections is to far or less the same set of entities ?
>>
>> Moreover, the LN security model diverges hugely from basic on-chain
>> transactions. Worst-case attack on-chain a malicious light client server
>> showing a longest, invalid, PoW-signed chain to double-spend the user. On
>> LN, the *liveliness* requirement means the entity owning your view of the
>> chain can lie to you on whether your channel has been spent by a revoked
>> commitment, the real tip of the blockchain or even dry-up block
>> announcement to trigger unexpected behavior in the client logic. A
>> malicious light client server may just drop any filters/utxos spends, what
>> your LN client should do in this case ? [1]
>>
>> Therefore, you may want to introduce monetary compensation in exchange of
>> servicing filters. Light client not dedicating resources to maintain the
>> network but free-riding on it, you may use their micro-payment capabilities
>> to price chain access resources [3]. This proposition may suit within the
>> watchtower paradigm, where another entity is delegated some part of
>> protocol execution, alleviating client onliness requirement. It needs
>> further analysis but how your funds may be compromised by a watchtower are
>> likely to be the same scenario that how a chain validation provider can
>> compromise you. That said, how do you avoid such "chain access" market
>> turning as an oligopoly is an open question. You may "bind" them to
>> internet topology or ask for fidelity bonds and create some kind of
>> scarcity but still...
>>
>> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servicing
>> friendly millions of LN mobiles clients. But just in case it may be good to
>> consider a reasonable alternative.
>>
>> Thanks Gleb for many points exposed here but all mistakes are my own.
>>
>> Cheers,
>>
>> Antoine
>>
>> [0] UTXO set size may be a bottleneck, but still if you have 2 channels
>> by clients that's 20M utxos, just roughly ~x3 than today.
>>
>> [1] And committing filters as part of headers may not solve everything as
>> an attacker can just delay or slow announcements to you, so you still need
>> network access to at least one honest node.
>>
>> [2]  It maybe argue that distinction client-vs-peer doesn't hold because
>> you may start as a client and start synchronizing the chain, relaying
>> blocks, etc. AFAIK, there is no such hybrid implementation and that's not
>> what you want to run in a mobile.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

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

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

I do see the consensus capture argument by miners but in reality isn't this
attack scenario have a lot of assumptions on topology an deployment ?

For such attack to succeed you need miners nodes to be connected to clients
to feed directly the invalid headers and if these ones are connected to
headers/filters gateways, themselves doing full-nodes validation invalid
chain is going to be sanitized out ?

Sure now you trust these gateways, but if you have multiple connections to
them and can guarantee they aren't run by the same entity, that maybe an
acceptable security model, depending of staked amount and your
expectations. I more concerned of having a lot of them and being
diversified enough to avoid collusion between gateways/chain access
providers/miners.

But even if you light clients is directly connected to the backbone network
and may be reached by miners you can implement fork anomalies detection and
from then you may have multiples options:
* halt the wallet, wait for human intervention
* fallback connection to a trusted server, authoritative on your chain view
* invalidity proofs?

Now I agree you need a wide-enough, sane backbone network to build on top,
and we should foster node adoption as much as we can.

Le mar. 5 mai 2020 à 09:01, Luke Dashjr <luke@dashjr.org> a écrit :

> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > 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.
>
> > Assuming a user adoption path where a full-node is required to benefit
> for
> > LN may deprive a lot of users, especially those who are already denied a
> > real financial infrastructure access.
>
> If Bitcoin can't do it, then Bitcoin can't do it.
> Bitcoin can't solve *any* problem if it becomes insecure itself.
>
> Luke
>
> P.S. See also
>
> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>
> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

[-- 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 --]

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

> As a result, the entire protocol could be served over something like
HTTP, taking advantage of all the established CDNs and anycast serving
infrastructure,

Yes it's moving the issue of being a computation one to a distribution one.
But still you need the bandwidth capacities. What I'm concerned is the
trust model of relying on few-establish CDNs, you don't want to make it
easy to have "headers-routing" hijack and therefore having massive channel
closure or time-locks interference due to LN clients not seeing the last
few block. So you may want to separate control/data plane, get filters from
CDN and headers as check-and-control directly from the backbone network.
"Hybrid" models should clearly be explored.

Web-of-trust style of deployments should be also envisioned, you may get
huge scaling improvement, assuming client may be peers between themselves
and the ones belonging to the same social entity should be able to share
the same chain view without too much risk.

> Piggy backing off the above idea, if the data starts being widely served
over HTTP, then LSATs[1][2] can be used to add a lightweight payment
mechanism by inserting a new proxy server in front of the filter/header
infrastructure.

Yeah, I hadn't time to read the spec yet but that was clearly something
like LSATs I meaned speaking about monetary compensation to price
resources. I just hope it isn't too much tie to HTTP because you may want
to read/write over other communication channels like
tx-broadcast-over-radio to solve first-hop privacy.

Le mar. 5 mai 2020 à 20:31, Olaoluwa Osuntokun <laolu32@gmail.com> a écrit :

> 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.
>
> > Therefore, you may want to introduce monetary compensation in exchange of
> > servicing filters. Light client not dedicating resources to maintain the
> > network but free-riding on it, you may use their micro-payment
> > capabilities to price chain access resources [3]
>
> Piggy backing off the above idea, if the data starts being widely served
> over HTTP, then LSATs[1][2] can be used to add a lightweight payment
> mechanism by inserting a new proxy server in front of the filter/header
> infrastructure. The minted tokens themselves may allow a user to purchase
> access to a single header/filter, a range of them in the past, or N headers
> past the known chain tip, etc, etc.
>
> -- Laolu
>
> [1]: https://lsat.tech/
> [2]: https://lightning.engineering/posts/2020-03-30-lsat/
>
>
> On Tue, May 5, 2020 at 3:17 AM Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use this
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> 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. Assuming a
>> user adoption path where a full-node is required to benefit for LN may
>> deprive a lot of users, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a mobile-first LN experience opens its own gap of challenges
>> especially in terms of security and privacy. The problem can be scoped as
>> how to build a scalable, secure, private chain access backend for millions
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum are used),
>> although their privacy and security guarantees with regards to
>> implementation on the client-side may still be an object of concern
>> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
>> estimation). That said, one of the bottlenecks is likely the number of
>> full-nodes being willingly to dedicate resources to serve those clients.
>> It's not about _which_ protocol is deployed but more about _incentives_ for
>> node operators to dedicate long-term resources to client they have lower
>> reasons to care about otherwise.
>>
>> 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. Widening full-node adoption, specially in term of
>> geographic distribution means as much as we can to bound its operational
>> cost.
>>
>> Obviously,  deployment of more efficient tx-relay protocol like Erlay
>> will free up some resources but it maybe wiser to dedicate them to increase
>> health and security of the backbone network like deploying more outbound
>> connections.
>>
>> Unless your light client protocol is so ridiculous cheap to rely on
>> niceness of a subset of node operators offering free resources, it won't
>> scale. And it's likely you will always have a ratio disequilibrium between
>> numbers of clients and numbers of full-node, even worst their growth rate
>> won't be the same, first ones are so much easier to setup.
>>
>> It doesn't mean servicing filters for free won't work for now, numbers of
>> BIP157 clients is still pretty low, but what is worrying is  wallet vendors
>> building such chain access backend, hitting a bandwidth scalability wall
>> few years from now instead of pursuing better solutions. And if this
>> happen, maybe suddenly, isn't the quick fix going to be to rely on
>> centralized services, so much easier to deploy ?
>>
>> Of course, it may be brought that actually current full-node operators
>> don't get anything back from servicing blocks, transactions, addresses...
>> It may be replied that you have an indirect incentive to participate in
>> network relay and therefore guarantee censorship-resistance, instead of
>> directly connecting to miners. You do have today ways to select your
>> resources exposure like pruning, block-only or being private but the wider
>> point is the current (non?)-incentives model seems to work for the base
>> layer. For light clients data, are node operators going to be satisfied to
>> serve this new *class* of traffic en masse ?
>>
>> This doesn't mean you won't find BIP157 servers, ready to serve you with
>> unlimited credit, but it's more likely their intentions maybe not aligned,
>> like spying on your transaction broadcast or block fetched. And you do want
>> peer diversity to avoid every BIP157 servers being on few ASNs for
>> fault-tolerance. Do people expect a scenario a la Cloudflare, where
>> everyone connections is to far or less the same set of entities ?
>>
>> Moreover, the LN security model diverges hugely from basic on-chain
>> transactions. Worst-case attack on-chain a malicious light client server
>> showing a longest, invalid, PoW-signed chain to double-spend the user. On
>> LN, the *liveliness* requirement means the entity owning your view of the
>> chain can lie to you on whether your channel has been spent by a revoked
>> commitment, the real tip of the blockchain or even dry-up block
>> announcement to trigger unexpected behavior in the client logic. A
>> malicious light client server may just drop any filters/utxos spends, what
>> your LN client should do in this case ? [1]
>>
>> Therefore, you may want to introduce monetary compensation in exchange of
>> servicing filters. Light client not dedicating resources to maintain the
>> network but free-riding on it, you may use their micro-payment capabilities
>> to price chain access resources [3]. This proposition may suit within the
>> watchtower paradigm, where another entity is delegated some part of
>> protocol execution, alleviating client onliness requirement. It needs
>> further analysis but how your funds may be compromised by a watchtower are
>> likely to be the same scenario that how a chain validation provider can
>> compromise you. That said, how do you avoid such "chain access" market
>> turning as an oligopoly is an open question. You may "bind" them to
>> internet topology or ask for fidelity bonds and create some kind of
>> scarcity but still...
>>
>> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servicing
>> friendly millions of LN mobiles clients. But just in case it may be good to
>> consider a reasonable alternative.
>>
>> Thanks Gleb for many points exposed here but all mistakes are my own.
>>
>> Cheers,
>>
>> Antoine
>>
>> [0] UTXO set size may be a bottleneck, but still if you have 2 channels
>> by clients that's 20M utxos, just roughly ~x3 than today.
>>
>> [1] And committing filters as part of headers may not solve everything as
>> an attacker can just delay or slow announcements to you, so you still need
>> network access to at least one honest node.
>>
>> [2]  It maybe argue that distinction client-vs-peer doesn't hold because
>> you may start as a client and start synchronizing the chain, relaying
>> blocks, etc. AFAIK, there is no such hybrid implementation and that's not
>> what you want to run in a mobile.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Keagan McClelland]

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

Hi Antoine,

Consensus capture by miners isn't the only concern here. Consensus capture
by any subset of users whose interests diverge from the overall consensus
is equally damaging. The scenario I can imagine here is that the more light
clients outpace full nodes, the more the costs of security are being
externalized from the light clients onto the full nodes. In this situation,
it can make full nodes harder to run. If they are harder to run it will
price out some marginal set of full node operators, which causes a net new
increase in light clients (as the disaffected full nodes convert), AND a
redistribution of load onto a smaller surface area. This is a naturally
unstable process. It is safe to say that as node counts drop, the set of
node operators will increasingly represent economic actors with extreme
weight. The more this process unfolds, the more likely their interests will
diverge from the population at large, and also the more likely they can be
coerced into behavior they otherwise wouldn't. After all it is easier to
find agents who carry lots of economic weight. This is true independent of
their mining status, we should be just as wary of consensus capture by
exchanges or HNWI's as we are about miners.

Keagan

On Wed, May 6, 2020 at 3:06 AM Antoine Riard <antoine.riard@gmail.com>
wrote:

> I do see the consensus capture argument by miners but in reality isn't
> this attack scenario have a lot of assumptions on topology an deployment ?
>
> For such attack to succeed you need miners nodes to be connected to
> clients to feed directly the invalid headers and if these ones are
> connected to headers/filters gateways, themselves doing full-nodes
> validation invalid chain is going to be sanitized out ?
>
> Sure now you trust these gateways, but if you have multiple connections to
> them and can guarantee they aren't run by the same entity, that maybe an
> acceptable security model, depending of staked amount and your
> expectations. I more concerned of having a lot of them and being
> diversified enough to avoid collusion between gateways/chain access
> providers/miners.
>
> But even if you light clients is directly connected to the backbone
> network and may be reached by miners you can implement fork anomalies
> detection and from then you may have multiples options:
> * halt the wallet, wait for human intervention
> * fallback connection to a trusted server, authoritative on your chain view
> * invalidity proofs?
>
> Now I agree you need a wide-enough, sane backbone network to build on top,
> and we should foster node adoption as much as we can.
>
> Le mar. 5 mai 2020 à 09:01, Luke Dashjr <luke@dashjr.org> a écrit :
>
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>> > 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.
>>
>> > Assuming a user adoption path where a full-node is required to benefit
>> for
>> > LN may deprive a lot of users, especially those who are already denied a
>> > real financial infrastructure access.
>>
>> If Bitcoin can't do it, then Bitcoin can't do it.
>> Bitcoin can't solve *any* problem if it becomes insecure itself.
>>
>> Luke
>>
>> P.S. See also
>>
>> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>>
>> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

What I'm thinking more is if the costs of security are being too much
externalized from the light clients onto full nodes, nodes operators are
just going to stop servicing light clients `peercfilters=false`. The
backbone p2p network is going to be fine. But the massive LN light clients
network built on top is going to rely on centralized services for its chain
access and now you may have consensus capture by those..

Le mer. 6 mai 2020 à 12:00, Keagan McClelland <keagan.mcclelland@gmail.com>
a écrit :

> Hi Antoine,
>
> Consensus capture by miners isn't the only concern here. Consensus capture
> by any subset of users whose interests diverge from the overall consensus
> is equally damaging. The scenario I can imagine here is that the more light
> clients outpace full nodes, the more the costs of security are being
> externalized from the light clients onto the full nodes. In this situation,
> it can make full nodes harder to run. If they are harder to run it will
> price out some marginal set of full node operators, which causes a net new
> increase in light clients (as the disaffected full nodes convert), AND a
> redistribution of load onto a smaller surface area. This is a naturally
> unstable process. It is safe to say that as node counts drop, the set of
> node operators will increasingly represent economic actors with extreme
> weight. The more this process unfolds, the more likely their interests will
> diverge from the population at large, and also the more likely they can be
> coerced into behavior they otherwise wouldn't. After all it is easier to
> find agents who carry lots of economic weight. This is true independent of
> their mining status, we should be just as wary of consensus capture by
> exchanges or HNWI's as we are about miners.
>
> Keagan
>
> On Wed, May 6, 2020 at 3:06 AM Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> I do see the consensus capture argument by miners but in reality isn't
>> this attack scenario have a lot of assumptions on topology an deployment ?
>>
>> For such attack to succeed you need miners nodes to be connected to
>> clients to feed directly the invalid headers and if these ones are
>> connected to headers/filters gateways, themselves doing full-nodes
>> validation invalid chain is going to be sanitized out ?
>>
>> Sure now you trust these gateways, but if you have multiple connections
>> to them and can guarantee they aren't run by the same entity, that maybe an
>> acceptable security model, depending of staked amount and your
>> expectations. I more concerned of having a lot of them and being
>> diversified enough to avoid collusion between gateways/chain access
>> providers/miners.
>>
>> But even if you light clients is directly connected to the backbone
>> network and may be reached by miners you can implement fork anomalies
>> detection and from then you may have multiples options:
>> * halt the wallet, wait for human intervention
>> * fallback connection to a trusted server, authoritative on your chain
>> view
>> * invalidity proofs?
>>
>> Now I agree you need a wide-enough, sane backbone network to build on
>> top, and we should foster node adoption as much as we can.
>>
>> Le mar. 5 mai 2020 à 09:01, Luke Dashjr <luke@dashjr.org> a écrit :
>>
>>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> > 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.
>>>
>>> > Assuming a user adoption path where a full-node is required to benefit
>>> for
>>> > LN may deprive a lot of users, especially those who are already denied
>>> a
>>> > real financial infrastructure access.
>>>
>>> If Bitcoin can't do it, then Bitcoin can't do it.
>>> Bitcoin can't solve *any* problem if it becomes insecure itself.
>>>
>>> Luke
>>>
>>> P.S. See also
>>>
>>> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>>>
>>> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Keagan McClelland]

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

I think that one of the solutions here is to have light clients choose
their full node tethers explicitly. Even if you think it is unrealistic to
have everyone run their own node (fwiw, I don’t), there is still a trust
model where you can pick your trusted source.

This way you could have many light clients working off of a family node,
and the peer services could be limited to some sort of “authenticated”
peers. Perhaps this is better accomplished over the RPC interface in Core,
but the idea is to have some sort of peer service model between “full
public” and “owner only”. This limits the amount of costs that can be
properly externalized, without exposing risk of consensus capture by
economically weighty institutions.

Keagan

On Wed, May 6, 2020 at 9:56 PM Antoine Riard <antoine.riard@gmail.com>
wrote:

> What I'm thinking more is if the costs of security are being too much
> externalized from the light clients onto full nodes, nodes operators are
> just going to stop servicing light clients `peercfilters=false`. The
> backbone p2p network is going to be fine. But the massive LN light clients
> network built on top is going to rely on centralized services for its chain
> access and now you may have consensus capture by those..
>
> Le mer. 6 mai 2020 à 12:00, Keagan McClelland <keagan.mcclelland@gmail.com>
> a écrit :
>
>> Hi Antoine,
>>
>> Consensus capture by miners isn't the only concern here. Consensus
>> capture by any subset of users whose interests diverge from the overall
>> consensus is equally damaging. The scenario I can imagine here is that the
>> more light clients outpace full nodes, the more the costs of security are
>> being externalized from the light clients onto the full nodes. In this
>> situation, it can make full nodes harder to run. If they are harder to run
>> it will price out some marginal set of full node operators, which causes a
>> net new increase in light clients (as the disaffected full nodes convert),
>> AND a redistribution of load onto a smaller surface area. This is a
>> naturally unstable process. It is safe to say that as node counts drop, the
>> set of node operators will increasingly represent economic actors with
>> extreme weight. The more this process unfolds, the more likely their
>> interests will diverge from the population at large, and also the more
>> likely they can be coerced into behavior they otherwise wouldn't. After all
>> it is easier to find agents who carry lots of economic weight. This is true
>> independent of their mining status, we should be just as wary of consensus
>> capture by exchanges or HNWI's as we are about miners.
>>
>> Keagan
>>
>> On Wed, May 6, 2020 at 3:06 AM Antoine Riard <antoine.riard@gmail.com>
>> wrote:
>>
>>> I do see the consensus capture argument by miners but in reality isn't
>>> this attack scenario have a lot of assumptions on topology an deployment ?
>>>
>>> For such attack to succeed you need miners nodes to be connected to
>>> clients to feed directly the invalid headers and if these ones are
>>> connected to headers/filters gateways, themselves doing full-nodes
>>> validation invalid chain is going to be sanitized out ?
>>>
>>> Sure now you trust these gateways, but if you have multiple connections
>>> to them and can guarantee they aren't run by the same entity, that maybe an
>>> acceptable security model, depending of staked amount and your
>>> expectations. I more concerned of having a lot of them and being
>>> diversified enough to avoid collusion between gateways/chain access
>>> providers/miners.
>>>
>>> But even if you light clients is directly connected to the backbone
>>> network and may be reached by miners you can implement fork anomalies
>>> detection and from then you may have multiples options:
>>> * halt the wallet, wait for human intervention
>>> * fallback connection to a trusted server, authoritative on your chain
>>> view
>>> * invalidity proofs?
>>>
>>> Now I agree you need a wide-enough, sane backbone network to build on
>>> top, and we should foster node adoption as much as we can.
>>>
>>> Le mar. 5 mai 2020 à 09:01, Luke Dashjr <luke@dashjr.org> a écrit :
>>>
>>>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>>> > 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.
>>>>
>>>> > Assuming a user adoption path where a full-node is required to
>>>> benefit for
>>>> > LN may deprive a lot of users, especially those who are already
>>>> denied a
>>>> > real financial infrastructure access.
>>>>
>>>> If Bitcoin can't do it, then Bitcoin can't do it.
>>>> Bitcoin can't solve *any* problem if it becomes insecure itself.
>>>>
>>>> Luke
>>>>
>>>> P.S. See also
>>>>
>>>> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>>>>
>>>> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Igor Cota]

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

Hi Antoine et al,

Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
> just rely on few thousands of full-node operators being nice and servicing
> friendly millions of LN mobiles clients. But just in case it may be good to
> consider a reasonable alternative.
>


> So you may want to separate control/data plane, get filters from CDN and
> headers as check-and-control directly from the backbone network. "Hybrid"
> models should clearly be explored.


For some months now I've been exploring the feasibility of running full
nodes on everyday phones [1]. One of my first thoughts was how to avoid the
phones mooching off the network. Obviously due to battery, storage and
bandwidth constraints it is not reasonable to expect pocket full nodes to
serve blocks during day time.

Huge exception to this is the time we are asleep and our phones are
connected to wifi and charging. IMO this is a huge untapped resource that
would allow mobile nodes to earn their keep. If we limit full node
operation to sleepy night time the only constraining resource is storage:
512 gb of internal storage in phones is quite rare, probably about $100 for
an SD card with full archival node capacity but phones with memory card
slots rarer still - no one is going to bother.

So depending on their storage capacity phone nodes could decide to store
and serve just a randomly selected range of blocks during their nighttime
operation. With trivial changes to P2P they could advertise the blocks they
are able to serve.
If there comes a time that normal full nodes feel DoS'ed they can challenge
such nodes to produce the blocks they advertise and ban them as moochers if
they fail to do so. Others may elect to be more charitable and serve
everyone.

These types of nodes would truly be part-timing since they only carry a
subset of the blockchain and work while their operator is asleep. Probably
should be called part-time or Sleeper Nodes™.

They could be user friendly as well, with Assume UTXO they could be
bootstrapped quickly and while they do the IBD in the background instead of
traditional pruning they can keep the randomly assigned bit of blockchain
to later serve the network.

Save for the elderly, all the people I know could run such a node, and I
don't live in a first world country.

There is also the feel-good kumbaya aspect of American phone nodes serving
the African continent while the Americans are asleep, Africans and
Europeans serving the Asians in kind. By plugging in our phones and going
to sleep we could blanket the whole world in (somewhat) full nodes!

Cheers,
Igor

[1] https://icota.github.io/

On Tue, 5 May 2020 at 12:18, Antoine Riard <antoine.riard@gmail.com> wrote:

> Hi,
>
> (cross-posting as it's really both layers concerned)
>
> Ongoing advancement of BIP 157 implementation in Core maybe the
> opportunity to reflect on the future of light client protocols and use this
> knowledge to make better-informed decisions about what kind of
> infrastructure is needed to support mobile clients at large scale.
>
> 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. Assuming a
> user adoption path where a full-node is required to benefit for LN may
> deprive a lot of users, especially those who are already denied a real
> financial infrastructure access. It doesn't mean we shouldn't foster node
> adoption when people are able to do so, and having a LN wallet maybe even a
> first-step to it.
>
> Designing a mobile-first LN experience opens its own gap of challenges
> especially in terms of security and privacy. The problem can be scoped as
> how to build a scalable, secure, private chain access backend for millions
> of LN clients ?
>
> Light client protocols for LN exist (either BIP157 or Electrum are used),
> although their privacy and security guarantees with regards to
> implementation on the client-side may still be an object of concern
> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
> estimation). That said, one of the bottlenecks is likely the number of
> full-nodes being willingly to dedicate resources to serve those clients.
> It's not about _which_ protocol is deployed but more about _incentives_ for
> node operators to dedicate long-term resources to client they have lower
> reasons to care about otherwise.
>
> 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. Widening full-node adoption, specially in term of
> geographic distribution means as much as we can to bound its operational
> cost.
>
> Obviously,  deployment of more efficient tx-relay protocol like Erlay will
> free up some resources but it maybe wiser to dedicate them to increase
> health and security of the backbone network like deploying more outbound
> connections.
>
> Unless your light client protocol is so ridiculous cheap to rely on
> niceness of a subset of node operators offering free resources, it won't
> scale. And it's likely you will always have a ratio disequilibrium between
> numbers of clients and numbers of full-node, even worst their growth rate
> won't be the same, first ones are so much easier to setup.
>
> It doesn't mean servicing filters for free won't work for now, numbers of
> BIP157 clients is still pretty low, but what is worrying is  wallet vendors
> building such chain access backend, hitting a bandwidth scalability wall
> few years from now instead of pursuing better solutions. And if this
> happen, maybe suddenly, isn't the quick fix going to be to rely on
> centralized services, so much easier to deploy ?
>
> Of course, it may be brought that actually current full-node operators
> don't get anything back from servicing blocks, transactions, addresses...
> It may be replied that you have an indirect incentive to participate in
> network relay and therefore guarantee censorship-resistance, instead of
> directly connecting to miners. You do have today ways to select your
> resources exposure like pruning, block-only or being private but the wider
> point is the current (non?)-incentives model seems to work for the base
> layer. For light clients data, are node operators going to be satisfied to
> serve this new *class* of traffic en masse ?
>
> This doesn't mean you won't find BIP157 servers, ready to serve you with
> unlimited credit, but it's more likely their intentions maybe not aligned,
> like spying on your transaction broadcast or block fetched. And you do want
> peer diversity to avoid every BIP157 servers being on few ASNs for
> fault-tolerance. Do people expect a scenario a la Cloudflare, where
> everyone connections is to far or less the same set of entities ?
>
> Moreover, the LN security model diverges hugely from basic on-chain
> transactions. Worst-case attack on-chain a malicious light client server
> showing a longest, invalid, PoW-signed chain to double-spend the user. On
> LN, the *liveliness* requirement means the entity owning your view of the
> chain can lie to you on whether your channel has been spent by a revoked
> commitment, the real tip of the blockchain or even dry-up block
> announcement to trigger unexpected behavior in the client logic. A
> malicious light client server may just drop any filters/utxos spends, what
> your LN client should do in this case ? [1]
>
> Therefore, you may want to introduce monetary compensation in exchange of
> servicing filters. Light client not dedicating resources to maintain the
> network but free-riding on it, you may use their micro-payment capabilities
> to price chain access resources [3]. This proposition may suit within the
> watchtower paradigm, where another entity is delegated some part of
> protocol execution, alleviating client onliness requirement. It needs
> further analysis but how your funds may be compromised by a watchtower are
> likely to be the same scenario that how a chain validation provider can
> compromise you. That said, how do you avoid such "chain access" market
> turning as an oligopoly is an open question. You may "bind" them to
> internet topology or ask for fidelity bonds and create some kind of
> scarcity but still...
>
> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
> just rely on few thousands of full-node operators being nice and servicing
> friendly millions of LN mobiles clients. But just in case it may be good to
> consider a reasonable alternative.
>
> Thanks Gleb for many points exposed here but all mistakes are my own.
>
> Cheers,
>
> Antoine
>
> [0] UTXO set size may be a bottleneck, but still if you have 2 channels by
> clients that's 20M utxos, just roughly ~x3 than today.
>
> [1] And committing filters as part of headers may not solve everything as
> an attacker can just delay or slow announcements to you, so you still need
> network access to at least one honest node.
>
> [2]  It maybe argue that distinction client-vs-peer doesn't hold because
> you may start as a client and start synchronizing the chain, relaying
> blocks, etc. AFAIK, there is no such hybrid implementation and that's not
> what you want to run in a mobile.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>


-- 
*Igor Cota*
Codex Apertus Ltd

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Braydon Fuller]

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Braydon Fuller]

On 5/6/20 9:07 PM, Keagan McClelland wrote:

> I think that one of the solutions here is to have light clients choose
> their full node tethers explicitly. Even if you think it is unrealistic to
> have everyone run their own node (fwiw, I don’t), there is still a trust
> model where you can pick your trusted source.
>
> This way you could have many light clients working off of a family node,
> and the peer services could be limited to some sort of “authenticated”
> peers. Perhaps this is better accomplished over the RPC interface in Core,
> but the idea is to have some sort of peer service model between “full
> public” and “owner only”. This limits the amount of costs that can be
> properly externalized, without exposing risk of consensus capture by
> economically weighty institutions.

The RPC interface in Bitcoin Core, and others, is not great for this
because it exposes a lot of functionality that isn't necessary and
introduces risks. For example the `gettxoutsetinfo` can start a very
intensive CPU and disk I/O task. There are several others, for example:
`stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading
full raw blocks isn't very efficient with JSON. Electrum servers (e.g
electrs) for example read blocks from disk instead and use the RPC
interface to sync headers. Though, Electrum servers also have a risk of
DoS with addresses that have many transactions, see the `--txid-limit`
option [2].

[1]:
https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956
[2]:
https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Keagan McClelland]

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

> The RPC interface in Bitcoin Core, and others, is not great for this
> because it exposes a lot of functionality that isn't necessary and
> introduces risks.

This is actually somewhat my point. If the RPC interface was good for this
and *didn't* introduce risks, we could just use that and be done with it.
But I'm finding there are many use cases that you want to have low cost
ways to serve peer services to people whom you have given explicit
permission, but they shouldn't have full ability to administrate the node.

Perhaps I wasn't explicit in my previous note but what I mean is that there
seems to be a demand for something *in between* a peer interface, and an
owner interface. I have little opinion as to whether this belongs in core
or not, I think there are much more experienced folks who can weight in on
that, but without something like this, you cannot limit your exposure for
serving something like bip157 filters without removing your own ability to
make use of some of those same services.

Keagan

On Fri, May 8, 2020 at 1:51 PM Braydon Fuller <braydon@purse.io> wrote:

> On 5/6/20 9:07 PM, Keagan McClelland wrote:
>
> > I think that one of the solutions here is to have light clients choose
> > their full node tethers explicitly. Even if you think it is unrealistic
> to
> > have everyone run their own node (fwiw, I don’t), there is still a trust
> > model where you can pick your trusted source.
> >
> > This way you could have many light clients working off of a family node,
> > and the peer services could be limited to some sort of “authenticated”
> > peers. Perhaps this is better accomplished over the RPC interface in
> Core,
> > but the idea is to have some sort of peer service model between “full
> > public” and “owner only”. This limits the amount of costs that can be
> > properly externalized, without exposing risk of consensus capture by
> > economically weighty institutions.
>
> The RPC interface in Bitcoin Core, and others, is not great for this
> because it exposes a lot of functionality that isn't necessary and
> introduces risks. For example the `gettxoutsetinfo` can start a very
> intensive CPU and disk I/O task. There are several others, for example:
> `stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading
> full raw blocks isn't very efficient with JSON. Electrum servers (e.g
> electrs) for example read blocks from disk instead and use the RPC
> interface to sync headers. Though, Electrum servers also have a risk of
> DoS with addresses that have many transactions, see the `--txid-limit`
> option [2].
>
> [1]:
>
> https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956
> [2]:
>
> https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289
>
>
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Braydon Fuller]

On 5/8/20 1:01 PM, Keagan McClelland wrote:

>> The RPC interface in Bitcoin Core, and others, is not great for this
>> because it exposes a lot of functionality that isn't necessary and
>> introduces risks.
> This is actually somewhat my point. If the RPC interface was good for this
> and *didn't* introduce risks, we could just use that and be done with it.
> But I'm finding there are many use cases that you want to have low cost
> ways to serve peer services to people whom you have given explicit
> permission, but they shouldn't have full ability to administrate the node.
>
> Perhaps I wasn't explicit in my previous note but what I mean is that there
> seems to be a demand for something *in between* a peer interface, and an
> owner interface. I have little opinion as to whether this belongs in core
> or not, I think there are much more experienced folks who can weight in on
> that, but without something like this, you cannot limit your exposure for
> serving something like bip157 filters without removing your own ability to
> make use of some of those same services.

An idea I was thinking about was having three ports for a full node:

1) Consensus bitcoin protocol. This is the existing peer-to-peer
protocol without additional services.
2) Wallet services protocol. Adds additional functionality for wallets.
For example bloom filtering, compact block filters, and potentially
output and address indexes for electrum-like support. It's nearly
identical to the consensus peer-to-peer protocol, supporting the same
wire format. As it's on another port, various middleware could be added
to support various authentication and transports.
3) Control interface. This is the existing JSON-RPC interface, without
all wallet related RPC methods.

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Christopher Allen]

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

On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Perhaps I wasn't explicit in my previous note but what I mean is that
> there seems to be a demand for something *in between* a peer interface,
> and an owner interface. I have little opinion as to whether this belongs in
> core or not, I think there are much more experienced folks who can weight
> in on that, but without something like this, you cannot limit your exposure
> for serving something like bip157 filters without removing your own ability
> to make use of some of those same services.
>

Our FullyNoded2 multisig wallet on iOS & Mac, communicates with your own
personal node over RPC, securing the connection using Tor over a hidden
onion service and two-way client authentication using a v3 Tor
Authentication key: https://github.com/BlockchainCommons/FullyNoded-2

It many ways the app (and its predecessor FullyNoded1) is an interface
between a personal full node and a user.

However, we do wish that the full RPC functionality was not exposed in
bitcoin-core. I’d love to see a cryptographic capability mechanism such
that the remote wallet could only m ask the node functions that it needs,
and allow escalation for other rarer services it needs with addition
authorization.

This capability mechanism feature set should go both ways, to a minimum
subset needed for being a watch-only transaction verification tool, all the
way to things RPC can’t do like deleting a wallet and changing bitcoin.conf
parameters and rebooting, without requiring full ssh access to the server
running the node.

If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Blockchain Commons would
be interested in hosting that collaboration. This could start as just being
a transparent shim between bitcoin-core & remote RPC, but later could
inform proposals for the future of the core wallet functionality as it gets
refactored.

— Christopher Allen

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

Hi Igor,

Thanks for sharing about what it's technically possible to do for a
full-node on phone, specially with regards to lower grade devices.

I do see 2 limitations for sleeping nodes:
- a lightning specific one, i.e you need to process block data real-time in
case of incoming HTLC you need to claim on chain or a HTLC timeout. There
is a bunch of timelocks implications in LN,  with regards to CSV,
CLTV_DELTA, incoming policy, outgoing policy, ... and you can't really
afford to be late without loosing a payment. I don't see timelocks being
increase, that would hinder liquidity.
- a p2p bandwidth concern, even if this new class of nodes turn as public
ones, they would still have a heavy sync period due to be fallen-behind
during the day, so you would have huge bandwidth spikes every a timezone
falls asleep and a risk of choking upload links of stable full-nodes.

I think assume-utxo may be interesting in the future in case of long-fork
detection, you may be able to download a utxo-set on the fly, and fall-back
to a full-node. But that would be only an emergency measure, not a regular
cost on the backbone network.

Antoine


Le jeu. 7 mai 2020 à 12:41, Igor Cota <igor@codexapertus.com> a écrit :

> Hi Antoine et al,
>
> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servicing
>> friendly millions of LN mobiles clients. But just in case it may be good to
>> consider a reasonable alternative.
>>
>
>
>> So you may want to separate control/data plane, get filters from CDN and
>> headers as check-and-control directly from the backbone network. "Hybrid"
>> models should clearly be explored.
>
>
> For some months now I've been exploring the feasibility of running full
> nodes on everyday phones [1]. One of my first thoughts was how to avoid the
> phones mooching off the network. Obviously due to battery, storage and
> bandwidth constraints it is not reasonable to expect pocket full nodes to
> serve blocks during day time.
>
> Huge exception to this is the time we are asleep and our phones are
> connected to wifi and charging. IMO this is a huge untapped resource that
> would allow mobile nodes to earn their keep. If we limit full node
> operation to sleepy night time the only constraining resource is storage:
> 512 gb of internal storage in phones is quite rare, probably about $100 for
> an SD card with full archival node capacity but phones with memory card
> slots rarer still - no one is going to bother.
>
> So depending on their storage capacity phone nodes could decide to store
> and serve just a randomly selected range of blocks during their nighttime
> operation. With trivial changes to P2P they could advertise the blocks they
> are able to serve.
> If there comes a time that normal full nodes feel DoS'ed they can
> challenge such nodes to produce the blocks they advertise and ban them as
> moochers if they fail to do so. Others may elect to be more charitable and
> serve everyone.
>
> These types of nodes would truly be part-timing since they only carry a
> subset of the blockchain and work while their operator is asleep. Probably
> should be called part-time or Sleeper Nodes™.
>
> They could be user friendly as well, with Assume UTXO they could be
> bootstrapped quickly and while they do the IBD in the background instead of
> traditional pruning they can keep the randomly assigned bit of blockchain
> to later serve the network.
>
> Save for the elderly, all the people I know could run such a node, and I
> don't live in a first world country.
>
> There is also the feel-good kumbaya aspect of American phone nodes serving
> the African continent while the Americans are asleep, Africans and
> Europeans serving the Asians in kind. By plugging in our phones and going
> to sleep we could blanket the whole world in (somewhat) full nodes!
>
> Cheers,
> Igor
>
> [1] https://icota.github.io/
>
> On Tue, 5 May 2020 at 12:18, Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use this
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> 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. Assuming a
>> user adoption path where a full-node is required to benefit for LN may
>> deprive a lot of users, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a mobile-first LN experience opens its own gap of challenges
>> especially in terms of security and privacy. The problem can be scoped as
>> how to build a scalable, secure, private chain access backend for millions
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum are used),
>> although their privacy and security guarantees with regards to
>> implementation on the client-side may still be an object of concern
>> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
>> estimation). That said, one of the bottlenecks is likely the number of
>> full-nodes being willingly to dedicate resources to serve those clients.
>> It's not about _which_ protocol is deployed but more about _incentives_ for
>> node operators to dedicate long-term resources to client they have lower
>> reasons to care about otherwise.
>>
>> 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. Widening full-node adoption, specially in term of
>> geographic distribution means as much as we can to bound its operational
>> cost.
>>
>> Obviously,  deployment of more efficient tx-relay protocol like Erlay
>> will free up some resources but it maybe wiser to dedicate them to increase
>> health and security of the backbone network like deploying more outbound
>> connections.
>>
>> Unless your light client protocol is so ridiculous cheap to rely on
>> niceness of a subset of node operators offering free resources, it won't
>> scale. And it's likely you will always have a ratio disequilibrium between
>> numbers of clients and numbers of full-node, even worst their growth rate
>> won't be the same, first ones are so much easier to setup.
>>
>> It doesn't mean servicing filters for free won't work for now, numbers of
>> BIP157 clients is still pretty low, but what is worrying is  wallet vendors
>> building such chain access backend, hitting a bandwidth scalability wall
>> few years from now instead of pursuing better solutions. And if this
>> happen, maybe suddenly, isn't the quick fix going to be to rely on
>> centralized services, so much easier to deploy ?
>>
>> Of course, it may be brought that actually current full-node operators
>> don't get anything back from servicing blocks, transactions, addresses...
>> It may be replied that you have an indirect incentive to participate in
>> network relay and therefore guarantee censorship-resistance, instead of
>> directly connecting to miners. You do have today ways to select your
>> resources exposure like pruning, block-only or being private but the wider
>> point is the current (non?)-incentives model seems to work for the base
>> layer. For light clients data, are node operators going to be satisfied to
>> serve this new *class* of traffic en masse ?
>>
>> This doesn't mean you won't find BIP157 servers, ready to serve you with
>> unlimited credit, but it's more likely their intentions maybe not aligned,
>> like spying on your transaction broadcast or block fetched. And you do want
>> peer diversity to avoid every BIP157 servers being on few ASNs for
>> fault-tolerance. Do people expect a scenario a la Cloudflare, where
>> everyone connections is to far or less the same set of entities ?
>>
>> Moreover, the LN security model diverges hugely from basic on-chain
>> transactions. Worst-case attack on-chain a malicious light client server
>> showing a longest, invalid, PoW-signed chain to double-spend the user. On
>> LN, the *liveliness* requirement means the entity owning your view of the
>> chain can lie to you on whether your channel has been spent by a revoked
>> commitment, the real tip of the blockchain or even dry-up block
>> announcement to trigger unexpected behavior in the client logic. A
>> malicious light client server may just drop any filters/utxos spends, what
>> your LN client should do in this case ? [1]
>>
>> Therefore, you may want to introduce monetary compensation in exchange of
>> servicing filters. Light client not dedicating resources to maintain the
>> network but free-riding on it, you may use their micro-payment capabilities
>> to price chain access resources [3]. This proposition may suit within the
>> watchtower paradigm, where another entity is delegated some part of
>> protocol execution, alleviating client onliness requirement. It needs
>> further analysis but how your funds may be compromised by a watchtower are
>> likely to be the same scenario that how a chain validation provider can
>> compromise you. That said, how do you avoid such "chain access" market
>> turning as an oligopoly is an open question. You may "bind" them to
>> internet topology or ask for fidelity bonds and create some kind of
>> scarcity but still...
>>
>> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servicing
>> friendly millions of LN mobiles clients. But just in case it may be good to
>> consider a reasonable alternative.
>>
>> Thanks Gleb for many points exposed here but all mistakes are my own.
>>
>> Cheers,
>>
>> Antoine
>>
>> [0] UTXO set size may be a bottleneck, but still if you have 2 channels
>> by clients that's 20M utxos, just roughly ~x3 than today.
>>
>> [1] And committing filters as part of headers may not solve everything as
>> an attacker can just delay or slow announcements to you, so you still need
>> network access to at least one honest node.
>>
>> [2]  It maybe argue that distinction client-vs-peer doesn't hold because
>> you may start as a client and start synchronizing the chain, relaying
>> blocks, etc. AFAIK, there is no such hybrid implementation and that's not
>> what you want to run in a mobile.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> *Igor Cota*
> Codex Apertus Ltd
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

Hi Christopher,

Thanks for Blockchain Commons and Learning Bitcoin from the Command Line!

> If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Blockchain Commons would
be interested in hosting that collaboration. This could start as just being
a transparent shim between bitcoin-core & remote RPC, but later could
inform proposals for the future of the core wallet functionality as it gets
refactored.

Yes generally refactoring in Core wallets are making good progress [0]. I'm
pretty sure feedbacks and proposals on future changes with regards to
usability would be greatly appreciated.

Maybe you can bring these during a IRC meeting ?

Antoine

[0] See https://github.com/bitcoin/bitcoin/pull/16528 or
https://github.com/bitcoin/bitcoin/pull/16426

Le ven. 8 mai 2020 à 17:31, Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Perhaps I wasn't explicit in my previous note but what I mean is that
>> there seems to be a demand for something *in between* a peer interface,
>> and an owner interface. I have little opinion as to whether this belongs in
>> core or not, I think there are much more experienced folks who can weight
>> in on that, but without something like this, you cannot limit your exposure
>> for serving something like bip157 filters without removing your own ability
>> to make use of some of those same services.
>>
>
> Our FullyNoded2 multisig wallet on iOS & Mac, communicates with your own
> personal node over RPC, securing the connection using Tor over a hidden
> onion service and two-way client authentication using a v3 Tor
> Authentication key: https://github.com/BlockchainCommons/FullyNoded-2
>
> It many ways the app (and its predecessor FullyNoded1) is an interface
> between a personal full node and a user.
>
> However, we do wish that the full RPC functionality was not exposed in
> bitcoin-core. I’d love to see a cryptographic capability mechanism such
> that the remote wallet could only m ask the node functions that it needs,
> and allow escalation for other rarer services it needs with addition
> authorization.
>
> This capability mechanism feature set should go both ways, to a minimum
> subset needed for being a watch-only transaction verification tool, all the
> way to things RPC can’t do like deleting a wallet and changing bitcoin.conf
> parameters and rebooting, without requiring full ssh access to the server
> running the node.
>
> If there are people interested in coordinating some proposals on how to
> defining different sets of wallet functionality, Blockchain Commons would
> be interested in hosting that collaboration. This could start as just being
> a transparent shim between bitcoin-core & remote RPC, but later could
> inform proposals for the future of the core wallet functionality as it gets
> refactored.
>
> — Christopher Allen
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[ZmnSCPxj]

Good morning Richard, and all,


> 2) a light client can query an ISP connected full node on the same unmetered local WiFi network and exchange differences in block headers opportunistically or pay for large missing ranges of headers, filters or full blocks using a payment channel. Cost is reduced and privacy is enhanced for the light client by not using a centralized ISP. Bandwidth for running the full node can be amortized and subsidized by payments from light clients who they resell data to.

A relatively pointless observation, but it seems to me that:

* The light client is requesting for validation information, because...
* ...its direct peers might be defrauding it, leading to...
* ...the money it *thinks* it has in its channels being valueless.

Thus, if the light client opportunistically pays for validation information (whether full blocks, headers, or filters), the direct peers it has could just as easily not forward any payments, thus preventing the light client from paying for the validation information.

Indeed, if the direct peer *is* defrauding the light client, the direct peer has no real incentive to actually forward *any* payments --- to do so would be to reduce the possible earnings it gets from defrauding the light client.
("Simulating" the payments so that the light client will not suspect anything runs the risk that the light client will be able to forward all its money out of the channel, and the cheating peer is still potentially liable for any funds it originally had in the channel if it gets caught.)

What would work would be to use a system similar to watchtowers, wherein the validation-information-provider is prepaid and issues tokens that can be redeemed later.
But this is not suitable for opportunistic on-same-WiFi where, say, a laptop is running a validation-information-provider-for-payment program on the same WiFi as a light-client mobile phone, if we consider that the laptop and mobile may have never met before and may never meet again.
It would work if the laptop altruistically serves the blocks, but not if it were for (on-Lightning) payment.


So it seems to me that this kind of service is best ridden on top of watchtower service providers.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Richard Myers]

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

Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
concern as: A node without direct internet connectivity can not rely on an
opportunistically incentivized local network peer for blockchain
information because the off-grid node's direct LN peers could collude to
not forward the payment.

On Mon, May 11, 2020 at 7:44 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> > 2) a light client can query an ISP connected full node on the same
> unmetered local WiFi network and exchange differences in block headers
> opportunistically or pay for large missing ranges of headers, filters or
> full blocks using a payment channel. Cost is reduced and privacy is
> enhanced for the light client by not using a centralized ISP. Bandwidth for
> running the full node can be amortized and subsidized by payments from
> light clients who they resell data to.
>
> A relatively pointless observation, but it seems to me that:
>
> * The light client is requesting for validation information, because...
> * ...its direct peers might be defrauding it, leading to...
> * ...the money it *thinks* it has in its channels being valueless.
>
> Thus, if the light client opportunistically pays for validation
> information (whether full blocks, headers, or filters), the direct peers it
> has could just as easily not forward any payments, thus preventing the
> light client from paying for the validation information.
>
> Indeed, if the direct peer *is* defrauding the light client, the direct
> peer has no real incentive to actually forward *any* payments --- to do so
> would be to reduce the possible earnings it gets from defrauding the light
> client.
> ("Simulating" the payments so that the light client will not suspect
> anything runs the risk that the light client will be able to forward all
> its money out of the channel, and the cheating peer is still potentially
> liable for any funds it originally had in the channel if it gets caught.)
>

One question I had is: how can a malicious direct payment peer "simulate" a
successful payment made by an off-grid victim peer to an information
source?  The censoring peer wouldn't be able to return the preimage for a
payment they failed to forward. Also, since the information provider and
off-grid node can presumably communicate via their local network
connection, it would be obvious if all of the victims LN peers were failing
to forward payments (whether maliciously or due to routing failures) to an
information provider they could otherwise communicate with.

Any LN payments not monitored by a watchtower that are received by the
eclipsed off-grid victim node would be at risk in this attack scenario.
Likewise any layer 1 payments they received should be buried under
sufficient valid block headers before being relied on.

I don't see how a LN node one-step removed from a direct internet
connection is at more risk than an internet connected node eclipsed by
their ISP, for example. In both cases, failure to get timely blockchain
info should trigger warnings to stop accepting payments.


> What would work would be to use a system similar to watchtowers, wherein
> the validation-information-provider is prepaid and issues tokens that can
> be redeemed later.
> But this is not suitable for opportunistic on-same-WiFi where, say, a
> laptop is running a validation-information-provider-for-payment program on
> the same WiFi as a light-client mobile phone, if we consider that the
> laptop and mobile may have never met before and may never meet again.
> It would work if the laptop altruistically serves the blocks, but not if
> it were for (on-Lightning) payment.
>

There's another problem if we can't rely on a recurring relationship with
an information provider besides not being able to prepay for validation
information doesn't make sense. We don't want an information provider to
collect payments for serving invalid information. Maybe for very small
payments this isn't a problem, but ideally validity could be coded into the
HTLC.

For example, an alternative HTLC construct that only paid for valid 81 B
headers that hash to 32 B values with a number of leading zeros committed
to by the HTLC. It would make more economic sense for an internet gateway
node to serve valid mined header to nodes on their local WiFi network than
to create bogus ones with the same (high) amount of work.


> So it seems to me that this kind of service is best ridden on top of
> watchtower service providers.
>

Public watchtowers or some sort of HTTP proxy data cache similar to a
watchtower makes the most sense to me because they would be expected to be
economically motivated and LN payment aware. Full nodes could potentially
be incentivized to exchange new data with other nodes in a tit-for-tat way,
but I don't expect them to be incentivized by light clients using LN
micropayments in a server-client arrangement.

Network agents that monetize full node information services beyond channel
monitoring would be more than just a "Watchtower" for light clients. Would
they be more like incentivized Electrum servers? Are there still privacy
concerns when they serve generic/un-personalized headers/filters/blocks to
light clients? A personal, altruistic or friends and family watchtower is
also possible, but I'm thinking about how light clients without this
possibility can be served.

Happy new epoch,

  -- Richard

-- 
Richard Myers
Decentralized Applications Engineer, goTenna
gotenna.com
@gotenna

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[ZmnSCPxj]

Good morning Richard,

> Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your concern as: A node without direct internet connectivity can not rely on an opportunistically incentivized local network peer for blockchain information because the off-grid node's direct LN peers could collude to not forward the payment.

Correct.

> > > 2) a light client can query an ISP connected full node on the same unmetered local WiFi network and exchange differences in block headers opportunistically or pay for large missing ranges of headers, filters or full blocks using a payment channel. Cost is reduced and privacy is enhanced for the light client by not using a centralized ISP. Bandwidth for running the full node can be amortized and subsidized by payments from light clients who they resell data to.
> >
> > A relatively pointless observation, but it seems to me that:
> >
> > * The light client is requesting for validation information, because...
> > * ...its direct peers might be defrauding it, leading to...
> > * ...the money it *thinks* it has in its channels being valueless.
> >
> > Thus, if the light client opportunistically pays for validation information (whether full blocks, headers, or filters), the direct peers it has could just as easily not forward any payments, thus preventing the light client from paying for the validation information.
> >
> > Indeed, if the direct peer *is* defrauding the light client, the direct peer has no real incentive to actually forward *any* payments --- to do so would be to reduce the possible earnings it gets from defrauding the light client.
> > ("Simulating" the payments so that the light client will not suspect anything runs the risk that the light client will be able to forward all its money out of the channel, and the cheating peer is still potentially liable for any funds it originally had in the channel if it gets caught.)
>
> One question I had is: how can a malicious direct payment peer "simulate" a successful payment made by an off-grid victim peer to an information source?  The censoring peer wouldn't be able to return the preimage for a payment they failed to forward. Also, since the information provider and off-grid node can presumably communicate via their local network connection, it would be obvious if all of the victims LN peers were failing to forward payments (whether maliciously or due to routing failures) to an information provider they could otherwise communicate with.

Perhaps "simulate" is not quite the correct term.
Basically, if the eclipsing peer(s) are reasonably sure they have eclipsed the light client, then all funds in those channels are semantically theirs (they "0wn" the eclipsed light client).
Then anything the light node offers from those channels (which it thinks are its, but are now in reality owned by the eclipsing peer) has no value (the eclipsing node already 0wns the light node and all its funds, what can the light node offer to it?).
The eclipsing peer could still "simulate" what the light node expects of reality by pretending that the light node actually still owns funds in the channel (even though the eclipsing node has successfully stolen all those funds), and forward as normal to get the payment preimage/scalar.


> > What would work would be to use a system similar to watchtowers, wherein the validation-information-provider is prepaid and issues tokens that can be redeemed later.
> > But this is not suitable for opportunistic on-same-WiFi where, say, a laptop is running a validation-information-provider-for-payment program on the same WiFi as a light-client mobile phone, if we consider that the laptop and mobile may have never met before and may never meet again.
> > It would work if the laptop altruistically serves the blocks, but not if it were for (on-Lightning) payment.
>
> There's another problem if we can't rely on a recurring relationship with an information provider besides not being able to prepay for validation information doesn't make sense. We don't want an information provider to collect payments for serving invalid information. Maybe for very small payments this isn't a problem, but ideally validity could be coded into the HTLC.
>
> For example, an alternative HTLC construct that only paid for valid 81 B headers that hash to 32 B values with a number of leading zeros committed to by the HTLC. It would make more economic sense for an internet gateway node to serve valid mined header to nodes on their local WiFi network than to create bogus ones with the same (high) amount of work.

If you are considering this for on-Lightning payments, do note that the alternative HTLC construct has to be known by every forwarding node, including the direct peer(s) of the light client, which are precisely the potential attackers on the light client.

It seems to be impractical for onchain payments: the provider can drop the data onchain to claim the funds, but it is precisely the blockchain data that the light client does not have direct access to, so ---


>  
>
> > So it seems to me that this kind of service is best ridden on top of watchtower service providers.
>
> Public watchtowers or some sort of HTTP proxy data cache similar to a watchtower makes the most sense to me because they would be expected to be economically motivated and LN payment aware. Full nodes could potentially be incentivized to exchange new data with other nodes in a tit-for-tat way, but I don't expect them to be incentivized by light clients using LN micropayments in a server-client arrangement.
>
> Network agents that monetize full node information services beyond channel monitoring would be more than just a "Watchtower" for light clients. Would they be more like incentivized Electrum servers?

Possibly.

> Are there still privacy concerns when they serve generic/un-personalized headers/filters/blocks to light clients?

It marks the client as a light client, at least.

Someone who gets read-only access to the logs of such a public-service node now has a list of light clients.
If the light clients are in any way identifiable and locatable, the hacker can then attempt to hack the light client and redirect their understanding of what the public-service node is (e.g. DNS poisoning) and then start performing other attacks on the client once its view of the blockchain is eclipsed.

This would be helped if the light client, for example, always uses Tor to access the public-service node, if payments for services of that node are decorrelated (e.g. tokens issued by the node that will later be reclaimed for service are blinded), etc.
Such would make the light client harder to locate in the first place.

(While a mobile client can certainly access the Internet over various access points, most people who own mobile devices have a home they go to at night, which often has Internet access, possibly with a stable identifiable location that can be attacked)

> A personal, altruistic or friends and family watchtower is also possible, but I'm thinking about how light clients without this possibility can be served.

This is probably something we can expect to see as well; though it should be noted, for those philosophically interested in such things, that these are the genesis of governments and states.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

[Chris Belcher]

On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> 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.
>>
> 
> Hi Luke,
> 
> I have heard this claim made several times but have never understood the
> argument behind it. The question I always have is: If I get scammed by not
> verifying my incoming transactions properly how can this affect anyone
> else? It's very unintuative.  I've been scammed several times in my life in
> fiat currency transactions but as far as I could tell it never negatively
> affected the currency overall!
> 
> The links you point and from what I've seen you say before refer to "miner
> control" as the culprit. My only thought is that this is because a light
> client could follow a dishonest majority of hash power chain. But this just
> brings me back to the question. If, instead of BTC, I get a payment in some
> miner scamcoin on their dishonest fork (but I think it's BTC because I'm
> running a light client) that still seems to only to damage me. Where does
> the side effect onto others on the network come from?
> 
> Cheers,
> 
> LL
> 

Hello Lloyd,

The problem comes when a large part of the ecosystem gets scammed at
once, which is how such an attack would happen in practice.

For example, consider if bitcoin had 10000 users. 10 of them use a full
node wallet while the other 9990 use an SPV wallet. If a miner attacked
the system by printing infinite bitcoins and spending coins without a
valid signature, then the 9990 SPV wallets would accept those fake coins
as payment, and trade the coins amongst themselves. After a time those
coins would likely be the ancestors of most active coins in the
9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:
full-node-coin and SPV-coin.

Now the fraud miners may become well known, perhaps being published on
bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong
incentive to be against any rollback. Their recent transactions would
disappear and they'd lose money. They would argue that they've already
been using the coin for a while, and it works perfectly fine, and anyway
a coin that can be spent in 9990 places is more useful than one that can
be spent in just 10 places. The SPV-wallet community might even decide
to use something like `invalidateblock` to make sure their SPV-coin
doesn't get reorg'd out of existence. There'd also likely be a social
attack, with every bitcoin community portal being flooded with bots and
shills advocating the merits of SPV-coin. This is not a hypothetical
because we already saw the same thing during the scalability conflict
2015-2017.

Before you know it, "Bitcoin" would become SPV-coin with inflation and
arbitrary seizure. Any normal user could download software called
"Bitcoin wallet" which they trust and have used before, but instead of
using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallets
backed by a full node, but that won't do much good to you when 9990
users happily use another coin as their medium of exchange.

Regards
CB

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

Hi Chris,

While approaching this question, I think you should consider economic
weight of nodes in evaluating miner consensus-hijack success. Even if you
expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
same  economic weight at all, therefore even if miners are able to lure a
majority of SPV clients they may not be able to stir economic nodes. SPV
clients users will now have an incentive to cancel their hijacked history
to stay on the most economic meaningful chain. And it's already assumed,
that if you run a bitcoin business or LN routing node, you do want to run
your own full-node.

I agree it may be hard to evaluate economic-weight-to-chain-backend
segments, specially with offchain you disentangle an onchain output value
from its real payment traffic. To strengthen SPV, you may implement forks
detection and fallback to some backup node(s) which would serve as an
authoritative source to arbiter between branches. Such backup node(s) must
be picked up manually at client initialization, before any risk of conflict
to avoid Reddit-style of hijack during contentious period or other massive
social engineering. You don't want autopilot-style of recommendations for
picking up a backup nodes and avoid cenralization of backups, but somehow a
uniform distribution. A backup node may be a private one, it won't serve
you any data beyond headers, and therefore you preserve public nodes
bandwidth, which IMO is the real bottleneck. I concede it won't work well
if you have a ratio of 1000-SPV for 1-full-node and people are not
effectively able to pickup a backup among their social environment.

What do you think about this model ?

Cheers,

Antoine

Le mar. 12 mai 2020 à 17:06, Chris Belcher <belcher@riseup.net> a écrit :

> On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> >>> 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.
> >>
> >
> > Hi Luke,
> >
> > I have heard this claim made several times but have never understood the
> > argument behind it. The question I always have is: If I get scammed by
> not
> > verifying my incoming transactions properly how can this affect anyone
> > else? It's very unintuative.  I've been scammed several times in my life
> in
> > fiat currency transactions but as far as I could tell it never negatively
> > affected the currency overall!
> >
> > The links you point and from what I've seen you say before refer to
> "miner
> > control" as the culprit. My only thought is that this is because a light
> > client could follow a dishonest majority of hash power chain. But this
> just
> > brings me back to the question. If, instead of BTC, I get a payment in
> some
> > miner scamcoin on their dishonest fork (but I think it's BTC because I'm
> > running a light client) that still seems to only to damage me. Where does
> > the side effect onto others on the network come from?
> >
> > Cheers,
> >
> > LL
> >
>
> Hello Lloyd,
>
> The problem comes when a large part of the ecosystem gets scammed at
> once, which is how such an attack would happen in practice.
>
> For example, consider if bitcoin had 10000 users. 10 of them use a full
> node wallet while the other 9990 use an SPV wallet. If a miner attacked
> the system by printing infinite bitcoins and spending coins without a
> valid signature, then the 9990 SPV wallets would accept those fake coins
> as payment, and trade the coins amongst themselves. After a time those
> coins would likely be the ancestors of most active coins in the
> 9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:
> full-node-coin and SPV-coin.
>
> Now the fraud miners may become well known, perhaps being published on
> bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong
> incentive to be against any rollback. Their recent transactions would
> disappear and they'd lose money. They would argue that they've already
> been using the coin for a while, and it works perfectly fine, and anyway
> a coin that can be spent in 9990 places is more useful than one that can
> be spent in just 10 places. The SPV-wallet community might even decide
> to use something like `invalidateblock` to make sure their SPV-coin
> doesn't get reorg'd out of existence. There'd also likely be a social
> attack, with every bitcoin community portal being flooded with bots and
> shills advocating the merits of SPV-coin. This is not a hypothetical
> because we already saw the same thing during the scalability conflict
> 2015-2017.
>
> Before you know it, "Bitcoin" would become SPV-coin with inflation and
> arbitrary seizure. Any normal user could download software called
> "Bitcoin wallet" which they trust and have used before, but instead of
> using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallets
> backed by a full node, but that won't do much good to you when 9990
> users happily use another coin as their medium of exchange.
>
> Regards
> CB
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[ZmnSCPxj]

Good morning Antoine,


> While approaching this question, I think you should consider economic weight of nodes in evaluating miner consensus-hijack success. Even if you expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the same  economic weight at all, therefore even if miners are able to lure a majority of SPV clients they may not be able to stir economic nodes. SPV clients users will now have an incentive to cancel their hijacked history to stay on the most economic meaningful chain. And it's already assumed, that if you run a bitcoin business or LN routing node, you do want to run your own full-node.

One hope I have for Lightning is that it will replace centralized custodial services, because:

* Lightning gains some of the scalability advantage of centralized custodial services, because you can now transfer to any Lightning client without touching the blockchain, for much reduced transfer fees.
* At the same time, it retains your-keys-your-coins noncustodiality, because every update of a Lightning channel requires your keys to sign off on it.

If most Lightning clients are SPV, then if we compare these two worlds:

* There are a few highly-important centralized custodial services with significant economic weight running fullnodes (i.e. now).
* There are no highly-important centralized custodial services, and most everyone uses Lightning, but with SPV (i.e. a Lightning future).

Then the distribution of economic weight would be different between these two worlds.
It may even be possible, that the Lightning future with massive SPV might end up with more economic weight in SPV nodes, than in the world without Lightning and dependent on centralized custodial services to scale.


It is also entirely possible that custodial services for Lightning will arise anyway and my hope is already dashed, come on universe, work harder will you, would you really disappoint some randomly-generated Internet person like that.


>
> I agree it may be hard to evaluate economic-weight-to-chain-backend segments, specially with offchain you disentangle an onchain output value from its real payment traffic. To strengthen SPV, you may implement forks detection and fallback to some backup node(s) which would serve as an authoritative source to arbiter between branches. Such backup node(s) must be picked up manually at client initialization, before any risk of conflict to avoid Reddit-style of hijack during contentious period or other massive social engineering. You don't want autopilot-style of recommendations for picking up a backup nodes and avoid cenralization of backups, but somehow a uniform distribution. A backup node may be a private one, it won't serve you any data beyond headers, and therefore you preserve public nodes bandwidth, which IMO is the real bottleneck. I concede it won't work well if you have a ratio of 1000-SPV for 1-full-node and people are not effectively able to pickup a backup among their social environment.
> What do you think about this model ?

Money makes the world go round, so such backup servers that are publicly-facing rather than privately-owned should be somehow incentivized to do so, or else they would not exist in the first place.
Of course, a free market tends towards monopoly, because any entity that happens to have even a slight advantage at the business will have more money to use towards business reinvestment and increase its advantage further, until they beat the competition to dust, anyone who has won a 4X game knows to search for and stack those little advantages until you snowball and conquer the world/galaxy/petri dish which is why the endgame of 4X games is so boring compared to the start, we have seen this happen in mining and exchanges and so on, and this works against your desire to have a uniform distribution.

If everyone runs such a privately-owned server, on the other hand, this is not so different from having a Lightning node you run at your home that has a fullnode as well and which you access via a remote control mobile device, and it is the inconvenience of having such a server at your home that prevents this in the first place.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Keagan McClelland]

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

> It should be therefore a top priority to make the UX of connecting my
mobile LN client to my home full node extremely easy, so that centralised
services can't improve much on that step. Especially if I already run a
full node.

For what it's worth, this is a main research area for us at Start9 Labs.

> Could someone briefly describe how this UX looks currently? And if it's
not as seamless as it could, what blockers are there?

At the root of all of these problems is that a "private server" is
considered inconvenient. There is no fundamental reason this has to be the
case. The main UX challenges we've found are around installation and
configuration of server applications, not to mention, that users don't have
an existing mental model for how to imagine applications. Most people who
do not work on computers for a living have heard of servers but their
firsthand experience with software is "apps". The fact that there is a
component of their applications that runs remotely on computers they don't
own.

So in short:
1. Educating on the distinction between client and server apps is an open
question whose burden will likely fall on the entire industry if we want to
get this right and not have an exchange takeover of Bitcoin.
2. Apps that either require "zero configuration" or have very easy in-app
walkthroughs of the bare essentials of configuration
3. GUI style installs of server applications familiar to those who have
installed desktop or mobile software.

I'm sure there are more things we'll learn as we grow but these are the top
three observations we've made and this is our primary area of work.

> Private full nodes serving headers to a handful of weak devices have been
mentioned many times as a good solution against all sorts of problems in a
future full of LN + SPV nodes. I agree.

This is the main thesis I've been going on for a while. Once your full node
has synced the whole blockchain and the total set of headers is known, you
don't actually even need to carry 100% of the block data, as you can
re-fetch a needed block from elsewhere and verify the block data matches
the header you've already checked for consensus. From there the header
chain can serve as base truth for a whole set of L2+ services or L1 SPV
wallets. Ideally, in a model like this, more expensive peer services would
be authenticated so that your other applications could get the data they
need without exposing your full node to the extra costs of those who are
not running their own nodes. Typically we've used Core's RPC API for this
but as others have mentioned upthread JSON is a wasteful format and there
are good reasons that you'd want Lightning to be able to request peer
services without necessarily having ownership control over the node.

The other thing I wanted to note is the fact that the issue isn't that
Lightning does SPV, the issue is around whether or not the node it is
tethered to is *actually* trusted since SPV necessarily trusts some
dimensions of the information supplied to it. Doing SPV against a full node
you own is no more dangerous than indexing watch only addresses in Core and
then asking for wallet/utxo information over RPC.

Keagan

On Thu, May 14, 2020 at 12:50 AM Orfeas Stefanos Thyfronitis Litos <
o.thyfronitis@ed.ac.uk> wrote:

>
>
> >If everyone runs such a privately-owned server, on the other hand, this
> >is not so different from having a Lightning node you run at your home
> >that has a fullnode as well and which you access via a remote control
> >mobile device, and it is the inconvenience of having such a server at
> >your home that prevents this in the first place.
>
> Private full nodes serving headers to a handful of weak devices have been
> mentioned many times as a good solution against all sorts of problems in a
> future full of LN + SPV nodes. I agree. It should be therefore a top
> priority to make the UX of connecting my mobile LN client to my home full
> node extremely easy, so that centralised services can't improve much on
> that step. Especially if I already run a full node.
>
> Could someone briefly describe how this UX looks currently? And if it's
> not as seamless as it could, what blockers are there?
>
> Best,
> Orfeas
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[William Casarin]

Orfeas Stefanos Thyfronitis Litos <o.thyfronitis@ed.ac.uk> writes:
> ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes:
>> If everyone runs such a privately-owned server, on the other hand, this
>> is not so different from having a Lightning node you run at your home
>> that has a fullnode as well and which you access via a remote control
>> mobile device, and it is the inconvenience of having such a server at
>> your home that prevents this in the first place.
>
> Private full nodes serving headers to a handful of weak devices have
> been mentioned many times as a good solution against all sorts of
> problems in a future full of LN + SPV nodes. I agree. It should be
> therefore a top priority to make the UX of connecting my mobile LN
> client to my home full node extremely easy, so that centralised
> services can't improve much on that step. Especially if I already run
> a full node.
>
> Could someone briefly describe how this UX looks currently? And if
> it's not as seamless as it could, what blockers are there?

The UX for this doesn't have to be complicated. All you need is a node
provider like FullyNoded, Casa, etc. My setup at home is a desktop with:

  - bitcoind
  - clightning
  - zerotier (or tailscale) (private vpn for connecting to your node from anywhere)
  - sparkwallet (clightning webui) bound to a zerotier interface

So as long as you have a node that runs these bits of software, perhaps
assumeutxo to speed up IBD, and a QR-code automagic setup, then UX
should be pretty smooth. You would still need to deal with lightning
backups and liquidity issues, but we just need to do more work on the
software side to make that experience nicer.

Cheers,
Will


--
https://jb55.com

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Antoine Riard]

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

> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
on it.

Yes I agree, I can foresee an easier step where managing low-value channel
and get your familiar with smooth key management maybe a first step before
running a full-node and getting a more full-fledged key management solution.

> It may even be possible, that the Lightning future with massive SPV might
end up with more economic weight in SPV nodes, than in the world without
Lightning and dependent on centralized custodial services to scale.

Even evaluating economic weight in Lightning is hard, both parties have
their own chain view, and it's likely if you assume a hub-and-spoke
topology, leaf nodes are going to be SPV and internal nodes full-nodes ?

> Money makes the world go round, so such backup servers that are
publicly-facing rather than privately-owned should be somehow incentivized
to do so, or else they would not exist in the first place.

I was thinking about the current workflow, Alice downloads her New Shiny
LN-wallet, she is asked to backup the seed, she is asked to pick-up
backup(s) nodes among her friends, relatives or business partners and is
NOT provided any automatic hint and register backup nodes addresses, maybe
even do out-of-band key exchange with this full-node operator. Therefore
you may avoid centralization by having not such publicly-facing servers. Of
course, Alice can still scrawl the web to and be lured to pickup malicious
public servers but if she is severely notified to not do so that may be
enough.

So it would be a combination of UX+user education+fallback security
mechanism to avoid economy hijack. That maybe a better solution rather than
PoW-only SPV. We have an open network so you can't prevent someone to run
such type of client but at least if they have to do so you can provide them
with a better option ?

Antoine




Le jeu. 14 mai 2020 à 00:02, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :

> Good morning Antoine,
>
>
> > While approaching this question, I think you should consider economic
> weight of nodes in evaluating miner consensus-hijack success. Even if you
> expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
> same  economic weight at all, therefore even if miners are able to lure a
> majority of SPV clients they may not be able to stir economic nodes. SPV
> clients users will now have an incentive to cancel their hijacked history
> to stay on the most economic meaningful chain. And it's already assumed,
> that if you run a bitcoin business or LN routing node, you do want to run
> your own full-node.
>
> One hope I have for Lightning is that it will replace centralized
> custodial services, because:
>
> * Lightning gains some of the scalability advantage of centralized
> custodial services, because you can now transfer to any Lightning client
> without touching the blockchain, for much reduced transfer fees.
> * At the same time, it retains your-keys-your-coins noncustodiality,
> because every update of a Lightning channel requires your keys to sign off
> on it.
>
> If most Lightning clients are SPV, then if we compare these two worlds:
>
> * There are a few highly-important centralized custodial services with
> significant economic weight running fullnodes (i.e. now).
> * There are no highly-important centralized custodial services, and most
> everyone uses Lightning, but with SPV (i.e. a Lightning future).
>
> Then the distribution of economic weight would be different between these
> two worlds.
> It may even be possible, that the Lightning future with massive SPV might
> end up with more economic weight in SPV nodes, than in the world without
> Lightning and dependent on centralized custodial services to scale.
>
>
> It is also entirely possible that custodial services for Lightning will
> arise anyway and my hope is already dashed, come on universe, work harder
> will you, would you really disappoint some randomly-generated Internet
> person like that.
>
>
> >
> > I agree it may be hard to evaluate economic-weight-to-chain-backend
> segments, specially with offchain you disentangle an onchain output value
> from its real payment traffic. To strengthen SPV, you may implement forks
> detection and fallback to some backup node(s) which would serve as an
> authoritative source to arbiter between branches. Such backup node(s) must
> be picked up manually at client initialization, before any risk of conflict
> to avoid Reddit-style of hijack during contentious period or other massive
> social engineering. You don't want autopilot-style of recommendations for
> picking up a backup nodes and avoid cenralization of backups, but somehow a
> uniform distribution. A backup node may be a private one, it won't serve
> you any data beyond headers, and therefore you preserve public nodes
> bandwidth, which IMO is the real bottleneck. I concede it won't work well
> if you have a ratio of 1000-SPV for 1-full-node and people are not
> effectively able to pickup a backup among their social environment.
> > What do you think about this model ?
>
> Money makes the world go round, so such backup servers that are
> publicly-facing rather than privately-owned should be somehow incentivized
> to do so, or else they would not exist in the first place.
> Of course, a free market tends towards monopoly, because any entity that
> happens to have even a slight advantage at the business will have more
> money to use towards business reinvestment and increase its advantage
> further, until they beat the competition to dust, anyone who has won a 4X
> game knows to search for and stack those little advantages until you
> snowball and conquer the world/galaxy/petri dish which is why the endgame
> of 4X games is so boring compared to the start, we have seen this happen in
> mining and exchanges and so on, and this works against your desire to have
> a uniform distribution.
>
> If everyone runs such a privately-owned server, on the other hand, this is
> not so different from having a Lightning node you run at your home that has
> a fullnode as well and which you access via a remote control mobile device,
> and it is the inconvenience of having such a server at your home that
> prevents this in the first place.
>
> Regards,
> ZmnSCPxj
>

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Christopher Allen]

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

On Thu, May 14, 2020 at 8:30 AM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > It should be therefore a top priority to make the UX of connecting my
> mobile LN client to my home full node extremely easy, so that centralised
> services can't improve much on that step. Especially if I already run a
> full node.
>

There already is an emerging approach for this, called QuickConnect
https://github.com/BlockchainCommons/Bitcoin-Standup/blob/master/Docs/Quick-Connect-API.md

It is currently offered by BitcoinStandup (both Mac and Linux),
BTCPayServer, Nodl, MyNode, RaspiBlitz full node tools and hardware, and is
used currently by FullyNoded, FullyNoded2, and a couple of other
experimental apps to allow secure connection via Tor v3 from a remote to
your own personal full node.

We know that QuickConnect needs another major iteration and welcome
contributions to requirements and/or proposals for the next version.

We invite you to share your thoughts here.
https://github.com/BlockchainCommons/Bitcoin-Standup/issues/66

— Christopher Allen

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