Good morning LL,
> Back to the general topic. Perhaps a way of refining the proposal is the
> following:
>
> 1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of
> design.
> 2. The owner (owners?) of leach LN UTXO can go to any node in the network and
> request a kind of t
> Loop attacks are not about loops, it only requires that the start and
end of a payment are controlled by the same entity
Thanks for clearing that up. I was referring to cycles in the payment paths
where you get honest parties to forward your HTLC between themselves over
and over again as part o
Hello Zeeman,
If I understand well the "point-to-point property" is the following : you
can authenticate an incoming HTLC traffic from your neighbors owing to
their expensive channels.
My concern with this approach relies on the fact that a routing node isn't
decisionary of the HTLC traffic goin
Good morning LL, and list,
> That's a very interesting point. If we were to be able to prevent loop
> attacks by the sender proving the path is well formed (without revealing who
> they are or any of the other hops) would this be an alternative solution?
> It seems to me that disabling loop att
On Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko wrote:
> Hi Lloyd,
>
> > I agree with Z that this proposal is missing a strong argument as to why
> this is a better “proof-of-stake” than channel balances themselves.
>
> I think Z’s consideration is about the alternative Stake Certificates
> propose
Hi Lloyd,
> I agree with Z that this proposal is missing a strong argument as to why this
> is a better “proof-of-stake” than channel balances themselves.
I think Z’s consideration is about the alternative Stake Certificates proposed
by t-bast, where every link in the route proves something to
Hi Dave,
Thanks for the hard questions.
>Can’t a malicious user get around this restriction by opening channels
with themself?
You are right, preventing this kind of Sybil attack is challenging, but I don’t
think it’s a no-go.
Three separate observations which make me positive about are:
1. Th
Hi Gleb et al,
I really appreciate the out-of-the-box thinking of this proposal.
I will put to the side the very difficult task of creating a cryptosystem
that efficiently achieves what's necessary for this to work because that
seems not to be the main concern.
I agree with Z that this proposal i
On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote:
>
> Hello list,
Gleb and Antoine,
This is an interesting idea! Thank you for working on it.
I had difficulty with one part of the proposal:
> Should we allow holding *any* Bitcoins (not just LN channels) for Stake
> Certific
Good morning Andres, t-bast, Gleb, et al,
> > But instead it could be a point-to-point property: each node provides its
> > own stake certificate
> > to the next node (and only to that node). Alice provides a stake
> > certificate to Bob, then Bob
> > provides a stake certificate to Carol, and
Hey,
On Fri, 27 Nov 2020 at 19:18, Bastien TEINTURIER wrote:
> Good morning list,
>
> This is an interesting approach to solve this problem, I really like the
> idea.
> It definitely deserves digging more into it: the fact that it doesn't add
> an additional
> payment makes it largely superior t
Good morning list,
This is an interesting approach to solve this problem, I really like the
idea.
It definitely deserves digging more into it: the fact that it doesn't add
an additional
payment makes it largely superior to upfront payment schemes in terms of UX.
If we restrict these stake certifi
Good morning Gleb,
> Thank you for your interest :)
>
> > Quick question: if I am a routing node and receive a valid stake
> > certificate, can I reuse this stake certificate on my own outgoing payments?
>
> That probably should be avoided, otherwise a mediocre routing node gets a lot
> of jammi
Thank you for your interest :)
> Quick question: if I am a routing node and receive a valid stake certificate,
> can I reuse this stake certificate on my own outgoing payments?
That probably should be avoided, otherwise a mediocre routing node gets a lot
of jamming opportunities for no good.
Y
Good morning Gleb and Antoine,
This is certainly interesting!
Quick question: if I am a routing node and receive a valid stake certificate,
can I reuse this stake certificate on my own outgoing payments?
It seems to me that the proof-of-stake-certificate should also somehow
integrate a detail
Hello list,
In this post, we explore a different approach to channel jamming mitigation.
We won’t talk about the background here, for the problem description as well as
some proposed solutions (mainly upfront payment schemes), see [1].
We’re suggesting using UTXO ownership proofs (a.k.a. Stake
16 matches
Mail list logo
