User Rating 0.0 ★★★★★

Total Usage 0 times

Category Crypto & Mining

Text to encode ASCII recommended. Multi-byte UTF-8 characters use more payload space.

Is this tool helpful?

Your feedback helps us improve.

★ ★ ★ ★ ★

About

Bitcoin transactions can embed arbitrary data by encoding text into the 20-byte payload of P2PKH addresses. Each address carries up to 20 bytes of ASCII data, prefixed with version byte 0x00 and suffixed with a 4-byte checksum derived from double SHA-256 hashing. The resulting addresses are indistinguishable from real payment addresses at the protocol level. If you broadcast a transaction with these addresses as outputs, your message is stored permanently on the blockchain. This technique was notably used to embed the Len Sassaman tribute and Wikileaks cables. This tool performs real Base58Check encoding - not a simulation. It computes genuine SHA-256 checksums via the Web Crypto API and handles the full Base58 alphabet (excluding confusable characters 0, O, I, l). Limitation: payloads are not spendable. Funds sent to these addresses are permanently lost.

Formulas

The Base58Check encoding process for each 20-byte text chunk:

payload = pad(UTF8bytes(text_chunk), 20)

raw = 0x00 ‖ payload

checksum = SHA256(SHA256(raw))[0..3]

address = Base58(raw ‖ checksum)

where ‖ denotes byte concatenation, SHA256 is the SHA-256 cryptographic hash, and Base58 converts a big-endian integer to the 58-character Bitcoin alphabet. Leading zero bytes in the input map to leading 1s in the output. Decoding reverses: strip leading 1s, convert Base58 → integer → 25 bytes, verify the checksum matches, then extract bytes 1 - 20 as the text payload.

Reference Data

Parameter	Value	Description
Version Byte	0x00	Mainnet P2PKH (prefix “1”)
Payload Size	20 bytes	RIPEMD-160 hash length (repurposed for data)
Checksum Size	4 bytes	First 4 bytes of double SHA-256
Total Raw Bytes	25 bytes	1 version + 20 payload + 4 checksum
Address Length	25 - 34 chars	Base58 encoded output
Base58 Alphabet	58 chars	123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
Excluded Characters	0, O, I, l	Removed to prevent visual ambiguity
Hash Algorithm	SHA-256	Applied twice for checksum
Max Text per Address	20 chars	ASCII characters (1 byte each)
Addresses for 140 chars	7	ceil(140 ÷ 20)
P2SH Version Byte	0x05	Prefix “3” (not used here)
Testnet Version Byte	0x6F	Prefix “m” or “n” (not used here)
Bech32 Format	bc1...	SegWit native (not used here)
OP_RETURN Limit	80 bytes	Alternative data embedding method
Dust Threshold	546 satoshis	Minimum output to avoid relay rejection

Frequently Asked Questions

Yes. Each address passes full Base58Check validation. The version byte is 0x00 (mainnet P2PKH) and the 4-byte checksum is computed via double SHA-256. Any Bitcoin node or wallet will accept these as syntactically valid addresses. However, the corresponding private keys are unknown, so any funds sent to them are irrecoverable.

OP_RETURN outputs are explicitly marked as unspendable and limited to 80 bytes per output. Address-based encoding disguises data as normal payment outputs (up to 20 bytes each) and requires a dust-level payment per output (546 satoshis minimum). OP_RETURN is the modern, preferred method. Address encoding is the older technique used in early blockchain messages.

The encoder uses UTF-8 byte representation. Multi-byte characters (e.g., emoji at 4 bytes, CJK at 3 bytes) consume more of the 20-byte payload per address. A single emoji could use 4 of the 20 available bytes. The decoder correctly reassembles multi-byte sequences across address boundaries.

Technically yes. You would construct a transaction with each generated address as a separate output, each funded above the dust threshold of 546 satoshis. The message becomes permanently embedded in the blockchain. Be aware this creates unspendable UTXOs, which is considered blockchain pollution by many node operators.

Each address payload is exactly 20 bytes. If the final chunk of your text is shorter, the remaining bytes are zero-padded. The decoder strips trailing null bytes (0x00) from the last address. In rare cases where your original text intentionally ends with null bytes, they will be lost.

Divide your message length in bytes by 20 and round up. A 140-character ASCII tweet needs ceil(140 ÷ 20) = 7 addresses. At 546 satoshis each, that costs 3822 satoshis in outputs plus the transaction fee.