Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible race condition(double spend) on HTLC-Timeout transactions? #686

Closed
yyforyongyu opened this issue Oct 24, 2019 · 2 comments

Comments

@yyforyongyu
Copy link

@yyforyongyu yyforyongyu commented Oct 24, 2019

From the offered HTLC Outputs,

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

With the following conditions,

  • a locktime is set to be 600900 in the HTLC-Timeout transaction.
  • the remote node has the payment_secret.
  • the local node wants to timeout the latest commitment transaction.

From my understanding, to timeout the latest commitment transaction, the local node has to,

  1. broadcast the commitment transaction at blockheight 600900;
  2. immediately broadcast the HTLC-Timeout transaction;
  3. wait a few days to spend the HTLC-Timeout transaction once the specified timelock value has passed.

Meanwhile, the remote node with the payment_secret can spend the commitment transaction too. Will this cause a race condition/double spend in the Bitcoin network? If so, how can it be resolve?

@fiatjaf

This comment has been minimized.

Copy link

@fiatjaf fiatjaf commented Oct 24, 2019

My guess: If the remote node really has the payment_secret and for some odd reason decided to only use it after local node have broadcasted the commitment transaction, that's still fine. Local node will see the payment_secret and use it to fulfill the HTLC on his other channel.

@Roasbeef

This comment has been minimized.

Copy link
Member

@Roasbeef Roasbeef commented Nov 22, 2019

broadcast the commitment transaction at blockheight 600900;

No, they can broadcast before then (the node that has the outgoing HTLC). Only after that height can they timeout the HTLC on chain.

Meanwhile, the remote node with the payment_secret can spend the commitment transaction too.

Only one spend can go into the chain. If the party with the incoming HTLC goes on-chain to pull it, and gets that confirmed before the timeout transaction, then the node that offered the HTLC can use that to settle their incoming HTLC. The node straddling both HTLCs needs to mind the CLTV delta between the two HTLCs. This is where the actual race can arise: if the incoming HTLC expires before the outgoing HTLC has been timedout on chain, then a partial settlement can occur.

@Roasbeef Roasbeef closed this Nov 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.