RobinLinus

Replay Protection via Reserved nLockTime Values

A Bitcoin-derived hard fork can use a reserved nLockTime value as a replay-protection marker.

For example, a fork can define:

nLockTime == LOCKTIME_THRESHOLD - 1

RobinLinus

Promising Real-World Bitcoin Payment Examples

Compiled from the X thread started by @robin_linus (April 2026):
"What are the most promising examples of Bitcoin payments actually working in the real world?"

---

Circular Economies & Bitcoin Communities

These are locations or projects where Bitcoin (often via Lightning) is used as everyday money among locals and visitors.

RobinLinus

I Like Big Blocks And I Cannot Lie

Debunking the myth that the 1 MB block-size limit was an original, permanent, sacred design constraint.

Satoshi Quotes

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices. Source

---

RobinLinus

BIP300-like withdrawals with BIP448-style covenants

This scheme emulates the slow miner-voting part of BIP300 using the covenant tools proposed in BIP448.

It is not full BIP300. It only supports fixed-denomination withdrawals to a fixed, permissioned set of recipients.

Assumptions

fixed withdrawal denomination D

RobinLinus

Onchain KYC and Whitelisted Custody Using BIP 448

A technical sketch of a “perpetual KYC” covenant using BIP 448’s proposed Taproot-native opcode bundle: BIP 446 OP_TEMPLATEHASH and BIP 348 OP_CHECKSIGFROMSTACK. BIP 448 also includes BIP 349 OP_INTERNALKEY, but this construction does not rely on it.

This is hypothetical. BIP 448, BIP 446, and BIP 348 are draft soft-fork proposals, and BIP 448 leaves activation to be determined later. The construction only works if the relevant opcodes are activated.

The same mechanism can be viewed in two ways:

regulated custody: coins can move only to approved KYC accounts

RobinLinus

Subchains with THIKCS

Summary

A subchain is an embedded blockchain whose blocks are published inside Bitcoin blocks. It is defined by a sequence of Bitcoin publish transactions. Bitcoin consensus enforces the ordering and cadence of publication; subchain clients enforce whatever meta-consensus rules they want over the published data.

This construction assumes the THIKCS upgrade: OP_TEMPLATEHASH, OP_INTERNALKEY, and OP_CHECKSIGFROMSTACK, as proposed in BIP-448. The important property is that OP_TEMPLATEHASH commits to the spending transaction template, but not to the prevouts, input amounts, input scriptPubKeys, or other inputs' annexes.

The construction uses two Bitcoin transactions per applied subblock:

RobinLinus

  BIP: 447
  Layer: Consensus (soft fork)
  Title: OP_TEMPLATEHASH2
  Author: Robin Linus <roblinus@stanford.edu>
  Status: Draft
  Type: Specification
  License: CC0-1.0

RobinLinus

A Self-Custodial 2FA Wallet with Built-in Recovery and Inheritance

Overview

This protocol describes a self-custodial Bitcoin wallet secured by a 2FA cosigning server, with two additional spending paths: a user-controlled unilateral recovery path (in case the server disappears or refuses to sign) and an heir-controlled inheritance path. The design improves on two families of existing wallets:

• Cosigner-based 2FA wallets like [Blockstream Green's Multisig Shield][green-2fa] use a CSV that begins ticking at deposit confirmation. As the timelock approaches expiry, the user must [redeposit][green-redeposit] funds to a fresh address to keep 2FA protection alive.
• Timelock-based recovery/inheritance wallets like [Wizardsardine's Liana][liana] likewise anchor their timelocks to deposit confirmation. Liana users must periodically "refresh coins" before the backup path becomes prematurely spendable.

This protocol's timelock is anchored to recovery initiation, not deposit. Funds can sit indefinitely

RobinLinus

Safe eCash/BTC Coin-Splitting Using a Chain-Unique Dust Input

The goal is to spend forked coins on eCash without exposing the corresponding BTC coins to replay risk, and without importing the valuable private key into the eCash splitting software.

The method is to construct an eCash transaction that spends both:

1. the valuable pre-fork UTXO, which exists on both Bitcoin and eCash; and
2. a small “dust” UTXO that exists only on the eCash chain.

The valuable input is signed with SIGHASH_ALL, so its signature commits to the full transaction, including the eCash-only dust input. Because that dust input does not exist as a valid spendable UTXO on Bitcoin, the transaction cannot be replayed on Bitcoin.

RobinLinus

Layer Tree protocol summary

Layer Tree is a Bitcoin L2 built around a shared pool UTXO controlled by an n-of-n MuSig key held by a set of operators. The operators may be implemented as independently attested TEEs.

Users’ balances are represented by periodically signed exit trees. Each exit tree commits to the current allocation of the pool among users. Users can transfer funds offchain, withdraw cooperatively to L1, deposit from L1, or unilaterally exit through the latest available exit tree.

The protocol fundamentally relies on a 1-of-N honest operator assumption for safety and data availability, while normal operation requires N-of-N operator cooperation.

---