Exchange assets across different blockchains — Bitcoin ↔ Ethereum — without any trusted third party. From the classic HTLC design (Nolan 2013, Herlihy 2018) to modern PTLC-based adaptor-signature swaps. Covers griefing attacks, griefing defenses, and the submarine swap special case.
Alice has 1 BTC and wants 15 ETH. Bob has 15 ETH and wants 1 BTC. They don't trust each other. How do they swap without a trusted third party?
The "atomic" guarantee: both transfers happen, or neither does — no partial execution, no need for escrow.
2013 — Tier Nolan proposes HTLC-based cross-chain swaps on Bitcoin Talk forum
2017 — First on-chain LTC/BTC atomic swap demonstrated
2018 — Maurice Herlihy formalizes multi-party atomic swaps (PODC 2018)
2022–25 — Griefing analysis, PTLC swaps, Rapidash, 4-Swap
HTLC — Hash Time-Locked Contract: pay-to-hash with timeout fallback
PTLC — Point Time-Locked Contract: pay-to-EC-point (privacy preserving)
Adaptor Sig — Schnorr-based commitment that reveals a scalar on broadcast
Griefing — Timing attack where initiator holds counterparty's funds locked
A full BTC ↔ ETH swap using Hash Time-Locked Contracts. Alice has 1 BTC and wants 15 ETH. Bob has 15 ETH and wants 1 BTC.
OP_IF OP_SHA256 <H> OP_EQUALVERIFY <Bob_pubkey> OP_CHECKSIG OP_ELSE <48h> OP_CHECKLOCKTIMEVERIFY OP_DROP <Alice_pubkey> OP_CHECKSIG OP_ENDIF
H = SHA256(R).This is a critical security insight. If Bob's timeout ≥ Alice's timeout, Alice can double-refund and Bob loses his ETH. The asymmetric timeout design prevents this.
Even with correct timeout design, HTLC swaps expose Bob to a griefing attack. Alice holds an implicit option: proceed if price moves favorably, or grief if not.
The swap acts like an American call option for Alice. She pays nothing for this optionality — Bob bears all the risk.
BTC locked for 48h
She owns BTC anyway — no real loss
15 ETH locked for 24h
Real opportunity cost — DeFi yields, other trades
Normal swap: ~5 min. With griefing: up to 24–48h capital lockup.
Agreed rate: 1 BTC = 15 ETH. Move the slider to simulate price change.
| Scenario | Alice Action | Alice P&L | Bob P&L | Outcome |
|---|
Three distinct approaches have been proposed to fix or mitigate the griefing problem in cross-chain atomic swaps.
Bob charges Alice an upfront premium before locking ETH. The premium compensates Bob for Alice's optionality — converting the griefing exploit into a properly priced call option.
Alice pays ~0.1% of ETH value upfront (non-refundable).
If Alice griefs, Bob keeps premium = compensation.
Uses PTLC-style adaptor signatures to enable simultaneous reveal. Both parties reveal their secrets at the same time — eliminating the sequential window that enables griefing.
Requires Schnorr signatures on both chains (e.g., Bitcoin Taproot + ETH EIP-7212).
Multi-party protocol where the party that griefs loses a deposit. Economically disincentivizes griefing. Extends to 4-party scenarios with full safety proofs.
Works across 4 parties, not just 2 — enabling more complex cross-chain topologies.
| Approach | Griefing | Privacy | Chain Support | Complexity |
|---|---|---|---|---|
| HTLC Classic | Vulnerable | Hash visible | Any HTLC chain | Low |
| Premium Model | Partial | Hash visible | BTC-ETH | Medium |
| Rapidash | Resistant | Point-based | Schnorr chains | Medium |
| 4-Swap | Resistant | Point-based | Multi-party | High |
Modern approach using Adaptor Signatures. Instead of a hash H = SHA256(R), use an elliptic curve point S = s·G. The on-chain footprint becomes indistinguishable from a normal Schnorr signature.
An adaptor signature σ_A is a "pre-signature" tied to a public point S = s·G. Completing it requires knowing the scalar s. This creates the same atomicity as HTLC but with no hash visible on-chain.
Alice generates R (secret), H = SHA256(R) (public hash lock)
Contract: "reveal R to unlock payment"
H is visible on-chain → privacy leak, linkable across chains
Alice generates scalar s, S = s·G (EC point, public)
Adaptor: "reveal s to complete Schnorr signature"
On-chain looks like normal key-path Taproot spend → no linkage
OP_IF OP_SHA256 <H> OP_EQUALVERIFY <Bob_pk> OP_CHECKSIG OP_ELSE <48h> OP_CLTV OP_DROP <Alice_pk> OP_CHECKSIG OP_ENDIF
Hash H visible Script visible
Linkable across chains (same H). Identifiable as a swap.
// On-chain: just a Schnorr sig <sig> <pubkey> // No OP_IF, no hash, no script // Looks identical to a normal spend
No hash on-chain Single-sig appearance
Undetectable as a swap. No cross-chain linkage. Privacy-preserving.
Click a row to highlight relevant details. Each protocol represents a distinct design point in the griefing–privacy–complexity trade-off space.
| Protocol | Chain Support | Griefing | Privacy | Complexity | Status |
|---|---|---|---|---|---|
| Nolan HTLC | BTC↔BTC (originally) | Vulnerable | Hash visible | Simple | Original (2013) |
| Herlihy HTLC | Any HTLC chain | Vulnerable | Hash visible | Simple | Classic baseline |
| Transferable Options | BTC↔ETH | Partial (premium) | Hash visible | Medium | Research (AFT 2022) |
| Rapidash | BTC↔ETH (Schnorr) | Resistant | Point-based | Medium | Research (FC 2025) |
| 4-Swap | Multi-party | Resistant | Point-based | Complex | Research (AFT 2025) |
| Submarine Swap | BTC on-chain ↔ LN | N/A | Hash visible | Medium | Deployed (Loop) |
A special case of HTLC-based atomic swaps enabling on-chain BTC ↔ Lightning Network balance conversion. Used by Lightning Labs Loop for channel rebalancing.
Lock: H, Timeout: 48h
HTLC: same hash H, Timeout: 24h
Loop Out — Convert on-chain BTC → LN inbound capacity. Alice gets LN balance.
Loop In — Reverse: drain LN balance → receive on-chain BTC.
Rebalancing — Node operators use Loop to rebalance channels without closing them.
The payment "dives below" the on-chain layer and resurfaces as an LN payment — hence the name.
The HTLC hash H links the on-chain and off-chain legs, ensuring atomicity.
Deployed in production by Lightning Labs Loop and other services. Well-understood security model.
Standard atomic swap: chain A ↔ chain B (different blockchain assets). Submarine swap: on-chain layer ↔ off-chain LN layer of the same blockchain. The "two chains" are just two payment layers — Bitcoin base layer and the Lightning payment channel network on top.