Reading your archive from the blockchain#

The transaction hash of the archived tweet is the only thing you need to find your data in the future. If you have that, you'll forever be able to find the data in any Bitcoin blockchain dataset.

Find your tx hash#

To find your transaction hash look at tweet we replied with or you can sign-in to to see archives you've made.

For example, here's the coffee_dad tweet example from the front page of this website: 93e3914340937e96426e671ef90a21409ec6709e7444567bcbcb04c17c205f14

Use a block explorer#

Now go to any Bitcoin block explorer. Here are some examples:

And paste that transaction hash 93e3914340937e96426e671ef90a21409ec6709e7444567bcbcb04c17c205f14 into the search field.

What you're looking at now is a Bitcoin transaction. The TL;DR of Bitcoin transactions is that there are inputs and outputs. The inputs are where the money came from (addresses belonging to, and the outputs are where the money was sent to.

But instead of putting someone's Bitcoin address in the output, we put the actual tweet archive data.

Examine the outputs#

Look at the outputs of this transaction and if you look closely you'll notice there are 3 different types of outputs in our transactions.

  1. a single OP_RETURN at the beginning
  2. multiple P2SH (pay to script hash)
  3. a single P2SH change transaction (pay to script hash change transaction)

The first output will be an OP_RETURN output. Most block explorers will convert this to ASCII (text) for you because that's what the intended purpose is. We put the metadata of the tweet there. TTB-T,$AUTHOR_NAME,$TWEET_ID,$TWEET_TIMESTAMP,$ARCHIVE_REQUESTOR_NAME

Unfortunately, Bitcoin only allows you to use 1 single OP_RETURN output so we use fake P2SH outputs (which are limited to 20 bytes) for the rest of our data, which is the full tweet text.

The change transaction may not always exist, but if it does, it will always be last and you can ignore it. This change transaction won't have any data in it.

Decoding the full tweet text#

Most block explorers present the outputs in hexadecimal, and some others in base58. It doesn't matter, it's the same data, just presented differently.

  • Hexadecimal characters are A-F and 0-9 and NOT case sensitive
  • Base58 is a variation of base64, its characters, like base64: are a-z and A-Z and 0-9 and IS case sensitive (EXCEPT it excludes 0 (zero), O (capital o), I (capital i) and l (lower case L))

At time of writing, and were presenting the data in hexadecimal, was using base58. example#

See how the first output, the OP_RETURN output, is already presented as plain text (ASCII) for you. This is the case with most/all block explorers.

This tweet was short, so there's only 1 output in the middle. It has trailing zeros, those are nulls/padding that you can ignore. Paste 686176696e6720636f66666565 into a hex-to-ASCII convert to get "having coffee"

Hosted on