From subhra.mazumdar1993 at gmail.com Fri Jun 5 07:34:01 2020 From: subhra.mazumdar1993 at gmail.com (Subhra Mazumdar) Date: Fri, 5 Jun 2020 13:04:01 +0530 Subject: [Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack In-Reply-To: References: Message-ID: Hi ZmnSCPxj, Thanks for your invaluable feedback. The attack stated for the construction https://gist.github.com/subhramazumdar/cf7b043a73db136f6a23091d20e51751 holds true for the path S->A->B->C->R. A will end up paying the money without receiving anything from S. >Initial contract establishment has to be done from S to R always, not R to S. Multi-stage contracts can be done from R to S (arguably the simple resolution of HTLC chains is "really' the second stage) for after the initial establishment, but initial establishment always has to be from S to R. If the initial contract establishment starts from S, we can still face reverse-griefing - if an intermediate node, say C, refuses to sign the contract then again B can be reverse-griefed by A. It will deny canceling the contract with B and wait for the locktime to expire, thereby victimizing B. What might possibly work here is that the parties must first exchange signatures for the error hash in order to unlock collateral and avoid reverse-griefing and only after that, exchange signatures for payment hash. Again if S starts the locking phase by supplying the error hash in one round followed by exchanging signature for payment hash in the next round, it might supply a wrong error hash so that R is not able to supply proof of cancelation. Even if S has not tampered with the error hash value, an intermediate may refuse to forward the contract with terms of error hash. Again we are stuck with the same problem because R possesses the witness to the error hash. If the contract is not forwarded to R, the preimage will not be revealed. Given the terms of the contract is (quoting for R and C, for the rest of the channel it is the same except the change in the locktime, penalty, and payment locked by each party): R and C establish the contract for 7 msat, using 1 msat from C and 6 msat from R: * R shows x such that h = h(x) is true, with R getting 7 msat. * R shows r such that y = h(r) is true, with C getting 1 msat and R getting 6 msat. * After one day, C gets 7 msat. What we think might work for our case is that we let the exchange of signature for lock phase happen over two rounds - R initiating the first round involving error hash and S initiating the second round involving payment hash, as follows: Initially, let R exchange signatures with C over the following terms of the contract. ? * (Terms of Cancelation) R shows r such that y = h(r) is true, with C getting 1 msat and R getting 6 msat. * After one day, C gets 7 msat. C exchange signature with B and this continues till A has established the contract with S. This allows an honest intermediary in the release phase to unlock the money if R has triggered cancelation of the contracts. After S has signed the cancelation contract with A, the second round is initiated for forwarding the payment. S exchange signatures with A for the payment hash. This will avoid the problem mentioned in the previous construction whereby an intermediate party ends up paying its successor without being remunerated by a malicious payer. The rest of the intermediate parties does the same. Finally, C will exchange signature with R over the following terms: * (Terms of Payment) R shows x such that h = h(x) is true, with R getting 7 msat. R will wait for a constant amount of time in order to receive incoming contract request from C. After that, given the condition, it will either release the preimage of error hash or payment hash. If R griefs, it will lose funds in the form of penalty. Regarding the second attack: >Then, 1 Planck interval before the 1-day limit, R uses the second clause to cancel the entire payment. This is exactly the same result as with the current griefing attack: F is induced to lock its funds for 1 day minus 1 Planck interval, but is never compensated for it. It is immaterial whether the mechanism used is `update_fail_htlc` or some other mechanism. We had mentioned in the paper under Discussions (Section 6.3) that we do not handle attacks concerning soft-griefing, i.e., if a party withholds the preimage for a long time but releases just before the expiration of locktime. We think with the current set of instructions supported in Bitcoin, it is hard to settle soft-griefing related disputes, accounting penalty for each unit of elapsed time. In case of soft-griefing, we neither impose the griefing penalty, nor is there a chance to reverse-grief. On Mon, Jun 1, 2020 at 7:39 AM ZmnSCPxj wrote: > Good morning Subhra, > > > There may be other issues as well with the overall setup, please > wait, I am considering as well what would happen if we correctly establish > the contracts from S to R. > > Unfortunately the Mitigating Reverse-Griefing contract reintroduces > griefing. > > First, let us simplify the setup to S -> F -> R. > > In the griefing attack of today the setup would be: > > * S->F has the contract, funded by S only: > * If F can reveal x such that h = h(x) for a known h, F can claim the > fund. > * After 2 days, S can recover the fund. > * F->R has the contract, funded by F only: > * If R can reveal x such that h = h(x) for a known h, R can claim the > fund. > * After 1 day, F can recover the fund. > > Then, 1 Planck interval before the 1-day limit, R cancels the HTLC by > doing some form of `update_fail_htlc` to F. > This causes F to not earn any funds, even though it had its funds locked > for 1 day minus 1 Planck interval; thus in practice, R can lock the funds > of F for a little less than the time limit imposed. > > > > With the Mitigating Reverse Griefing technique, the setup would be: > > * S->F has the contract, funded by S and F: > * If F can reveal x such that h = h(x) for a known h, F can claim the > fund. > * If F can reveal r such that y = h(r) for a known y, S and F can > recover their original contributions to the fund. > * After 2 days, S can claim the fund. > * F->R has the contract, funded by F and R: > * If R can reveal x such that h = h(x) for a known h, R can claim the > fund. > * If R can reveal r such that y = h(r) for a known y, F and R can > recover their original contributions to the fund. > * After 1 day, F can claim the fund. > > Then, 1 Planck interval before the 1-day limit, R uses the second clause > to cancel the entire payment. > > This is exactly the same result as with the current griefing attack: F is > induced to lock its funds for 1 day minus 1 Planck interval, but is never > compensated for it. > It is immaterial whether the mechanism used is `update_fail_htlc` or some > other mechanism. > > > So not only does Mitigating Reverse-Griefing just replace reverse-griefing > with the attack described in my previous post, which I am now calling > backflip-reverse-griefing (because calling it "reverse-reverse-griefing" > would be ***SO BORING AND OBVIOUS***), it also returns the original > griefing attack. > > > I think it is a principle of protocol design that, in general, protecting > against one attack could open you up to the opposite of that attack. > > > It is helpful to remember that the original griefing attack is basically a > withholding attack, wherein a participant does not respond after a > particular step in the protocol. > By adding more steps, you simply add more places where a participant can > stop responding after some step in the protocol, and thus add even more > attack surface. > > > Regards, > ZmnSCPxj > > -- Yours sincerely, Subhra Mazumdar. -------------- next part -------------- An HTML attachment was scrubbed... URL: