BTCMessage Demo & About


It is difficult to send an unsolicited message to a Bitcoin address, where a communication channel is yet to be established (see [1], [2], [3], [4], [5]). No existing solution results in a message which is reasonably noticable to an unexpecting recipient.

Messages using the BTCMessage tool are relatively expensive & public, and therefore are not effective means of communication. But they may be desirable in certain circumstances:

  • To attempt to contact the mistaken recipient of an accidental transaction.
  • To give someone advice.
  • Leaving a small message along with a donation.

These messages are not for common use as the message is comprised of unspendable transaction outputs (UTXO) which could theoretically bloat the blockchain size.

Though with currently over 65,000,000 unspent UTXOs, an ocassional messages will have little impact.

How it works

Creating such long vanity addresses legitimately is essentially impossible.
Instead we can forge one.

Bitcoin addresses are only valid if they have a valid checksum, meaning that it's highly likely any selected 34 characters will not be a valid address. To forge an address we instead:

  1. Decide upon the text we wish to include in our address.
  2. Pad the address up to 33 characters.
  3. Convert this base58 address back into bytes.
  4. Recalculate the checksum from the first 21 bytes, and use it to overwrite the last 4 bytes.
  5. Convert the address bytes back to base58 format.
  6. Any other reason you wish to attempt to communicate with an address.

The checksum uses the first 21 bytes of the address, hashes it twice with SHA256 and then takes the first 4 bytes of this hash; which will comprise the last 4 bytes of our address.

For a full tutorial how to do this in C, please see my website.

1BTCmsg Header

This is an optional message header which identifies the transaction as a message, I own this address so might get a few cents from each message.

I am currently searching for a vanity address "1BTCMessage...", which for a case insensitive match will take ~70 days on my GTX 970. I'm using shorter ones until I find a match, or a better solution.


Before 2015, there was no standard for how inputs outputs of Bitcoin transactions should be ordered. As a result, wallets could often have discenable fingerprints based on how they composed transactions.

BIP0069 introduced a standard for ordering where outputs are first ordered by amount, and then secondly by the `scriptPubKeys` byte arrays.

We use this to our advantage to order our message, by using ascending output amounts our message will display in the correct order.


Any to feature requests/suggestions please email me at