Complete script implementation

Each channel pair locks funds in a 2-of-2 multisig.

Redeem script

OP_2 <pubkey_A> <pubkey_B> OP_2 OP_CHECKMULTISIG

scriptSig (cooperative spend)

OP_0 <sig_A> <sig_B> <redeem_script>

A channel's state is a single commitment transaction, signed by both parties but not broadcast. It fully describes the current balances and all active PREPAREs. Every change — new payment, COMMIT, CANCEL — produces a new commitment transaction with a higher sequence number.

No active payments

State N:
  Input:  funding output (2-of-2 multisig)
  Output 0: Alice balance
  Output 1: Bob balance

One active payment

State N+1:
  Input:  funding output (2-of-2 multisig)
  Output 0: Alice balance (minus deposit)
  Output 1: Bob balance (minus deposit)
  Output 2: PREPARE_1 (payment_hash_1, 2N locked)

Two active payments

State N+2:
  Input:  funding output (2-of-2 multisig)
  Output 0: Alice balance (minus both deposits)
  Output 1: Bob balance (minus both deposits)
  Output 2: PREPARE_1 (payment_hash_1, 2N locked)
  Output 3: PREPARE_2 (payment_hash_2, 2N locked)

First payment resolved, second still active

State N+3:
  Input:  funding output (2-of-2 multisig)
  Output 0: Alice balance (updated)
  Output 1: Bob balance (updated)
  Output 2: PREPARE_2 (payment_hash_2, 2N locked)

Multiple payments can be active simultaneously. Each state change is atomic — one at a time, new sequence number, both parties sign.

Both parties agree on final balances and sign a single transaction spending the funding output. No delays, no challenge period.

Transaction

Input:  funding output (2-of-2 multisig)
scriptSig: OP_0 <sig_A> <sig_B> <redeem_script>

Output 0: <balance_A> to <pubkey_A>
Output 1: <balance_B> to <pubkey_B>

Any active PREPAREs are resolved off-chain before closing.

One party broadcasts their latest commitment transaction without cooperation. The broadcaster's balance output is delayed to give the counterparty a challenge period.

Broadcaster's output redeem script

OP_IF
    <counterparty_pubkey> OP_CHECKSIG
OP_ELSE
    <144> OP_CHECKSEQUENCEVERIFY OP_DROP
    <broadcaster_pubkey> OP_CHECKSIG
OP_ENDIF

Counterparty overrides (broadcaster used old state)

<counterparty_sig> OP_TRUE <redeem_script>

Broadcaster claims (after 144 blocks ≈ 24h)

<broadcaster_sig> OP_FALSE <redeem_script>

The counterparty's balance output pays immediately — standard P2PKH. Any active PREPARE outputs are included and resolved on-chain using the scripts in sections 6–8.

There is no separate dispute mechanism. It is the state sequence.

A PREPARE is created in state N+1. COMMIT is not a signed state — it is simply someone using the preimage spend path in state N+1. CANCEL is state N+2, signed by both parties with a higher sequence number.

If someone broadcasts state N+1 and tries to use the preimage path, the counterparty broadcasts state N+2 (CANCEL) during the challenge period. Higher sequence number wins. Funds restored.

This is the same mechanism used for all channel disputes (section 4) and the same mechanism Lightning uses for revocation.

Alice deposits N, Bob deposits N. Total 2N in the output. Bob can CANCEL. Preimage triggers COMMIT.

Redeem script

OP_IF
    OP_SHA256 <payment_hash> OP_EQUALVERIFY
    OP_2 <pubkey_A> <pubkey_B> OP_2 OP_CHECKMULTISIG
OP_ELSE
    <pubkey_B> OP_CHECKSIG
OP_ENDIF

COMMIT (requires preimage + both signatures)

OP_0 <sig_A> <sig_B> <preimage> OP_TRUE <redeem_script>

Outputs: Bob 2N (Alice's payment + Bob's deposit returned)

CANCEL (Bob signs alone)

<sig_B> OP_FALSE <redeem_script>

Outputs: Alice N, Bob N (everything restored)

Bob deposits N, Carol deposits 3N. Total 4N in the output. Carol can CANCEL. Preimage triggers COMMIT.

Redeem script

OP_IF
    OP_SHA256 <payment_hash> OP_EQUALVERIFY
    OP_2 <pubkey_B> <pubkey_C> OP_2 OP_CHECKMULTISIG
OP_ELSE
    <pubkey_C> OP_CHECKSIG
OP_ENDIF

COMMIT (requires preimage + both signatures)

OP_0 <sig_B> <sig_C> <preimage> OP_TRUE <redeem_script>

Outputs: Carol 4N (3N deposit returned + N payment received)

CANCEL (Carol signs alone)

<sig_C> OP_FALSE <redeem_script>

Outputs: Bob N, Carol 3N (everything restored)

Carol deposits N, Dave deposits 0. Standard HTLC with timeout. No CANCEL signature — timeout only.

Redeem script

OP_IF
    OP_SHA256 <payment_hash> OP_EQUALVERIFY
    <pubkey_D> OP_CHECKSIG
OP_ELSE
    <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <pubkey_C> OP_CHECKSIG
OP_ENDIF

COMMIT (Dave has preimage)

<sig_D> <preimage> OP_TRUE <redeem_script>

Outputs: Dave N

CANCEL (timeout expired)

<sig_C> OP_FALSE <redeem_script>

Outputs: Carol N (deposit returned)

1. Dave generates preimage, sends payment_hash to Alice.
2. PREPARE phase (forward, all off-chain): Alice & Bob lock hop 1 (2N); Bob & Carol lock hop 2 (4N); Carol & Dave lock hop 3 (N).
3. COMMIT phase (backward, all off-chain): Dave reveals; Carol resolves hop 2; Bob resolves hop 1. Payment complete. No transactions broadcast.
4. CANCEL (if something goes wrong, off-chain): hop 3 times out; Carol signs CANCEL on hop 2; Bob signs CANCEL on hop 1.
5. On-chain only if a counterparty is unresponsive: broadcast the latest commitment. Active PREPAREs resolve via the COMMIT or CANCEL scripts above.

When both sender and receiver bank with the same institution, the payment is a simplified two-hop case. No staggered deposits needed — the bank is the only intermediary.

Alice → Bank → Dave

Hop 1 (Alice → Bank): Same as section 6. Alice deposits N, Bank deposits N. Total 2N. Bank can CANCEL. Preimage triggers COMMIT.

Hop 2 (Bank → Dave): Same as section 8. Bank deposits N, Dave deposits 0. Standard HTLC with timeout.

Deposits are 1:1 — the bank matches Alice's N with N. The 3:1 ratio (section 7) only applies to cross-bank routing where an intermediary must cover cumulative risk across a longer chain.

No new scripts required. Intra-bank payments use sections 6 and 8 directly.

Same scripts as above. Three routers (A, B, C) run the exact same protocol to net bilateral debts: A → B → C (novation of debt).

Identical PREPARE / COMMIT / CANCEL scripts. Amounts reflect debts instead of payments. Discovery of novation loops is handled at the application layer, separate from on-chain scripts.

Five script types in the entire protocol.

All scripts use opcodes available since 2016 (BIP 65/112). No SegWit, Taproot, or soft fork required.