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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
