# Full Mesh Payment Protocol — Complete Bitcoin Script

Complete script implementation for 3-hop payments: Alice → Bob → Carol → Dave.
Payment amount: N satoshis. Hash: SHA256(preimage).

---

## 1. Channel Funding

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>
```

---

## 2. Channel State

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.

**Example — no active payments:**
```
State N:
  Input:  funding output (2-of-2 multisig)
  Output 0: Alice balance
  Output 1: Bob balance
```

**Example — 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)
```

**Example — 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)
```

**Example — 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.

---

## 3. Channel Close — Cooperative

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.

---

## 4. Channel Close — Unilateral

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.

---

## 5. Dispute — How CANCEL Beats COMMIT

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.

---

## 6. PREPARE — Hop 1 (Alice → Bob)

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)

---

## 7. PREPARE — Hop 2 (Bob → Carol)

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)

---

## 8. PREPARE — Hop 3 (Carol → Dave)

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)

---

## 9. Payment Flow

```
1. Dave generates preimage, sends payment_hash to Alice

2. PREPARE phase (forward, all off-chain):
   Alice & Bob   →  new state: PREPARE hop 1 (2N locked)
   Bob & Carol   →  new state: PREPARE hop 2 (4N locked)
   Carol & Dave  →  new state: PREPARE hop 3 (N locked)

3. COMMIT phase (backward, all off-chain):
   Dave reveals preimage  →  hop 3 resolved, new state
   Carol sees preimage    →  hop 2 resolved, new state
   Bob sees preimage      →  hop 1 resolved, new state

   All parties update channel states off-chain.
   Payment complete. No transactions broadcast.

4. CANCEL (if something goes wrong, off-chain):
   Hop 3: timeout expires    →  Carol reclaims, new state
   Hop 2: Carol signs CANCEL →  new state, balances restored
   Hop 1: Bob signs CANCEL   →  new state, balances restored

5. On-chain resolution (only if counterparty unresponsive):
   Broadcast latest commitment transaction.
   Active PREPAREs appear as outputs, resolved on-chain
   via COMMIT or CANCEL scripts (sections 6–8).
```

---

## 10. Intra-Bank Payment (Alice → Bank → Dave)

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.

---

## 11. Credit Clearing (Novation)

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.

---

## Summary

Five script types in the entire protocol:

| # | Type                    | Script                                | Opcodes |
|---|-------------------------|---------------------------------------|---------|
| 1 | Channel funding         | 2-of-2 multisig                       | ~5      |
| 2 | Unilateral close output | checksig / CSV + checksig             | ~7      |
| 3 | PREPARE hop 1 & 2       | SHA256 + multisig / checksig          | ~8      |
| 4 | PREPARE hop 3           | SHA256 + checksig / CLTV + checksig   | ~8      |
| 5 | Cooperative close       | (no script — just spends funding)     | 0       |

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