Gleb Naumenko [ARCHIVE] on Nostr: đź“… Original date posted:2020-11-30 đź“ť Original message: Hi Dave, Thanks for the ...
đź“… Original date posted:2020-11-30
đź“ť Original message:
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 <dave at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201130/1155fb80/attachment.html>;
đź“ť Original message:
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 <dave at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201130/1155fb80/attachment.html>;