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

Thu May 7 04:07:09 UTC 2020

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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200506/26bac9b9/attachment.html>