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. This still requires locking funds by an attacker
2. We might start with a low credit for just random valid Stake Certificates, 
but increase if they showed good activity: e.g., they we route through them a 
lot, or they paid us a lot of fees previously. Both ideas would require some 
extra work of linking Stake Certificates to these activities in a private 
matter. The paid-fees one should be easier.
3. We might give more credit if they or their channel counterparty is just a 
known good actor. This can be achieved by a routing node have this second list 
of trustworthy UTXOs payment sender may prove inclusion for.

(2) and (3) may be just a part of routing node Stake Certificate acceptance 
policy, I think if we like the ideas, new can make them work in a desirable 
private/scalable way.

We might also have senders proving that they paid fees to *other* (real) 
non-Sybil routing nodes, although it adds even more complexity.

Also, now that I’m thinking, maybe payment receiver could also contribute to 
the Stake Certificate…

>How would a stake certificate prove that the UTXO was generated for LN rather 
>than just belonging to a user with a 2-of-2 multisig wallet or any 
>key-path-spendable taproot wallet?)

You are right, we can only get so close to proving that it’s indeed a payment 
channel. I think the problem of channels-with-themselves (see a beginning of 
this response) includes this one, so if we solve that, this won’t be a big deal.

>That cost doesn’t seem high enough to me to effectively prevent attacks.

Perhaps having 1000 BTC staked should not allow them to send 1000 BTC over 
Lightning, but maybe, with Stake Certificates, this could be restricted to say 
100 BTC per 0.1 hour?
This, of course, requires hypothesizing about honest economic activity in the 
Lightning Network.
The exact economics of Stake Certificates still has to be worked out, I’m just 
suggesting that we probably have a lot flexibility with restrictions, since 
we’re very permissive towards users to begin with.

– gleb
On Nov 28, 2020, 8:25 PM +0200, David A. Harding <d...@dtrt.org>, wrote:
> 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 Certificates?
> >
> > [...] we believe that allowing any UTXO would give an attacker more
> > opportunities to use their cold funds for this attack, or even have a
> > secondary market where holders sell their proofs (they have nothing to
> > loose).
>
> Can't a malicious user get around this restriction by opening channels
> with themself? (Also, aren't current channel open outputs just P2WSH
> 2-of-2 multisigs, and in the future won't they be generic P2TR outputs?
> How would a stake certificate prove that the UTXO was generated for LN
> rather than just belonging to a user with a 2-of-2 multisig wallet or
> any key-path-spendable taproot wallet?)
>
> According to some random website, the current total channel balance of
> the public LN is about 1,000 BTC. Although I'm sure this will grow with
> time, it seems to me that an attacker who can rent access to stake
> certificates for a one-week attack at, say, a 5% annual interest rate
> would only need to pay 1 BTC to acquire stake certificates equal to all
> honest users at present. That cost doesn't seem high enough to me to
> effectively prevent attacks. Am I missing something?
>
> Thanks,
>
> -Dave
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to