Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-11-30 📝 Original message: Hi Gleb et al, I really ...
📅 Original date posted:2020-11-30
📝 Original message:
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 is missing a strong argument as to why
this is a better "proof-of-stake" than channel balances themselves.
In order to send a jamming HTLC you have to have to lock up funds to do it
(they need outgoing balance for the sender and incoming balance for the
receiver).
Why would stake certificates be more powerful than this? I get that you
decrement the UTXO's credit even if they fail. This increases the cost of
sending spam (but it also increases the cost of sending normal payments
since you now may be honest but have all your UTXOs run out of credit.)
Does this increased cost (it was not zero before) actually prevent the
attack without inhibiting normal usage?
In general there seems to be an open question about whether these channel
jamming attacks are actually economic.
If I want to get more payments routed through me would it really be optimal
to do channel jamming?
Suppose that the nodes react to the jamming by adding extra capacity by
splicing out from somewhere else. Then I have jammed up my own coins and
got nothing for it.
What if instead of attacking I allocated the coins instead to creating more
valuable channels. Couldn't this be more profitable?
I just posed this question in [1].
If we are talking about non-economic adversaries who simply wish to destroy
LN then that's another game altogether.
For example if the CCP with its 1% of all Bitcoin it seized from the
plustoken scam were to try and attack lightning they would likely succeed
even if we had this system in place simply because they have a lot of
"stake".
As David points out I don't think you can make a distinction between real
LN outputs and fake ones.
It seems unavoidable that any coins you own could be used to produce a
certificate to give you spam bandwidth (especially if you actually manage
to guarantee privacy through ZKPs).
[1] https://github.com/t-bast/lightning-docs/issues/7
Cheers,
LL
On Sun, Nov 29, 2020 at 5:25 AM 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201130/a4049932/attachment.html>;
📝 Original message:
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 is missing a strong argument as to why
this is a better "proof-of-stake" than channel balances themselves.
In order to send a jamming HTLC you have to have to lock up funds to do it
(they need outgoing balance for the sender and incoming balance for the
receiver).
Why would stake certificates be more powerful than this? I get that you
decrement the UTXO's credit even if they fail. This increases the cost of
sending spam (but it also increases the cost of sending normal payments
since you now may be honest but have all your UTXOs run out of credit.)
Does this increased cost (it was not zero before) actually prevent the
attack without inhibiting normal usage?
In general there seems to be an open question about whether these channel
jamming attacks are actually economic.
If I want to get more payments routed through me would it really be optimal
to do channel jamming?
Suppose that the nodes react to the jamming by adding extra capacity by
splicing out from somewhere else. Then I have jammed up my own coins and
got nothing for it.
What if instead of attacking I allocated the coins instead to creating more
valuable channels. Couldn't this be more profitable?
I just posed this question in [1].
If we are talking about non-economic adversaries who simply wish to destroy
LN then that's another game altogether.
For example if the CCP with its 1% of all Bitcoin it seized from the
plustoken scam were to try and attack lightning they would likely succeed
even if we had this system in place simply because they have a lot of
"stake".
As David points out I don't think you can make a distinction between real
LN outputs and fake ones.
It seems unavoidable that any coins you own could be used to produce a
certificate to give you spam bandwidth (especially if you actually manage
to guarantee privacy through ZKPs).
[1] https://github.com/t-bast/lightning-docs/issues/7
Cheers,
LL
On Sun, Nov 29, 2020 at 5:25 AM 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201130/a4049932/attachment.html>;