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