RobinLinus

A Bitcoin 2FA Wallet with Presigned Recovery and Inheritance

This is an alternative construction for Robin Linus’s 2FA wallet proposal. It preserves the central idea: an emergency withdrawal must consume a token created by a separate kickoff transaction, and the withdrawal delay runs from that token’s creation. A deposit can remain protected indefinitely until someone starts an emergency exit.

The construction uses existing Taproot signature rules. It needs neither OP_TEMPLATEHASH2 nor OP_TEMPLATEHASH, and it does not require deleting private keys. Instead, the user and the 2FA server jointly presign two restricted spends for each deposit. A Taproot SIGHASH_NONE signature commits to the complete input set, including the emergency token and its relative timelock, while leaving outputs unspecified. At withdrawal time, the token holder supplies another signature that authorizes the destination and fee.

The tradeoff is per-UTXO in

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.