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

2020-05-07 Thread Antoine Riard via bitcoin-dev
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 buil

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

2020-05-07 Thread Keagan McClelland via bitcoin-dev
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 ligh

Re: [bitcoin-dev] Statechain implementations

2020-05-07 Thread Tom Trevethan via bitcoin-dev
Hi, An quick update on progress with our statechain implementation which we are pressing ahead with - we have started work on a version in Rust ( https://github.com/commerceblock/mercury) that is based on the 2P ECDSA gotham-city wallet from KZen (https://github.com/KZen-networks/gotham-city), and

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

2020-05-07 Thread Igor Cota via bitcoin-dev
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 ma