Lloyd Fournier [ARCHIVE] on Nostr: đź“… Original date posted:2020-11-30 đź“ť Original message: On Mon, Nov 30, 2020 at ...
đź“… Original date posted:2020-11-30
đź“ť Original message:
On Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko <naumenko.gs at gmail.com> 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
> proposed by t-bast, where every link in the route proves something to the
> next hop.
> For the context see this post, specifically “point-to-point property”:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002888.html
>
Thanks for the correction.
>
> I think you managed to apply the same argument to our original proposal as
> well :)
>
> > 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).
>
> I think the issue here is with loop attacks (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)?
> This restriction with locking funds doesn’t really work…
> After getting past their intermediate hop, an attacker can make arbitrary
> loops and lock 100 BTC channels even by just having 1 BTC locked in the
> initial hop.
>
> Stake Certificates allow for a node in the middle of the route to
> distinguish where the payment is coming from (in a privacy-preserving
> manner of course), to distinguish heavy channel users from normal.
> They also allow to force an attacker to distribute jamming in time and
> across many channels.
>
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 attacks might be much easier than stake
certificates.
> Perhaps, alternative restrictions may take place by restricting based on
> from which immediate channel/node they are coming (one-hop). But that
> sounds like a mess, as a payment sender doesn’t have any control, and
> gossiping that would probably be a privacy leak, also it still allows free
> jamming I think (just a bit different).
> The big deal here is to distinguish the flows, to better control them.
> We can discuss this separately.
>
> It’s true that any token might achieve the same goal here, but how to make
> it Sybil-resistant and prevent generating new tokens? Stake Certificates, I
> don’t know what else we can commit to.
>
> > If we are talking about non-economic adversaries who simply wish to
> destroy LN then that’s another game altogether.
>
> I was thinking about this scenario all the way, but maybe I should think
> about the other one as well.
>
>
But if we are talking about large holders of Bitcoin that just want to
destory LN this seems like a very weak mitigation since they will be able
to produce stake certificates galore and lock up channels anyway.
I don't see much of a way around this other than reputation systems.
LL
>
> – gleb
> On Nov 30, 2020, 6:39 AM +0200, Lloyd Fournier <lloyd.fourn at gmail.com>,
> wrote:
>
> 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/20201201/84676029/attachment-0001.html>;
đź“ť Original message:
On Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko <naumenko.gs at gmail.com> 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
> proposed by t-bast, where every link in the route proves something to the
> next hop.
> For the context see this post, specifically “point-to-point property”:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002888.html
>
Thanks for the correction.
>
> I think you managed to apply the same argument to our original proposal as
> well :)
>
> > 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).
>
> I think the issue here is with loop attacks (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)?
> This restriction with locking funds doesn’t really work…
> After getting past their intermediate hop, an attacker can make arbitrary
> loops and lock 100 BTC channels even by just having 1 BTC locked in the
> initial hop.
>
> Stake Certificates allow for a node in the middle of the route to
> distinguish where the payment is coming from (in a privacy-preserving
> manner of course), to distinguish heavy channel users from normal.
> They also allow to force an attacker to distribute jamming in time and
> across many channels.
>
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 attacks might be much easier than stake
certificates.
> Perhaps, alternative restrictions may take place by restricting based on
> from which immediate channel/node they are coming (one-hop). But that
> sounds like a mess, as a payment sender doesn’t have any control, and
> gossiping that would probably be a privacy leak, also it still allows free
> jamming I think (just a bit different).
> The big deal here is to distinguish the flows, to better control them.
> We can discuss this separately.
>
> It’s true that any token might achieve the same goal here, but how to make
> it Sybil-resistant and prevent generating new tokens? Stake Certificates, I
> don’t know what else we can commit to.
>
> > If we are talking about non-economic adversaries who simply wish to
> destroy LN then that’s another game altogether.
>
> I was thinking about this scenario all the way, but maybe I should think
> about the other one as well.
>
>
But if we are talking about large holders of Bitcoin that just want to
destory LN this seems like a very weak mitigation since they will be able
to produce stake certificates galore and lock up channels anyway.
I don't see much of a way around this other than reputation systems.
LL
>
> – gleb
> On Nov 30, 2020, 6:39 AM +0200, Lloyd Fournier <lloyd.fourn at gmail.com>,
> wrote:
>
> 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/20201201/84676029/attachment-0001.html>;