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

2020-05-25 Thread Christopher Allen
On Thu, May 14, 2020 at 8:30 AM Keagan McClelland via bitcoin-dev < [email protected]> 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

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

2020-05-08 Thread Braydon Fuller via Lightning-dev
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

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

2020-05-08 Thread Keagan McClelland
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 wrote: > On 5/6/20 9:07 PM, Keagan McClelland wrote: > > > I think that one

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

2020-05-08 Thread Braydon Fuller via Lightning-dev
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 g

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

2020-05-25 Thread Christopher Allen
On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev < [email protected]> 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 own

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

2020-05-06 Thread Keagan McClelland
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 wrote: > What I'm thinking more is if the costs of security are being too much > externalized fro

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

2020-05-06 Thread Keagan McClelland
capture by exchanges or HNWI's as we are about miners. Keagan On Wed, May 6, 2020 at 3:06 AM Antoine Riard 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 a

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

2020-05-06 Thread Antoine Riard
twork 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 a écrit : > Hi Antoine, > > Consensus capture by miners isn't the only concern here. Consensus capture >

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

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

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

2020-05-09 Thread Antoine Riard
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 co