Hi ZmnSCPxj, You are of course correct. I had considered the effect of reorgs, but the email seemed to be getting too lengthy to mention that too.
You would need a few spare blocks in which Bob won't be accused of bribery as a safety margin, which does reduce the time frame in which Alice can get her transaction confirmed in order to have a valid bribery fraud. This seems workable if the time frame was long enough (over a few hours should be sufficient, assuming we consider reorgs of over 3-4 blocks to be unlikely), but could indeed be problematic if the time frame is already short to begin with. Nadav On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > 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 >
_______________________________________________ bitcoin-dev mailing list email@example.com https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev