Subhra Mazumdar [ARCHIVE] on Nostr: đź“… Original date posted:2020-05-30 đź“ť Original message: Hi ZmnSCPxj, Thanks for ...
đź“… Original date posted:2020-05-30
đź“ť Original message:
Hi ZmnSCPxj,
Thanks for the feedback. The 1000 block relative confirmation time was just
a representative value, as stated in [1]. We acknowledge that practical
implementations have much lesser confirmation times.
> Yes, to earn by reverse-griefing you can need to trigger the channel to
be closed, but even if you leave it open, there is a chance the
counterparty will close it for no reason it will bother to explain to you.
The possibility exists. Noted.
> Can you describe this in more detail?
Here is our proposal for mitigating reverse-griefing
https://gist.github.com/subhramazumdar/cf7b043a73db136f6a23091d20e51751
Looking forward to your comments.
[1] Poon, J. and Dryja, T., 2016. The bitcoin lightning network: Scalable
off-chain instant payments.
<https://lightning.network/lightning-network-paper.pdf>;
On Sat, May 30, 2020 at 11:35 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > - Myopic strategy: An adversary makes short-term gain by
> reverse-griefing but loses in the long term because of waiting time
> involved in earning the profit and also due to closure of channel.
> >
> > - Long-term strategy: If a strategy provides short term gain but
> incurs a substantial loss in the long term without fulfilling any of the
> objectives of griefing attack, the adversary would choose not to deviate
> from the protocol and behave honestly.
>
> What mechanism protects against the myopic strategy?
>
> There are many reasons why getting short-term gains *right now* via
> reverse-griefing is generally better:
>
> * Time discounting.
> Money you have now is better than money you will have in the future,
> because you can immediately reinvest the money right now.
> Thus, future earnings must be discounted by the expected average return
> on investment compared to current earnings.
> * Counterparty risk.
> Even if you maintain the channel open in the hope of future earnings,
> the counterparty can very well just close the channel at any time for no
> discernible reason.
> This reduces the expected return on investment by honest behavior.
> * Cheap pseudonyms.
> All you need is to get 256 bits of entropy and you can connect as a
> different node.
> VPNs and cloud servers can make it difficult to nail down specific IP
> addresses as belonging to you as attacker.
>
> My reading of the paper suggests that you simply assume that the honest
> strategy will earn more economically than reverse-griefing; can you provide
> expected return of investment on other possible investments (e.g. running a
> JoinMarket maker) to determine time discounting, and the rate at which
> channels get closed for no good reason to check counterparty risk?
>
> The fact that a reverse-griefing becomes possible means that, even after
> ignoring onchain fees, running a node can lead to a negative return on
> investment, whereas with current Lightning, if we ignore onchain fees, the
> minimum return on investment is 0 and you can "only" earn (again,
> emphasizing that this holds only if we ignore onchain fees; but in any
> case, with reverse-griefing possible, this can potentially give even worse
> negative return on investment if the node is attacked by reverse-griefing).
>
> Griefing can only prevent you from earning.
> Reverse-griefing can lose you funds.
>
>
> > > Rationality requires some goal to work toward. Often, the goal is
> "look out for number one" i.e. be selfish. Thus, an economically rational
> selfish entity is not a contradiction in terms: instead, it is simply
> applying its rationality towards its own self-interest.
> >
> > Using the term “rational and selfish” in the Discussion was a poor
> choice of words. Thanks for pointing it out. We define an honest-rational
> party as someone who follows the protocol unless a strictly more rewarding
> strategy exists. In our paper, an honest-rational party will follow the
> protocol as the profit earned by processing several transactions is greater
> than the profit earned by reverse-griefing.
> >
> > > So if an honestly-self-rational node could be tempted to setting up
> reverse-griefing attacks, it seems to me that grief-penalty cannot work
> well as a solution to griefing.
> >
> > Apart from earning less profit, there are several factors which justify
> why an honest rational party would prefer to follow the protocol rather
> than turn malicious and follow a myopic strategy (i.e resort to
> reverse-griefing):
> >
> > 1. A party who tries to reverse-grief has to wait for the expiration of
> the off-chain contract’s locktime before it can broadcast the transaction
> for earning a penalty.
>
> But an honest node that hopes to continuously earn money may need to wait
> even longer before somebody forwards through them, and is generally paid
> only a few dozen millisatoshi each time.
>
>
> > 2. Note that this output again is encumbered by the RSMC (1000 block
> relative confirmation times as stated in [1]) This means that it has to
> wait for 1000 blocks after broadcasting the penalty transaction before it
> can actually spend the output.
>
> I am unaware of any modern implementation that uses timelocks that large.
>
>
> >
> > 3. The fund locked in the contract, which acts as compensation in case
> of misbehavior, is a substantial amount. Definitely, an intermediate party
> won’t keep its funds unutilized and try to resolve payment as soon as
> possible.
>
> Like I pointed out elsewhere, griefing attacks are attacks committed by
> payer/payee conspiracies against forwarding nodes; we can disregard this
> point since it applies to non-griefing-penalty (i.e. current Lightning)
> just as well.
>
>
> > 4. It leads to channel closure. Any operation performed on-chain is a
> costly affair. A rational party will not prefer to close the channel.
>
> And like I pointed out, because any counterparty can close its channel
> with you at any time, this risk can be discounted by the expected average
> chance that a counterparty will close the channel for no reason.
> Yes, to earn by reverse-griefing you can need to trigger the channel to be
> closed, but even if you leave it open, there is a chance the counterparty
> will close it for no reason it will bother to explain to you.
>
> >
> >
> > Thus an honest-rational party can earn in either of the two ways:
> >
> > 1. A fee for processing payments.
> >
> > 2. If affected by griefing attack, it gets compensated for the
> collateral loss.
> >
> >
> > > Given we route using onion routing, it would be trivial to create a
> loop in the route so that the same node occurs twice in it, thus trivially
> meeting the "at least two nodes in the path must be corrupted" requirement.
> That is, the sender and the receiver can be the same node, making it appear
> twice in the path.
> >
> > Our assumption that at most one party is corrupted under adversarial
> model holds true for self-payment. Please refer to Corollary 1 of our
> Security Analysis section in the paper.
>
> Okay.
>
> >
> > > The solution should really prevent griefing without introducing any
> reverse-griefing.
> >
> > To avoid reverse-griefing, we may add an extra round (as preprocessing
> step) before initiating the lock phase. Additionally, the off-chain
> contract might contain two hashes: one for normal payment and one for
> error. Thanks to Rene Pickhardt for his suggestions.
>
>
> Can you describe this in more detail?
>
>
> Regards,
> ZmnSCPj
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200530/aa9aa0bd/attachment.html>;
đź“ť Original message:
Hi ZmnSCPxj,
Thanks for the feedback. The 1000 block relative confirmation time was just
a representative value, as stated in [1]. We acknowledge that practical
implementations have much lesser confirmation times.
> Yes, to earn by reverse-griefing you can need to trigger the channel to
be closed, but even if you leave it open, there is a chance the
counterparty will close it for no reason it will bother to explain to you.
The possibility exists. Noted.
> Can you describe this in more detail?
Here is our proposal for mitigating reverse-griefing
https://gist.github.com/subhramazumdar/cf7b043a73db136f6a23091d20e51751
Looking forward to your comments.
[1] Poon, J. and Dryja, T., 2016. The bitcoin lightning network: Scalable
off-chain instant payments.
<https://lightning.network/lightning-network-paper.pdf>;
On Sat, May 30, 2020 at 11:35 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > - Myopic strategy: An adversary makes short-term gain by
> reverse-griefing but loses in the long term because of waiting time
> involved in earning the profit and also due to closure of channel.
> >
> > - Long-term strategy: If a strategy provides short term gain but
> incurs a substantial loss in the long term without fulfilling any of the
> objectives of griefing attack, the adversary would choose not to deviate
> from the protocol and behave honestly.
>
> What mechanism protects against the myopic strategy?
>
> There are many reasons why getting short-term gains *right now* via
> reverse-griefing is generally better:
>
> * Time discounting.
> Money you have now is better than money you will have in the future,
> because you can immediately reinvest the money right now.
> Thus, future earnings must be discounted by the expected average return
> on investment compared to current earnings.
> * Counterparty risk.
> Even if you maintain the channel open in the hope of future earnings,
> the counterparty can very well just close the channel at any time for no
> discernible reason.
> This reduces the expected return on investment by honest behavior.
> * Cheap pseudonyms.
> All you need is to get 256 bits of entropy and you can connect as a
> different node.
> VPNs and cloud servers can make it difficult to nail down specific IP
> addresses as belonging to you as attacker.
>
> My reading of the paper suggests that you simply assume that the honest
> strategy will earn more economically than reverse-griefing; can you provide
> expected return of investment on other possible investments (e.g. running a
> JoinMarket maker) to determine time discounting, and the rate at which
> channels get closed for no good reason to check counterparty risk?
>
> The fact that a reverse-griefing becomes possible means that, even after
> ignoring onchain fees, running a node can lead to a negative return on
> investment, whereas with current Lightning, if we ignore onchain fees, the
> minimum return on investment is 0 and you can "only" earn (again,
> emphasizing that this holds only if we ignore onchain fees; but in any
> case, with reverse-griefing possible, this can potentially give even worse
> negative return on investment if the node is attacked by reverse-griefing).
>
> Griefing can only prevent you from earning.
> Reverse-griefing can lose you funds.
>
>
> > > Rationality requires some goal to work toward. Often, the goal is
> "look out for number one" i.e. be selfish. Thus, an economically rational
> selfish entity is not a contradiction in terms: instead, it is simply
> applying its rationality towards its own self-interest.
> >
> > Using the term “rational and selfish” in the Discussion was a poor
> choice of words. Thanks for pointing it out. We define an honest-rational
> party as someone who follows the protocol unless a strictly more rewarding
> strategy exists. In our paper, an honest-rational party will follow the
> protocol as the profit earned by processing several transactions is greater
> than the profit earned by reverse-griefing.
> >
> > > So if an honestly-self-rational node could be tempted to setting up
> reverse-griefing attacks, it seems to me that grief-penalty cannot work
> well as a solution to griefing.
> >
> > Apart from earning less profit, there are several factors which justify
> why an honest rational party would prefer to follow the protocol rather
> than turn malicious and follow a myopic strategy (i.e resort to
> reverse-griefing):
> >
> > 1. A party who tries to reverse-grief has to wait for the expiration of
> the off-chain contract’s locktime before it can broadcast the transaction
> for earning a penalty.
>
> But an honest node that hopes to continuously earn money may need to wait
> even longer before somebody forwards through them, and is generally paid
> only a few dozen millisatoshi each time.
>
>
> > 2. Note that this output again is encumbered by the RSMC (1000 block
> relative confirmation times as stated in [1]) This means that it has to
> wait for 1000 blocks after broadcasting the penalty transaction before it
> can actually spend the output.
>
> I am unaware of any modern implementation that uses timelocks that large.
>
>
> >
> > 3. The fund locked in the contract, which acts as compensation in case
> of misbehavior, is a substantial amount. Definitely, an intermediate party
> won’t keep its funds unutilized and try to resolve payment as soon as
> possible.
>
> Like I pointed out elsewhere, griefing attacks are attacks committed by
> payer/payee conspiracies against forwarding nodes; we can disregard this
> point since it applies to non-griefing-penalty (i.e. current Lightning)
> just as well.
>
>
> > 4. It leads to channel closure. Any operation performed on-chain is a
> costly affair. A rational party will not prefer to close the channel.
>
> And like I pointed out, because any counterparty can close its channel
> with you at any time, this risk can be discounted by the expected average
> chance that a counterparty will close the channel for no reason.
> Yes, to earn by reverse-griefing you can need to trigger the channel to be
> closed, but even if you leave it open, there is a chance the counterparty
> will close it for no reason it will bother to explain to you.
>
> >
> >
> > Thus an honest-rational party can earn in either of the two ways:
> >
> > 1. A fee for processing payments.
> >
> > 2. If affected by griefing attack, it gets compensated for the
> collateral loss.
> >
> >
> > > Given we route using onion routing, it would be trivial to create a
> loop in the route so that the same node occurs twice in it, thus trivially
> meeting the "at least two nodes in the path must be corrupted" requirement.
> That is, the sender and the receiver can be the same node, making it appear
> twice in the path.
> >
> > Our assumption that at most one party is corrupted under adversarial
> model holds true for self-payment. Please refer to Corollary 1 of our
> Security Analysis section in the paper.
>
> Okay.
>
> >
> > > The solution should really prevent griefing without introducing any
> reverse-griefing.
> >
> > To avoid reverse-griefing, we may add an extra round (as preprocessing
> step) before initiating the lock phase. Additionally, the off-chain
> contract might contain two hashes: one for normal payment and one for
> error. Thanks to Rene Pickhardt for his suggestions.
>
>
> Can you describe this in more detail?
>
>
> Regards,
> ZmnSCPj
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200530/aa9aa0bd/attachment.html>;