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 certificates to LN funding txs, which have a
very specific format
(multisig 2-of-2) there are probably smart ways to achieve this.
If for example we're able to do it easily with Schnorr-based funding txs,
it may be worth
waiting for that to happen.
I'm a bit afraid of having to use ZKPs for general statements, I'd prefer
something tailored
to that specific case (it would likely be more efficient and have less new
assumptions - even
though you're right to point out that this is a non-critical system, so
we're freer to experiment
with hot new stuff).
I completely agree with Z that it should be added to the requirements that
a node cannot
reuse a stake certificate from another node for himself.
Another constraint is that the proof has to be small, since we have to fit
> it all in a small onion...
>
I'm not sure that's necessary. If I understand correctly, you're saying
that because in your
model, the sender (Alice) creates one stake certificate for each node in
the route (Bob, Carol)
and puts them in the onion.
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 so on. If that's the case, it
can be in a tlv field in the
`update_add_htlc` message and doesn't need to be inside the onion. This
also makes it less
likely that Alice is exposing herself to remote nodes in the route (payer
privacy).
Of course, this depends on the implementation details we choose, but I
think it's worth stressing
that these two models exist and are quite different.
Thanks,
Bastien
Le ven. 27 nov. 2020 à 07:46, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> a écrit :
> 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 jamming opportunities for no good.
> >
> > You are right, that’s a strong argument for proof “interactivity”: every
> Certificate should probably commit to *at least* public key of the routing
> node it is generated for.
>
> Right, it would be better to have the certificate commit to a specific
> routing node rather than the payment hash/point as I proposed.
> Committing to a payment hash/point allows a random forwarding node to
> probe the rest of the network using the same certificate, lowering the
> score for that certificate on much of the network.
>
> Another constraint is that the proof has to be small, since we have to fit
> it all in a small onion...
>
> Presumably we also want the score to eventually "settle to 0" over time.
>
> Regards,
> ZmnSCPxj
>
> >
> > – gleb
> > On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj ,
> wrote:
> >
> > > 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 of the current payment (such as payment hash/point) so
> it cannot be reused by routing nodes for their own outgoing payments.
> > >
> > > For example, looking only at your naive privacy-broken proposal, the
> signature must use a `sign-to-contract` where the `R` in the signature is
> actually `R' + h(R' | payment_hash)` with the `R'` also revealed.
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > > 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
> Certificates) to solve this problem. Previously, these proofs were only
> used in the Lightning Network at channel announcement time to prevent
> malicious actors from announcing channels they don’t control. One can think
> of it as a “fidelity bond” (as a scarce resource) as a requirement for
> sending HTLCs.
> > > >
> > > > We start by overviewing issues with other solutions, and then
> present a naive, privacy-broken Stake Certificates. Then we examine
> designing a privacy-preserving version, evaluating them. At the end, we
> talk about non-trivial design decisions and open questions.
> > > >
> > > > ## Issues with other proposals
> > > >
> > > > We find unsatisfying that upfront
