On Thu, May 14, 2020 at 8:30 AM Keagan McClelland via bitcoin-dev <
bitcoin-...@lists.linuxfoundation.org> 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't improve much on
There doesn't seem to be anything in the original email that's specific to
BIP 157. It's a restatement of the arguments against light clients:
- light clients are a burden on the full nodes that serve them
- if light clients become more popular, there won't be enough full nodes to
serve them
-
On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
bitcoin-...@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
> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
on it.
Yes I agree, I can foresee an easier step where managing low-value channel
and get your familiar with smooth key management maybe a first step
Orfeas Stefanos Thyfronitis Litos writes:
> ZmnSCPxj via Lightning-dev writes:
>> If everyone runs such a privately-owned server, on the other hand, this
>> is not so different from having a Lightning node you run at your home
>> that has a fullnode as well and which you access via a remote
> 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
>If everyone runs such a privately-owned server, on the other hand, this
>is not so different from having a Lightning node you run at your home
>that has a fullnode as well and which you access via a remote control
>mobile device, and it is the inconvenience of having such a server at
>your
Good morning Antoine,
> While approaching this question, I think you should consider economic weight
> of nodes in evaluating miner consensus-hijack success. Even if you expect a
> disproportionate ratio of full-nodes-vs-SPV, they may not have the same
> economic weight at all, therefore
Hi Chris,
While approaching this question, I think you should consider economic
weight of nodes in evaluating miner consensus-hijack success. Even if you
expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
same economic weight at all, therefore even if miners are able to
On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> bitcoin-...@lists.linuxfoundation.org> wrote:
>
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> Trust-minimization of Bitcoin security model has
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 could
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
> 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
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
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
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
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
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
> The choice between whether we offer them a light client technology that
is better or worse for privacy and scalability.
And offer them a solution which would scale in the long-term.
Again it's not an argumentation against BIP 157 protocol in itself, the
problem I'm interested in is how
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
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
bitcoin-...@lists.linuxfoundation.org> wrote:
> 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
Good morning ariard and luke-jr
> > 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
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
>
23 matches
Mail list logo
