docs(t6): standalone T6 model explainer
Self-contained explainer of the T6 model: what it is (a BTC channel whose state record lives on the BCH chain instead of an LN node), how it works (clerk/bailiff — BCH records, BTC settles), the step-by-step mechanics (open / transact / cooperative close / unilateral exit + revocation penalty), how it differs from LN (state-record location → no node, no lost-state, permissionless watchtower, two light wallets), the trust model (penalty as a "BTC tax"; denial > penalty on BCH-native), LN interop (HTLC-capable T6 = LN channel with a BCH watchtower; submarine swap to fund), what's validated on real coins, and why it matters. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
walerikus
parent
c4abcbf9b7
commit
48cc3ea808
1 changed files with 196 additions and 0 deletions
196
Parameters/T6_BitcoinCash_LN/T6_model_explained.md
Normal file
196
Parameters/T6_BitcoinCash_LN/T6_model_explained.md
Normal file
|
|
@ -0,0 +1,196 @@
|
|||
# The T6 Model — Bitcoin Cash as a better Lightning
|
||||
|
||||
*A standalone explainer: what T6 is, how it works, how it differs from Lightning, whether
|
||||
it interoperates, and the key mechanics. Validated end-to-end on real coins (BCH chipnet +
|
||||
BTC signet).*
|
||||
|
||||
---
|
||||
|
||||
## 1. What T6 is, in one sentence
|
||||
|
||||
**T6 is a Bitcoin payment channel whose state record lives on the Bitcoin Cash blockchain
|
||||
instead of inside a private Lightning node.** The bitcoin stays locked in a normal 2-of-2 on
|
||||
BTC and settles on BTC — but the channel's running balance is kept as a **public, permanent,
|
||||
on-chain record on BCH**, so no one has to run a node, store private state, or stay online to
|
||||
police the channel. It is *the Lightning model, with its weakest layer (the node) replaced by
|
||||
a chain.*
|
||||
|
||||
It is built **for Lightning users** — to demonstrate, in their own model (lock BTC, channel),
|
||||
that a better one exists.
|
||||
|
||||
---
|
||||
|
||||
## 2. The problem it solves
|
||||
|
||||
Self-custodial Lightning makes the user carry a surprising amount:
|
||||
|
||||
- **Run a node.** Not just a wallet — a persistent, stateful daemon that manages channels.
|
||||
- **Keep private state.** Your latest commitment transaction and every revocation secret. If
|
||||
you **lose them, you can lose your funds** (the "lost-state" footgun).
|
||||
- **Stay online to defend.** If your counterparty broadcasts an old state while you're away,
|
||||
you must catch and counter it within a timelock — or delegate to a (semi-trusted) watchtower.
|
||||
|
||||
These are the costs that, in practice, push most users onto **custodial** Lightning wallets.
|
||||
T6 removes all three by moving the channel's *record* and *watchtower* onto Bitcoin Cash.
|
||||
|
||||
---
|
||||
|
||||
## 3. How it works — the architecture
|
||||
|
||||
T6 has two halves, on two chains, with a strict division of labour:
|
||||
|
||||
- **BTC — the bailiff (holds and moves the money).** The funds sit in a standard **2-of-2
|
||||
funding output** on BTC. All settlement (cooperative close, unilateral close, penalty) is a
|
||||
**BTC transaction**, because *only BTC script can move BTC.*
|
||||
- **BCH — the clerk (records and proves the state).** The channel's current balance lives in a
|
||||
small **covenant-controlled NFT (the "board")** on BCH. Every update is a **both-signed,
|
||||
on-chain, strictly-monotonic** record. Anyone can read it; no one can lose it; a stale state
|
||||
can never overwrite a newer one.
|
||||
|
||||
> **Clerk vs bailiff.** BCH *knows* the truth (instantly, publicly, permanently); BTC
|
||||
> *enforces* it (it holds the coins). The two never merge — BTC can't read BCH — which is the
|
||||
> single fact that shapes the whole design.
|
||||
|
||||
The off-chain part is the same as Lightning: between updates, the parties exchange
|
||||
**signed-but-unbroadcast BTC commitment transactions** (signing is a local act, not an
|
||||
on-chain event). The difference is purely **where the agreed state is recorded** — on the
|
||||
public BCH board, instead of privately inside two nodes.
|
||||
|
||||
---
|
||||
|
||||
## 4. The mechanics, step by step
|
||||
|
||||
1. **Open.** Alice and Bob fund a 2-of-2 on BTC (an on-chain BTC tx — unavoidable, true of any
|
||||
channel). The opening balance is written to the BCH board as **state 0**.
|
||||
2. **Transact.** Each payment is a new balance, **co-signed by both** and recorded on the board
|
||||
as the next monotonic state (1, 2, 3 …). The full BCH transaction history is the channel's
|
||||
**audit trail**; the latest NFT commitment is the **current truth**. (Recording on BCH costs
|
||||
a fraction of a cent per update — and can be batched/lazy-anchored to ~nothing.)
|
||||
3. **Cooperative close.** Both sign one BTC tx paying out the latest agreed split. Done.
|
||||
4. **Unilateral exit + penalty (trustless, no cooperation needed).** A party can force-settle
|
||||
by broadcasting their latest BTC commitment. Its self-output is a **revocation script**:
|
||||
```
|
||||
OP_IF <revocationPub> OP_CHECKSIG
|
||||
OP_ELSE <CSV> OP_CHECKSEQUENCEVERIFY OP_DROP <closerPub> OP_CHECKSIG
|
||||
OP_ENDIF
|
||||
```
|
||||
- **Honest close:** after a CSV delay, the closer takes their own output (ELSE).
|
||||
- **Cheating (broadcasting a *stale* state):** when the state advanced, the closer handed
|
||||
over that state's **revocation key**. So if they later broadcast the old state, the
|
||||
counterparty sweeps the closer's output **immediately** (IF branch) — the **penalty**.
|
||||
Cheating therefore costs the cheater their **whole balance**.
|
||||
|
||||
The **BCH board** is what makes the penalty practical: it tells the victim (or any
|
||||
permissionless watchtower) *the true latest state*, so a stale BTC broadcast is detected
|
||||
instantly. BCH detects; **BTC enforces** the penalty (it holds the funds).
|
||||
|
||||
---
|
||||
|
||||
## 5. How T6 differs from Lightning
|
||||
|
||||
Structurally, **a T6 channel and an LN channel are the same object** — a BTC 2-of-2 with
|
||||
signed commitment transactions, settling on BTC. The *only* difference is **where the state
|
||||
record lives**, and that one difference cascades into every practical advantage:
|
||||
|
||||
| | **Lightning** | **T6** |
|
||||
|---|---|---|
|
||||
| State record | **private**, inside your node | **public**, on the BCH board |
|
||||
| Lose your device's state? | can lose funds | **nothing lost** — the chain remembers |
|
||||
| Watchtower | your node, or a semi-trusted service | **permissionless** — anyone reads BCH |
|
||||
| Must be online to *defend*? | yes | **no** (the board is always online) |
|
||||
| What the user runs | light BTC wallet **+ a persistent LN node** | **light BTC wallet + light BCH wallet** |
|
||||
| Self-custodial with just a wallet? | no (needs the node) | **yes** |
|
||||
|
||||
So the headline difference: **LN makes you run (or trust) a node; T6 makes you run two light,
|
||||
self-custodial wallets** — because the node's two heavy jobs (keeping the state, being the
|
||||
watchtower) are done by the Bitcoin Cash chain, on-chain, for everyone, permissionlessly.
|
||||
(One secp256k1 keypair works on both chains — the same key signs the BTC commitment and the
|
||||
BCH board update.)
|
||||
|
||||
What T6 does **not** change — these are inherent to a *BTC channel*, not fixable from BCH:
|
||||
**bilateral** (third parties need their own channels + routing), **open/close are on-chain BTC**
|
||||
(the base-layer cost), and **sign-to-receive** (you must be online to *receive*, because
|
||||
receiving means co-signing the new state).
|
||||
|
||||
---
|
||||
|
||||
## 6. Trust model — and why the penalty is a "BTC tax"
|
||||
|
||||
T6's settlement is **trustless**: BTC script enforces it; no bonded signers, no custodian.
|
||||
The penalty makes unilateral exit trustless by **deterrence** — cheating is *possible* but
|
||||
self-defeating, so a rational party never does it.
|
||||
|
||||
But notice *why* a penalty is needed at all: **BTC can't deny a stale transaction.** A stale
|
||||
commitment is a perfectly valid BTC tx (valid signatures, spends the unspent 2-of-2), and BTC
|
||||
**cannot tell it's old** — it can't read the BCH board, and has no covenant to require "only
|
||||
the latest state may settle." So BTC's only option is to **let it through and punish it**
|
||||
(penalty), which in turn needs a watcher to make the punishment credible.
|
||||
|
||||
On a **BCH-native** channel the cleaner mechanism is available: a covenant **reads the latest
|
||||
on-chain state and simply *denies* the stale settlement** — it never confirms, no penalty, no
|
||||
watcher, no timelock race. So the penalty (and its watchtower requirement) is a **BTC
|
||||
limitation**: T6 carries it *only because it keeps the funds on BTC* for users who want to stay
|
||||
in BTC. It is the last piece of the "BTC tax," and it disappears the moment value settles on BCH.
|
||||
|
||||
---
|
||||
|
||||
## 7. Is it interoperable with Lightning?
|
||||
|
||||
Yes — because a T6 channel *is* a BTC channel.
|
||||
|
||||
- **Opening** any channel (LN or T6) is an on-chain BTC event (the funding tx).
|
||||
- **Sending into an already-open channel is off-chain.** If a T6 channel **implements LN's
|
||||
HTLC + routing protocol**, it simply *is* an LN channel that happens to use BCH as its
|
||||
watchtower — and **LN payments route into it off-chain**, with no on-chain step per payment.
|
||||
- A wallet supporting **BTC + LN + BCH**, holding an LN channel on one side and an
|
||||
**HTLC-capable T6 channel** on the other, can **route a payment LN → T6** (it forwards the
|
||||
HTLC; the board records the result). The structural requirement is just the **open,
|
||||
HTLC-capable channel** (plus the usual LN receive conditions: inbound liquidity + online).
|
||||
- **Funding a T6 channel from existing LN funds** (when no compatible channel/route exists)
|
||||
crosses via **on-chain BTC** — a **submarine swap** (preferred — keeps your LN channel open)
|
||||
or a channel **close**. Only BTC can move BTC; BCH can *snapshot, record, and coordinate* LN
|
||||
state (a better, permissionless watchtower for LN itself) but cannot move the BTC funds.
|
||||
|
||||
**User experience:** a T6-aware wallet presents plain *send / receive*, runs a **submarine
|
||||
swap** underneath (no channel close), and uses the **BCH board** as the watchtower for the
|
||||
resulting channel — the HTLC/routing/funding complexity hidden behind one tap.
|
||||
|
||||
---
|
||||
|
||||
## 8. What's been validated (real coins)
|
||||
|
||||
| Layer | Chain | Result |
|
||||
|---|---|---|
|
||||
| Channel-state **board** (both-signed, monotonic, permissionless, unloseable) | BCH chipnet | ✅ stale update rejected; latest state readable by anyone |
|
||||
| **2-of-2 funding** lock | BTC signet | ✅ `764238…` |
|
||||
| **Cooperative close** | BTC signet | ✅ `af4db7…` (split paid) |
|
||||
| **Unilateral-exit penalty** (stale broadcast → cheater's balance seized) | BTC signet | ✅ `b35186…` |
|
||||
| **Scale** (many addresses / concurrent channels) | BCH chipnet | ✅ 3 channels, 6 sign-only parties, 1 permissionless watchtower |
|
||||
|
||||
Code: `contracts/BchChannelBoard.cash`, `scripts/chipnet-channel-board-test.mjs`,
|
||||
`scripts/chipnet-channel-board-multi.mjs`, `scripts/btc-signet-channel.mjs`,
|
||||
`scripts/btc-signet-penalty.mjs`. Only the *honest* CSV-delayed self-close (the liveness
|
||||
mirror of the penalty) is unrun — non-security-critical.
|
||||
|
||||
---
|
||||
|
||||
## 9. Why it matters
|
||||
|
||||
T6 is the **"better Lightning, for Lightning users"**: same model they already accept (lock
|
||||
BTC, channel, stay in BTC), but with Lightning's heaviest costs — running a node, guarding
|
||||
private state, staying online to watch — **lifted onto the Bitcoin Cash chain**, which does
|
||||
them publicly, permanently, and permissionlessly. It's a *demonstration*, not an argument: it
|
||||
hands an LN user the same thing they already use, working better, on real Bitcoin and real
|
||||
Bitcoin Cash.
|
||||
|
||||
And it quietly makes a larger point. T6 keeps a penalty and a watchtower *only because the
|
||||
funds stay on BTC*, which can't see the fresh state. Move the value onto BCH itself (a native
|
||||
channel, or simply transacting on-chain) and the penalty, the watchtower, the sign-to-receive,
|
||||
the routing — the entire residual friction — **dissolve.** T6 shows BCH makes a *better* LN;
|
||||
the on-chain models show BCH doesn't *need* one. Both are true, and T6 is the door an LN user
|
||||
can actually walk through.
|
||||
|
||||
---
|
||||
|
||||
*Companion to `T6_BTC-BCH_complete-record.md` (the full BTC↔BCH investigation: all models,
|
||||
all tests, the conceptual spine). This file is the focused T6 explainer.*
|
||||
Loading…
Add table
Reference in a new issue