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 Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
[email protected]> 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 runn
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
'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 ?
>>
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),
>
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
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
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
Hey Antoine, just a small note, [3] is missing in your footnotes, can you
add it? Thanks
On Tue, 5 May 2020 at 18:17, Antoine Riard wrote:
> Hi,
>
> (cross-posting as it's really both layers concerned)
>
> Ongoing advancement of BIP 157 implementation in Core maybe the
>
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
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
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
a écrit :
> 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
>
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
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
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
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
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 <
> [email protected]> wrote:
>
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> Trust-minimization
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
19 matches
Mail list logo
