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 your feedback. We would like to clarify certain points.
> Can you clarify what *goal* you are assuming the party has, which the
party is applying its rationality towards?
- The goal of griefing-penalty is to penalize any party who intends to
launch a griefing attack on the network. The strategy not only increases
the cost of attack but compensates other affected parties. It
disincentivizes an adversary from stalling the network and *enforces *good
behavior.
- Disincentivizing an adversary from carrying out griefing attack
definitely improves the credibility of Lightning Network. This will attract
more participants, willing to invest in the network, and filter out
malicious actors from the system by making the attack financially expensive.
Under the current specification of Lightning Network, griefing attack
doesn’t result in any financial loss for the adversary. The attack can
potentially lead to financial gain out of routing several transactions if a
competitor gets eliminated.
With the introduction of *griefing-penalty*, an adversary might follow
either of the two strategies to avoid paying penalty:
-
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.
> 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.
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.
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.
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.
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 <https://arxiv.org/abs/2005.09327>;.
> 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
<https://bitcoin.stackexchange.com/questions/96108/why-do-multihop-ln-payments-start-settling-from-the-recipients-end/96110#96110>;
.
[1] Poon, J. and Dryja, T., 2016. The bitcoin lightning network: Scalable
off-chain instant payments.
<https://lightning.network/lightning-network-paper.pdf>;
On Wed, May 20, 2020 at 10:23 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra et al,
>
> I am unsure whether you actually solve the Reverse-Griefing attack that
> the Griefing-Penalty enables.
> It seems to me that Reverse-Griefing is worse than Griefing, since it
> causes loss of funds already owned, whereas griefing only causes loss of
> opportunity to earn.
>
> In particular:
>
> > With the introduction of griefing-penalty, in order to avoid paying a
> compensation, at least two nodes in the path must be corrupted, as per the
> argument made above.
>
> 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.
>
> > Though we assume honest party will act rationally, in reality a party
> is selfish
>
> This does not make sense.
>
> 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.
>
> Can you clarify what *goal* you are assuming the party has, which the
> party is applying its rationality towards?
>
> --
>
> In general, all work towards such open standards as Lightning Network and
> so on have the motivating goal of "creating value": by fixing problems and
> improving specs, everyone gets a better Lightning Network and (hopefully)
> benefits.
> However this is not the ultimate goal towards we work toward.
> Instead, this is an instrumental goal, with the ultimate goal being to
> acquire more value; the act of creating value is then performed in the hope
> that the increase in global value will also translate to an increase in
> your own value.
>
> Thus, any forwarding node, by increasing liquidity on the Lightning
> Network, does so in the hope that it will capture some of the increased
> value:
>
> * Directly, by earning fees.
> * Indirectly, by promoting the use of Lightning and earning more future
> fees.
> * Even more indirectly, by promoting the use of Lightning on top of
> Bitcoin and increasing the value of any Bitcoin held in channels.
>
> Thus ultimately all honest behavior is ultimately
> honestly-rationally-selfish behavior.
>
> 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.
>
> The solution should really prevent griefing without introducing any
> reverse-griefing.
>
> Regards,
> ZmnSCPxj
>
>
> > Hi,
> >
> > We went through the discussion of Griefing Attack and after a thorough
> analysis, we realized that the attack cannot be prevented as the adversary
> doesn’t suffer any loss of funds.
> >
> > We propose an efficient countermeasure for the attack, known as
> Griefing-Penalty. Our proposed strategy works for any timelock based
> payment protocol. The penalty compensates for the loss incurred by the
> intermediaries, affected by griefing attack. You will find the paper
> Griefing-Penalty: Countermeasure for Griefing Attack in Bitcoin-compatible
> PCNs on arXiv. We look forward to hearing from the community on the
> feasibility of the approach and whether it can be implemented or not.
> >
> > Our Contribution to the paper:
> >
> > • We propose a countermeasure for mitigating griefing attack in
> Bitcoin-compatible PCNs, known as Griefing-Penalty. It punishes the griefer
> by forcing it to pay compensation to all the parties whose funds got locked
> for a certain time period as a result of the attack.
> >
> > • The loss of funds incurred upon mounting griefing-attack is
> proportional to the collateral cost of each channel involved in routing the
> payment.
> >
> > • To illustrate the benefit of the proposed countermeasure, we propose a
> new payment protocol, called as HTLC-GP or Hashed Timelock Contract with
> Griefing-Penalty.
> >
> > • We provide a security analysis which proves that our protocol is
> privacy-preserving as well as mitigates loss due to griefing attack by
> compensating the honest nodes
> >
> > We will briefly summarize the problem and our contribution through an
> example.
> >
> > The problem of Griefing Attack explained briefly
> >
> > Consider the situation where A wants to transfer 1 msat to C. It figures
> out a path connecting it to C, in the form A->B->C. A establishes an HTLC
> with B, locking 1 msat in the contract having expiration time of say 2
> days. B after receiving the incoming contract, forms a contract with C,
> locking 1 msat in the contract with locktime of 1 day.
> >
> > A------------------------->B---------------------->C
> >
> > HTLC(1msat, 2 day) HTLC(1msat, 1 day)
> >
> > Now if C griefs, funds of A and B remain locked as they cannot resolve
> HTLC. After an elapsed time of 1 day, the fund gets unlocked and B gets
> back 1 msat. Similarly, B cancels contract with A after 1 day, A unlocks 1
> msat. The problem with this construction is that C doesn’t lose anything.
> >
> > Griefing-Penalty: a strategy to penalize the adversary
> >
> > Hence we have come up with the following idea:
> >
> > 1) An off-chain contract established between 2 parties requires both the
> parties to lock funds – one party locking the amount that is to be
> forwarded and the other party locking the fund which can be claimed as a
> penalty, if this party griefs.
> >
> > 2) The penalty locked is proportional to the product of the amount being
> forwarded and the expiration time of the contract. All the parties affected
> by griefing must get compensation since their liquidity is tied up for a
> certain period of time.
> >
> > Considering the example used for demonstrating griefing attack. We
> modify the contract and term it as HTLC-GP (Hashed Timelock Contract with
> Griefing Penalty). We assume a rate of penalty, say 0.01 per hour, for
> calculating the penalty the party has to lock in order to accept an
> off-chain contract request.
> >
> > A forwards the term of the contract to B, requesting B to lock
> 0.01*1*48=0.48 msat as a penalty. A locks 1 msat in the contract, so the
> total amount locked in the contract is 1.48 msat. In the same way, B
> forwards the term of the contract to C, requesting C to lock 0.01*1*24=0.24
> msat as a penalty. B locks 1 msat in the contract, so the total amount
> locked in the contract is 1.24 msat. If the payment is not resolved within
> 1 day, all the parties who have forwarded the contract will claim the
> penalty locked in the contract.
> >
> >
> A-------------------------------------->B-------------------------------->C
> >
> > HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.24 msat,1 day)
> >
> > If C releases the preimage before the expiration of locktime, it will
> claim the full amount locked in the contract, i.e. 1.24 msat. Similarly, B
> claims 1.48 msat from the contract established with A.
> >
> > Suppose C griefs. After an elapse of 1 day, B claims 1.24 msat from the
> contract. C loses 0.24 msat. When B cancels contract with A, it will settle
> by paying 1.48 msat to A. But then B loses an additional 0.24 msat. This is
> not desired as B was not involved in mounting the attack. As per the
> objective, even B should earn a remuneration as it got affected by griefing.
> >
> > Hence, B should have asked C to lock funds in the contract which can be
> used for compensating both B and A. So C must lock 0.48 msat + 0.24 msat =
> 0.72 msat. So if C griefs, now it loses 0.72 msat (proportional to the
> collateral cost of the path). B pays 0.48 msat to A, keeping 0.24 msat with
> itself as compensation.
> >
> >
> A-------------------------------------->B-------------------------------->C
> >
> > HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.72 msat,1 day)
> >
> >
> A------------------------------------->B-------------------------------->C
> (griefs)
> >
> > (A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72
> msat)
> >
> > --
> > Yours sincerely,
> > Subhra Mazumdar.
>
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200530/13de0e9e/attachment-0001.html>;
đź“ť Original message:
Hi ZmnSCPxj,
Thanks for your feedback. We would like to clarify certain points.
> Can you clarify what *goal* you are assuming the party has, which the
party is applying its rationality towards?
- The goal of griefing-penalty is to penalize any party who intends to
launch a griefing attack on the network. The strategy not only increases
the cost of attack but compensates other affected parties. It
disincentivizes an adversary from stalling the network and *enforces *good
behavior.
- Disincentivizing an adversary from carrying out griefing attack
definitely improves the credibility of Lightning Network. This will attract
more participants, willing to invest in the network, and filter out
malicious actors from the system by making the attack financially expensive.
Under the current specification of Lightning Network, griefing attack
doesn’t result in any financial loss for the adversary. The attack can
potentially lead to financial gain out of routing several transactions if a
competitor gets eliminated.
With the introduction of *griefing-penalty*, an adversary might follow
either of the two strategies to avoid paying penalty:
-
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.
> 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.
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.
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.
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.
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 <https://arxiv.org/abs/2005.09327>;.
> 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
<https://bitcoin.stackexchange.com/questions/96108/why-do-multihop-ln-payments-start-settling-from-the-recipients-end/96110#96110>;
.
[1] Poon, J. and Dryja, T., 2016. The bitcoin lightning network: Scalable
off-chain instant payments.
<https://lightning.network/lightning-network-paper.pdf>;
On Wed, May 20, 2020 at 10:23 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra et al,
>
> I am unsure whether you actually solve the Reverse-Griefing attack that
> the Griefing-Penalty enables.
> It seems to me that Reverse-Griefing is worse than Griefing, since it
> causes loss of funds already owned, whereas griefing only causes loss of
> opportunity to earn.
>
> In particular:
>
> > With the introduction of griefing-penalty, in order to avoid paying a
> compensation, at least two nodes in the path must be corrupted, as per the
> argument made above.
>
> 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.
>
> > Though we assume honest party will act rationally, in reality a party
> is selfish
>
> This does not make sense.
>
> 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.
>
> Can you clarify what *goal* you are assuming the party has, which the
> party is applying its rationality towards?
>
> --
>
> In general, all work towards such open standards as Lightning Network and
> so on have the motivating goal of "creating value": by fixing problems and
> improving specs, everyone gets a better Lightning Network and (hopefully)
> benefits.
> However this is not the ultimate goal towards we work toward.
> Instead, this is an instrumental goal, with the ultimate goal being to
> acquire more value; the act of creating value is then performed in the hope
> that the increase in global value will also translate to an increase in
> your own value.
>
> Thus, any forwarding node, by increasing liquidity on the Lightning
> Network, does so in the hope that it will capture some of the increased
> value:
>
> * Directly, by earning fees.
> * Indirectly, by promoting the use of Lightning and earning more future
> fees.
> * Even more indirectly, by promoting the use of Lightning on top of
> Bitcoin and increasing the value of any Bitcoin held in channels.
>
> Thus ultimately all honest behavior is ultimately
> honestly-rationally-selfish behavior.
>
> 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.
>
> The solution should really prevent griefing without introducing any
> reverse-griefing.
>
> Regards,
> ZmnSCPxj
>
>
> > Hi,
> >
> > We went through the discussion of Griefing Attack and after a thorough
> analysis, we realized that the attack cannot be prevented as the adversary
> doesn’t suffer any loss of funds.
> >
> > We propose an efficient countermeasure for the attack, known as
> Griefing-Penalty. Our proposed strategy works for any timelock based
> payment protocol. The penalty compensates for the loss incurred by the
> intermediaries, affected by griefing attack. You will find the paper
> Griefing-Penalty: Countermeasure for Griefing Attack in Bitcoin-compatible
> PCNs on arXiv. We look forward to hearing from the community on the
> feasibility of the approach and whether it can be implemented or not.
> >
> > Our Contribution to the paper:
> >
> > • We propose a countermeasure for mitigating griefing attack in
> Bitcoin-compatible PCNs, known as Griefing-Penalty. It punishes the griefer
> by forcing it to pay compensation to all the parties whose funds got locked
> for a certain time period as a result of the attack.
> >
> > • The loss of funds incurred upon mounting griefing-attack is
> proportional to the collateral cost of each channel involved in routing the
> payment.
> >
> > • To illustrate the benefit of the proposed countermeasure, we propose a
> new payment protocol, called as HTLC-GP or Hashed Timelock Contract with
> Griefing-Penalty.
> >
> > • We provide a security analysis which proves that our protocol is
> privacy-preserving as well as mitigates loss due to griefing attack by
> compensating the honest nodes
> >
> > We will briefly summarize the problem and our contribution through an
> example.
> >
> > The problem of Griefing Attack explained briefly
> >
> > Consider the situation where A wants to transfer 1 msat to C. It figures
> out a path connecting it to C, in the form A->B->C. A establishes an HTLC
> with B, locking 1 msat in the contract having expiration time of say 2
> days. B after receiving the incoming contract, forms a contract with C,
> locking 1 msat in the contract with locktime of 1 day.
> >
> > A------------------------->B---------------------->C
> >
> > HTLC(1msat, 2 day) HTLC(1msat, 1 day)
> >
> > Now if C griefs, funds of A and B remain locked as they cannot resolve
> HTLC. After an elapsed time of 1 day, the fund gets unlocked and B gets
> back 1 msat. Similarly, B cancels contract with A after 1 day, A unlocks 1
> msat. The problem with this construction is that C doesn’t lose anything.
> >
> > Griefing-Penalty: a strategy to penalize the adversary
> >
> > Hence we have come up with the following idea:
> >
> > 1) An off-chain contract established between 2 parties requires both the
> parties to lock funds – one party locking the amount that is to be
> forwarded and the other party locking the fund which can be claimed as a
> penalty, if this party griefs.
> >
> > 2) The penalty locked is proportional to the product of the amount being
> forwarded and the expiration time of the contract. All the parties affected
> by griefing must get compensation since their liquidity is tied up for a
> certain period of time.
> >
> > Considering the example used for demonstrating griefing attack. We
> modify the contract and term it as HTLC-GP (Hashed Timelock Contract with
> Griefing Penalty). We assume a rate of penalty, say 0.01 per hour, for
> calculating the penalty the party has to lock in order to accept an
> off-chain contract request.
> >
> > A forwards the term of the contract to B, requesting B to lock
> 0.01*1*48=0.48 msat as a penalty. A locks 1 msat in the contract, so the
> total amount locked in the contract is 1.48 msat. In the same way, B
> forwards the term of the contract to C, requesting C to lock 0.01*1*24=0.24
> msat as a penalty. B locks 1 msat in the contract, so the total amount
> locked in the contract is 1.24 msat. If the payment is not resolved within
> 1 day, all the parties who have forwarded the contract will claim the
> penalty locked in the contract.
> >
> >
> A-------------------------------------->B-------------------------------->C
> >
> > HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.24 msat,1 day)
> >
> > If C releases the preimage before the expiration of locktime, it will
> claim the full amount locked in the contract, i.e. 1.24 msat. Similarly, B
> claims 1.48 msat from the contract established with A.
> >
> > Suppose C griefs. After an elapse of 1 day, B claims 1.24 msat from the
> contract. C loses 0.24 msat. When B cancels contract with A, it will settle
> by paying 1.48 msat to A. But then B loses an additional 0.24 msat. This is
> not desired as B was not involved in mounting the attack. As per the
> objective, even B should earn a remuneration as it got affected by griefing.
> >
> > Hence, B should have asked C to lock funds in the contract which can be
> used for compensating both B and A. So C must lock 0.48 msat + 0.24 msat =
> 0.72 msat. So if C griefs, now it loses 0.72 msat (proportional to the
> collateral cost of the path). B pays 0.48 msat to A, keeping 0.24 msat with
> itself as compensation.
> >
> >
> A-------------------------------------->B-------------------------------->C
> >
> > HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.72 msat,1 day)
> >
> >
> A------------------------------------->B-------------------------------->C
> (griefs)
> >
> > (A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72
> msat)
> >
> > --
> > Yours sincerely,
> > Subhra Mazumdar.
>
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200530/13de0e9e/attachment-0001.html>;