đź“… 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>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:01:38
in reply to nevent1q…5546
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:01:38Event JSON
{
"id": "b2aad28bf65bdf1d7af8baf00d76d9689cdeb1543b14416e1749e03b1511da93",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315698,
"kind": 1,
"tags": [
[
"e",
"cf62c1c9ba62fff4a5cf755628bee75840429fbdff26c4293acc0bc18dd74e69",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2020-11-30\n📝 Original message:\nOn Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko \u003cnaumenko.gs at gmail.com\u003e wrote:\n\n\u003e Hi Lloyd,\n\u003e\n\u003e \u003e I agree with Z that this proposal is missing a strong argument as to why\n\u003e this is a better “proof-of-stake” than channel balances themselves.\n\u003e\n\u003e I think Z’s consideration is about the alternative Stake Certificates\n\u003e proposed by t-bast, where every link in the route proves something to the\n\u003e next hop.\n\u003e For the context see this post, specifically “point-to-point property”:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002888.html\n\u003e\n\nThanks for the correction.\n\n\n\u003e\n\u003e I think you managed to apply the same argument to our original proposal as\n\u003e well :)\n\u003e\n\u003e \u003e In order to send a jamming HTLC you have to have to lock up funds to do\n\u003e it (they need outgoing balance for the sender and incoming balance for the\n\u003e receiver).\n\u003e\n\u003e I think the issue here is with loop attacks (\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)?\n\u003e This restriction with locking funds doesn’t really work…\n\u003e After getting past their intermediate hop, an attacker can make arbitrary\n\u003e loops and lock 100 BTC channels even by just having 1 BTC locked in the\n\u003e initial hop.\n\u003e\n\u003e Stake Certificates allow for a node in the middle of the route to\n\u003e distinguish where the payment is coming from (in a privacy-preserving\n\u003e manner of course), to distinguish heavy channel users from normal.\n\u003e They also allow to force an attacker to distribute jamming in time and\n\u003e across many channels.\n\u003e\n\nThat's a very interesting point. If we were to be able to prevent loop\nattacks by the sender proving the path is well formed (without revealing\nwho they are or any of the other hops) would this be an alternative\nsolution?\nIt seems to me that disabling loop attacks might be much easier than stake\ncertificates.\n\n\n\u003e Perhaps, alternative restrictions may take place by restricting based on\n\u003e from which immediate channel/node they are coming (one-hop). But that\n\u003e sounds like a mess, as a payment sender doesn’t have any control, and\n\u003e gossiping that would probably be a privacy leak, also it still allows free\n\u003e jamming I think (just a bit different).\n\u003e The big deal here is to distinguish the flows, to better control them.\n\u003e We can discuss this separately.\n\u003e\n\u003e It’s true that any token might achieve the same goal here, but how to make\n\u003e it Sybil-resistant and prevent generating new tokens? Stake Certificates, I\n\u003e don’t know what else we can commit to.\n\u003e\n\u003e \u003e If we are talking about non-economic adversaries who simply wish to\n\u003e destroy LN then that’s another game altogether.\n\u003e\n\u003e I was thinking about this scenario all the way, but maybe I should think\n\u003e about the other one as well.\n\u003e\n\u003e\nBut if we are talking about large holders of Bitcoin that just want to\ndestory LN this seems like a very weak mitigation since they will be able\nto produce stake certificates galore and lock up channels anyway.\nI don't see much of a way around this other than reputation systems.\n\nLL\n\n\n\n\u003e\n\u003e – gleb\n\u003e On Nov 30, 2020, 6:39 AM +0200, Lloyd Fournier \u003clloyd.fourn at gmail.com\u003e,\n\u003e wrote:\n\u003e\n\u003e Hi Gleb et al,\n\u003e\n\u003e I really appreciate the out-of-the-box thinking of this proposal.\n\u003e I will put to the side the very difficult task of creating a cryptosystem\n\u003e that efficiently achieves what's necessary for this to work because that\n\u003e seems not to be the main concern.\n\u003e\n\u003e I agree with Z that this proposal is missing a strong argument as to why\n\u003e this is a better \"proof-of-stake\" than channel balances themselves.\n\u003e In order to send a jamming HTLC you have to have to lock up funds to do it\n\u003e (they need outgoing balance for the sender and incoming balance for the\n\u003e receiver).\n\u003e Why would stake certificates be more powerful than this? I get that you\n\u003e decrement the UTXO's credit even if they fail. This increases the cost of\n\u003e sending spam (but it also increases the cost of sending normal payments\n\u003e since you now may be honest but have all your UTXOs run out of credit.)\n\u003e Does this increased cost (it was not zero before) actually prevent the\n\u003e attack without inhibiting normal usage?\n\u003e\n\u003e In general there seems to be an open question about whether these channel\n\u003e jamming attacks are actually economic.\n\u003e If I want to get more payments routed through me would it really be\n\u003e optimal to do channel jamming?\n\u003e Suppose that the nodes react to the jamming by adding extra capacity by\n\u003e splicing out from somewhere else. Then I have jammed up my own coins and\n\u003e got nothing for it.\n\u003e What if instead of attacking I allocated the coins instead to creating\n\u003e more valuable channels. Couldn't this be more profitable?\n\u003e I just posed this question in [1].\n\u003e\n\u003e If we are talking about non-economic adversaries who simply wish to\n\u003e destroy LN then that's another game altogether.\n\u003e For example if the CCP with its 1% of all Bitcoin it seized from the\n\u003e plustoken scam were to try and attack lightning they would likely succeed\n\u003e even if we had this system in place simply because they have a lot of\n\u003e \"stake\".\n\u003e As David points out I don't think you can make a distinction between real\n\u003e LN outputs and fake ones.\n\u003e It seems unavoidable that any coins you own could be used to produce a\n\u003e certificate to give you spam bandwidth (especially if you actually manage\n\u003e to guarantee privacy through ZKPs).\n\u003e\n\u003e [1] https://github.com/t-bast/lightning-docs/issues/7\n\u003e\n\u003e Cheers,\n\u003e\n\u003e LL\n\u003e\n\u003e\n\u003e On Sun, Nov 29, 2020 at 5:25 AM David A. Harding \u003cdave at dtrt.org\u003e wrote:\n\u003e\n\u003e\u003e On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Hello list,\n\u003e\u003e\n\u003e\u003e Gleb and Antoine,\n\u003e\u003e\n\u003e\u003e This is an interesting idea! Thank you for working on it.\n\u003e\u003e\n\u003e\u003e I had difficulty with one part of the proposal:\n\u003e\u003e\n\u003e\u003e \u003e #### Should we allow holding *any* Bitcoins (not just LN channels) for\n\u003e\u003e Stake Certificates?\n\u003e\u003e \u003e\n\u003e\u003e \u003e [...] we believe that allowing any UTXO would give an attacker more\n\u003e\u003e \u003e opportunities to use their cold funds for this attack, or even have a\n\u003e\u003e \u003e secondary market where holders sell their proofs (they have nothing to\n\u003e\u003e \u003e loose).\n\u003e\u003e\n\u003e\u003e Can't a malicious user get around this restriction by opening channels\n\u003e\u003e with themself? (Also, aren't current channel open outputs just P2WSH\n\u003e\u003e 2-of-2 multisigs, and in the future won't they be generic P2TR outputs?\n\u003e\u003e How would a stake certificate prove that the UTXO was generated for LN\n\u003e\u003e rather than just belonging to a user with a 2-of-2 multisig wallet or\n\u003e\u003e any key-path-spendable taproot wallet?)\n\u003e\u003e\n\u003e\u003e According to some random website, the current total channel balance of\n\u003e\u003e the public LN is about 1,000 BTC. Although I'm sure this will grow with\n\u003e\u003e time, it seems to me that an attacker who can rent access to stake\n\u003e\u003e certificates for a one-week attack at, say, a 5% annual interest rate\n\u003e\u003e would only need to pay 1 BTC to acquire stake certificates equal to all\n\u003e\u003e honest users at present. That cost doesn't seem high enough to me to\n\u003e\u003e effectively prevent attacks. Am I missing something?\n\u003e\u003e\n\u003e\u003e Thanks,\n\u003e\u003e\n\u003e\u003e -Dave\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201201/84676029/attachment-0001.html\u003e",
"sig": "4ef198cc249af3fb7c05ea022ad2697b6b9e3755793f75d6f1bd384f928f8a301e30fd3d4c5777e28a2e33b574833ce8e36d1e767c280ba75e1d78280d9c8ebf"
}