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

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

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

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

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

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

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