Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-05 📝 Original message: Hi ZmnSCPxj, Thanks for ...
📅 Original date posted:2020-06-05
📝 Original message:
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 <https://arxiv.org/abs/2005.09327>; 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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200605/213e7821/attachment-0001.html>;
📝 Original message:
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 <https://arxiv.org/abs/2005.09327>; 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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200605/213e7821/attachment-0001.html>;