___
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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
>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 ser
t all sorts of
> problems in a future full of LN + SPV nodes. I agree. 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 al
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
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
ing a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, whic
ce BIP157 clients,
in the hope that a BIP157 client can contact any arbitrary fullnode to get
BIP157 service.
This is supposed to improve to the situation relative to e.g. Electrum, where
there are far fewer Electrum servers than fullnodes.
Of course, as ariard computes, deploying BIP157 could
o, and having a LN wallet maybe even a
first-step to it.
Designing a mobile-first LN experience opens its own gap of challenges
especially in terms of security and privacy. The problem can be scoped as
how to build a scalable, secure, private chain access backend for millions
of LN clients ?
Light c
Good morning Richard, and all,
> 2) a light client can query an ISP connected full node on the same unmetered
> local WiFi network and exchange differences in block headers
> opportunistically or pay for large missing ranges of headers, filters or full
> blocks using a payment c
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
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
f challenges
>> especially in terms of security and privacy. The problem can be scoped as
>> how to build a scalable, secure, private chain access backend for millions
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum are used),
>
opportunity to reflect on the future of light client protocols and use this
> knowledge to make better-informed decisions about what kind of
> infrastructure is needed to support mobile clients at large scale.
>
> Trust-minimization of Bitcoin security model has always relied first and
&
all the
way to things RPC can’t do like deleting a wallet and changing bitcoin.conf
parameters and rebooting, without requiring full ssh access to the server
running the node.
If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Bl
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 connect
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
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 altern
ldn't foster node
> adoption when people are able to do so, and having a LN wallet maybe even a
> first-step to it.
>
> Designing a mobile-first LN experience opens its own gap of challenges
> especially in terms of security and privacy. The problem can be scoped as
> how to build a scalabl
others oppose merging support for BIP
>> 157 in
>> > Core.
>>
>> BIP 157 can be implemented as a separate daemon that processes the blocks
>> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>>
>> The intention, as I understood it, of put
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
l, therefore even if miners are able to lure a majority
> of SPV clients they may not be able to stir economic nodes. SPV clients users
> will now have an incentive to cancel their hijacked history to stay on the
> most economic meaningful chain. And it's already assumed, that if you ru
Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
concern as: A node without direct internet connectivity can not rely on an
opportunistically incentivized local network peer for blockchain
information because the off-grid node's direct LN peers could collude to
not fo
ers, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a mobile-firs
pecially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a mobile-first LN experi
Thanks Antoine for starting this thread, I've also been curious about the
current thinking on light clients and incentivized full node services after
seeing the LSAT work.
On Wed, May 6, 2020 at 11:40 AM Antoine Riard
wrote:
>
> Yeah, I hadn't time to read the spec yet but
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
ne
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 sec
> 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
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 adoption without users
Good morning Richard,
> Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
> concern as: A node without direct internet connectivity can not rely on an
> opportunistically incentivized local network peer for blockchain information
> because the off-grid node
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
m 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 built on top is going to rely on centralized services for its chain
> acce
lure a
majority of SPV clients they may not be able to stir economic nodes. SPV
clients users will now have an incentive to cancel their hijacked history
to stay on the most economic meaningful chain. And it's already assumed,
that if you run a bitcoin business or LN routing node, you do want t
ey may not be able to stir economic nodes. SPV
> clients users will now have an incentive to cancel their hijacked history
> to stay on the most economic meaningful chain. And it's already assumed,
> that if you run a bitcoin business or LN routing node, you do want to run
> your o
35 matches
Mail list logo
