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

2020-05-08 Thread Christopher Allen via bitcoin-dev
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

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

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

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 don

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

2020-05-08 Thread Braydon Fuller via bitcoin-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 you can pick yo

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

2020-05-08 Thread Braydon Fuller via bitcoin-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 good for this > and *didn't*

Re: [bitcoin-dev] Revault: a multi-party vault architecture

2020-05-08 Thread darosior via bitcoin-dev
The fee bumping construction I described in the previous post is potentially vulnerable to transaction pinning. We shared a SINGLE | ANYONECANPAY signature for the first (and only) input of revaulting transactions to allow any party to append an input and an output in order to bump the transac

[bitcoin-dev] Compressed block headers

2020-05-08 Thread Will Clark via bitcoin-dev
Hello list, I would like to propose a compressed block header scheme for IBD and block announcements. This proposal is derivative of previous proposals found on this list (see links in spec below) with some modifications and clarifications. The below specification (also found at https://github