Smart Contract Giving, powered by bc1q21.com
A bc1q21 Smart Contract Gift is not stored inside bc1q21.com.
The Bitcoin and the time-lock conditions exist directly on the Bitcoin blockchain. bc1q21 is a convenience tool that helps users create and claim those gifts, but bc1q21 does not hold the Bitcoin, store the recipient's recovery words, or control the funds.
If bc1q21.com were no longer available, a technically capable person could still reconstruct and claim a gift after its release date using the original 12 recovery words, public Bitcoin blockchain data, and compatible Bitcoin transaction and script tools.
This page explains how that independent recovery is possible.
The 12 recovery words are a BIP39 mnemonic. From those same words, bc1q21 deterministically derives the Bitcoin keys and addresses used by the gift.
For current bc1q21 gifts, important derivation paths include:
Older bc1q21 gifts used a legacy CLTV signing key at:
m/44'/0'/0'/0/0
The current bc1q21 claim software retains compatibility with both the legacy and current gift formats.
The funding address can be deterministically recreated from the 12 recovery words. Public Bitcoin blockchain data can then be searched for transactions involving that address.
A bc1q21 gift creation transaction contains one or more P2SH time-locked outputs and an OP_RETURN output containing encrypted recovery metadata.
The correct gift transaction should not be identified merely because it contains an OP_RETURN output and a P2SH address. The recovery words must be used to reconstruct the expected contract and verify that it matches an actual output in the transaction.
The redeem script is not stored in OP_RETURN.
The OP_RETURN output contains encrypted recovery metadata representing the first release date of the gift.
For current gifts, the encryption secret is derived deterministically from private key material associated with:
m/84'/0'/0'/0/2
Current gifts use authenticated AES-GCM encryption. Older gifts used a legacy AES-CBC format. The current bc1q21 recovery software supports both formats so previously created gifts remain recoverable.
After the encrypted OP_RETURN metadata is decrypted, the first release date is known.
The redeem script is then reconstructed rather than downloaded from bc1q21 or recovered directly from OP_RETURN.
For current gifts, each release uses a deterministic child key derived from:
m/84'/0'/0'/1/{index}
That child public key is combined with the applicable release date to rebuild the Bitcoin CHECKLOCKTIMEVERIFY (CLTV) redeem script.
Conceptually, the script enforces:
The redeem script is hashed to recreate the corresponding P2SH contract address. That reconstructed address must match an actual time-locked output in the gift creation transaction.
Older gifts are reconstructed using the legacy CLTV key derivation. A correct independent recovery process must therefore determine whether the gift uses the legacy or current per-release key format and verify the result against the blockchain.
Once a release date has been reached and the correct contract output has been identified, a Bitcoin transaction can be constructed to spend that output.
A technically correct release transaction must identify the correct previous transaction and output, use the proper transaction locktime and sequence, account for the actual Bitcoin value being spent and an appropriate miner fee, and provide the required signature together with the reconstructed redeem script.
The transaction can then send the released Bitcoin to an address controlled by the recipient and be broadcast directly to the Bitcoin network.
Before signing, the raw funding transaction and the actual value of the output being spent should be independently verified. This helps ensure that incorrect third-party or API data cannot cause an unintended miner fee or invalid transaction.
In simplified technical form, independent recovery follows this sequence:
bc1q21 has previously completed a manual mainnet recovery test using the original recovery words and public Bitcoin blockchain information without relying on the normal bc1q21 recipient claiming interface.
The historical wallet addresses, transaction IDs, redeem scripts, recovery words, and other identifying blockchain information from that test are intentionally not published here.
The purpose of the test was to demonstrate the underlying property of the system: the recipient's ability to recover the Bitcoin does not depend on bc1q21 holding a secret or maintaining custody of the funds.
Claiming a gift manually is an advanced Bitcoin recovery procedure. It requires an accurate understanding of BIP39 key derivation, Bitcoin scripts, P2SH, CHECKLOCKTIMEVERIFY, transaction construction, transaction fees, signatures, and broadcasting.
This page is intended to document the independent recovery architecture and provide a technical reference. It should not be interpreted as a recommendation that an inexperienced user manually construct or sign Bitcoin transactions.
Bitcoin transactions are irreversible. A mistake in transaction construction, signing, fee calculation, output selection, or destination address can result in permanent loss.
The ordinary bc1q21 recipient interface exists to perform these steps more safely and conveniently. Independent manual recovery is the fallback path demonstrating that the Bitcoin itself is not dependent on the continued operation of bc1q21.com.
A bc1q21 Smart Contract Gift is controlled by Bitcoin's blockchain rules and deterministic cryptographic information derived from the recipient's recovery words.
bc1q21 does not hold the recipient's Bitcoin or possess a server-side secret required to release it.
With the original 12 recovery words, public blockchain data, and appropriate Bitcoin technical tools, a competent Bitcoin engineer can reconstruct and claim a mature gift independently of bc1q21.com.
Protect the 12 recovery words carefully. They are the critical private recovery information for the gift.
