From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Nadav Ivgi <nadav@shesek•info>
Cc: Matan Yehieli <matany@campus•technion.ac.il>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Itay Tsabary <sitay@campus•technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
Date: Thu, 25 Jun 2020 04:04:09 +0000 [thread overview]
Message-ID: <XcV-a5p3nVenGEXgv4CO2X6lh4UXi18PM4-iKnfY3_SSoi5xCeCp84wsS1yHdHMVvDftNX5TrOnhUfvei371OQQHIVAJmcF-UQ_EAAZONyE=@protonmail.com> (raw)
In-Reply-To: <CAGXD5f0PXDMbVMiUNnqK-HGwB1yDEmBQgtLbQU4xcad3pDaGmw@mail.gmail.com>
Good morning Nadav,
> > I and some number of Lightning devs consider this to be sufficient disincentive to Bob not attacking in the first place.
>
> An additional disincentive could be introduced in the form of bribery proofs for failed attempts.
>
> If we assume that "honest" users of the LN protocol won't reveal their timelocked transactions before reaching the timelock expiry (they shouldn't anyway because standard full node implementations won't relay them), we can prove that Bob attempted bribery and failed to an outside observer by showing Bob's signed timelocked transaction, spending an output that was in reality spent by a different transaction prior to the locktime expiry, which should not be possible if Bob had waited.
Unfortunately this could be subject to an inversion of this attack.
Alice can wait for the timelock to expire, then bribe miners to prevent confirmation of the Bob timelocked transaction, getting the Alice hashlocked transaction confirmed.
Now of course you do mention "prior to the locktime expiry" but there is now risk at around locktime.
Particularly, "natural" orphaned blocks and short-term chainsplits can exist.
Bob might see that the locktime has arrived and broadcast the signed timelocked transaction, then Alice sees the locktime has not yet arrived (due to short-term chainsplits/propagation delays) and broadcast the signed hashlocked transaction, then in the end the Alice side of the short-term chainsplit is what solidifies into reality due to random chance on which miner wins which block.
Then Bob can now be accused of bribery, even though it acted innocently; it broadcasted the timelock branch due to a natural chainsplit but Alice hashlocked branch got confirmed.
Additional complications can be added on top to help mitigate this edge case but more complex == worse in general.
For example it could "prior to locktime expiry" can ignore a few blocks before the actual timelock, but this might allow Bob to mount the attack by initiating its bribery behavior earlier by those few blocks.
Finally, serious attackers would just use new pseudonyms, the important thing is to make pseudonyms valuable and costly to lose, so it is considered sufficient that LN nodes need to have some commitment to the LN in the form of actual channels (which are valuable, potentially money-earning constructs, and costly to set up).
Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris Belcher, could use similar disincentivizing; I know Chris is planning a fidelity bond system for SwapMarket makers, for example, which would mimic the properties of LN channels (costly to set up, money-earning).
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-06-25 4:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
2020-06-23 6:41 ` Stanga
2020-06-23 9:48 ` ZmnSCPxj
2020-06-23 12:47 ` Stanga
2020-06-23 13:18 ` Stanga
2020-06-25 1:38 ` ZmnSCPxj
2020-06-25 3:26 ` Nadav Ivgi
2020-06-25 4:04 ` ZmnSCPxj [this message]
2020-06-25 4:35 ` Nadav Ivgi
2020-06-25 13:12 ` Bastien TEINTURIER
2020-06-28 16:41 ` David A. Harding
2020-07-04 21:05 ` ZmnSCPxj
2020-06-28 12:15 ` David A. Harding
2020-06-29 11:57 ` Tejaswi Nadahalli
2020-06-29 18:05 ` ZmnSCPxj
2020-06-30 6:28 ` Stanga
2020-06-30 6:45 ` Tejaswi Nadahalli
2020-07-01 16:58 ` ZmnSCPxj
2020-07-02 12:22 ` Tejaswi Nadahalli
2020-07-02 16:06 ` ZmnSCPxj
2020-07-03 9:43 ` Tejaswi Nadahalli
2020-07-03 10:16 ` ZmnSCPxj
2020-07-03 10:44 ` Tejaswi Nadahalli
[not found] ` <CAF-fr9Z7Xo8JmwtuQ7LE3k1=er+p7s9zPjH_8MNPwbxAfT1z7Q@mail.gmail.com>
2020-07-03 12:38 ` ZmnSCPxj
[not found] ` <CAF-fr9YhiOFD4n8rGF-MBkWeZmzBWfOJz+p8ggfLuDpioVRvyQ@mail.gmail.com>
2020-07-04 20:58 ` ZmnSCPxj
2020-07-05 9:03 ` Stanga
2020-07-06 11:13 ` Tejaswi Nadahalli
2020-07-02 12:39 ` Tejaswi Nadahalli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='XcV-a5p3nVenGEXgv4CO2X6lh4UXi18PM4-iKnfY3_SSoi5xCeCp84wsS1yHdHMVvDftNX5TrOnhUfvei371OQQHIVAJmcF-UQ_EAAZONyE=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=matany@campus$(echo .)technion.ac.il \
--cc=nadav@shesek$(echo .)info \
--cc=sitay@campus$(echo .)technion.ac.il \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox