Bitcoin hash puzzle script Updated 2025-03-28 +Created 2025-01-04
View more
We've found three unspent puzzle scripts that require finding SHA-256 hashes:
c4b46c5d88327d7af6254820562327c5f11b6ee5449da04b7cfd3710b48b6f55 0 OP_SHA256 None OP_EQUAL
702c36851ed202495c2bec1dd0cefb448b50fafd3a5cdd5058c18ca53fc2c3d1 0 OP_SHA256 None OP_EQUAL
fb01987b540ec286973aac248fab643de82813af452d958056fee8de9f4535ab 0 OP_SHA256 None OP_EQUAL
All three are also mentioned at: bitcoincashresearch.org/t/p2sh32-a-long-term-solution-for-80-bit-p2sh-collision-attacks/750/23 in addition to some OP_HASH256 ones. The thread manages to identify one of the OP_HASH256 ones as a fake Genesis block hash.
They were mined on 01 Apr 2014, 02 Apr 2014 and 03 Apr 2014, suggesting a possible April fool's reference?
Each is worth 0.0002 BTC, which is only 20$ as of 2024, so it's not worth much effort beyond the fun aspect of it. But it is fun!
Read the full article
Base58 messages Updated 2025-03-28 +Created 1970-01-01
View more
Bitcoin addresses are by convention expressed in Base58, which is a human readable binary-to-text encoding invented by Bitcoin.
It is a bit like Base64, but obsessed with eliminating characters that look like one another in popular but stupid fonts like capital "I" and lower case ell "l". As such, any embedded text is rather obfuscated due to this limitations, and people often resort to leet-like replacements such as '1' to represent 'I'.
This seems to be one of the earliest strategies used to encode messages into the Bitcoin blockchain. The first known example appears in 2011. Then starting November 2011, a large number of messages were inscribed n short successsion, presumably by a single person or small group.
The interest in Base58 encoding might have initially arisen with people's desire to have "vanity addresses", that is Bitcoin addresses that have real words in them, much like vanity plates or vanity numbers. Such addresses with long words in them are hard to find while keeping the address spendable, because they have to correspond to a private key. An extreme notable example is:which contains the awkward 13 letter word:
embarrassable
in it. TODO: proof that it is pendable?
Perhaps inspired by this, some people also decided to use Base58 addresses as a way to create more general unspendable inscriptions, even even though the method is much more clumsy and complicated than P2FKHS. There is however a certain art to working under limitations.
Figure 1.
Total burn addresses as a function of time found by Bitcoin Burn Addresses: Unveiling the Permanent Losses and Their Underlying Causes
. Although it is not solely focused on inscriptions and may also contain functional burn addresses, it is likely that the methods of Khatib/Legout capture the overall trend of base58 inscription counts.
These messages were originally found with: github.com/cirosantilli/bitcoin-inscription-indexer#payload-size-out-utxo-2vals which tracks the largest transactions with unspent outputs.
Bitcoin Burn Addresses: Unveiling the Permanent Losses and Their Underlying Causes later revealed many new ones.
Finding Base58 messages is intrinsically hard for a few reasons
  • the words may be garbled by Base58 leet
  • only very small ammounts of data can be encoded at a time, and all of it contains ASCII, so you can't just "find all long ASCII strings" as we started doing for other ASCII inscriptions a la strings -n20; you have to use some dictionary as a basis
  • the Base58 does not show up raw on the blockchain, as it is just a human representation for the actual binary data that does, so you can't just strings the blockchain, you have to parse it
The interesting following transactions contain base58 encoded messages on addresses, sorted chronologically, and heighlighted either due to their earliness or historical or artistic quality:
Related:
Read the full article
Genesis block message Updated 2025-03-28 +Created 1970-01-01
View more
Inscription added by Satoshi Nakamoto on the Genesis block containing:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
which is a reference to: www.thetimes.co.uk/article/chancellor-alistair-darling-on-brink-of-second-bailout-for-banks-n9l382mn62h wihch is fully titled:
Chancellor Alistair Darling on brink of second bailout for banks
The "Alistair" was slikely removed due to limited payload concerns.
Through the newspaper reference, the message proves a minimal starting date for the first mine.
And it hints that one of Bitcoin's motivation was the financial crisis of 2007-2008, where banks were given bailouts by the government to not go under, which many people opposed as the crisis was their own fault in the first place. A notable related stab is taken at Len Sassaman tribute.
We can extract the image from the blockchain ourselves by starting from: blockchain.info/block-height/0?format=json.
From that page we manually extract the hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f and then:
wget -O 0.hex https://blockchain.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f?format=hex
xxd -p -r 0.hex
and that does contain the famous genesis block string:
EThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks
The JSON clarifies that the data is encoded in the script field of the transaction input:
{
      {
         "script":"04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73"
The extra E (0x45 in ASCII) in EThe Times is just extra noise required by the script, we can break things up as:
04ffff001d0104 45 5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
where:
  • 54 is T
  • the 04ffff001d0104 part just doesn't show up on the terminal because it is not made of any printable characters.
The initial 04 is OP_RETURN.
TODO what is actual the meaning of the ffff001d010445 part? @defango twitter.com/defango/status/1642750851134652417 comments:
04ffff001d0104 is a hexadecimal string. It is commonly used in the Bitcoin network as a part of the mining process. Specifically, it is used as the target value for a block to be considered valid by the Bitcoin network.
This value represents the level of difficulty required for a miner to generate a block that meets the network's criteria. The first four bytes, 04ffff, represent the maximum possible target value. The next three bytes, 001d01, represent the current difficulty level
while the final byte, 04, is a padding byte. In summary, this value sets the difficulty level for mining a new block in the Bitcoin network.
TODO the output of the transaction has a jumbled script, likely just a regular output to get things going, can't be arbitrary like input.
Read the full article
History of Bitcoin Updated 2025-03-28 +Created 1970-01-01
View more
Read the full article
How Bitcoin works Updated 2025-03-28 +Created 1970-01-01
View more
Here is a very direct description of the system:
  • each transaction (transaction is often abbreviated "tx") has a list of inputs, and a list of outputs
  • each input is the output of a previous transaction. You verify your identity as the indented receiver by producing a digital signature for the public key specified on the output
  • each output specifies the public key of the receiver and the value being sent
  • the sum of output values cannot obvious exceed the sum of input values. If it is any less, the leftover is sent to the miner of the transaction as a transaction fee, which is an incentive for mining.
  • once an output is used from an input, it becomes marked as spent, and cannot be reused again. Every input uses the selected output fully. Therefore, if you want to use an input of 1 BTC to pay 0.1 BTC, what you do is to send 0.1 BTC to the receiver, and 0.9 BTC back to yourself as change. This is why the vast majority of transactions has two outputs: one "real", and the other change back to self.
Code 1. "Sample Bitcoin transaction graph" illustrates these concepts:
  • tx0: magic transaction without any inputs, i.e. either Genesis block or a coinbase mining reward. Since it is a magic transaction, it produces 3 Bitcoins from scratch: 1 in out0 and 2 in out1. The initial value was actually 50 BTC and reduced with time: Section "Bitcoin halving"
  • tx1: regular transaction that takes:
    • a single input from tx0 out0, with value 1
    • produces two outputs:
      • out0 for value 0.5
      • out1 for value 0.3
    • this means that there was 0.2 left over from the input. This value will be given to the miner that mines this transaction.
    Since this is a regular transaction, no new coins are produced.
  • tx2: regular transaction with a single input and a single output. It uses up the entire input, leading to 0 miner fees, so this greedy one might (will?) never get mined.
  • tx3: regular transaction with two inputs and one output. The total input is 2.3, and the output is 1.8, so the miner fee will be 0.5
                   tx1                     tx3
  tx0            +---------------+       +---------------+
+----------+     | in0           |       | in0           |
| out0     |<------out: tx0 out0 |  +------out: tx1 out1 |
| value: 1 |     +---------------+  |    +---------------+
+----------+     | out0          |  |    | in1           |
| out1     |<-+  | value: 0.5    |  | +----out: tx2 out0 |
| value: 2 |  |  +---------------+  | |  +---------------+
+----------+  |  | out1          |<-+ |  | out1          |
              |  | value: 0.3    |    |  | value: 1.8    |
              |  +---------------+    |  +---------------+
              |                       |
              |                       |
              |                       |
              |    tx2                |
              |  +---------------+    |
              |  | in0           |    |
              +----out: tx0 out1 |    |
                 +---------------+    |
                 | out0          |<---+
                 | value: 2      |
                 +---------------+
Code 1.
Sample Bitcoin transaction graph
.
Since every input must come from a previous output, there must be some magic way of generating new coins from scratch to bootstrap the system. This mechanism is that when the miner mines successfully, they get a mining fee, which is a magic transaction without any valid inputs and a pre-agreed value, and an incentive to use their power/compute resources to mine. This magic transaction is called a "coinbase transaction".
The key innovation of Bitcoin is how to prevent double spending, i.e. use a single output as the input of two different transactions, via mining.
For example, what prevents me from very quickly using a single output to pay two different people in quick succession?
The solution are the blocks. Blocks discretize transactions into chunks in a way that prevents double spending.
A block contains:
  • a list of transactions that are valid amongst themselves. Notably, there can't be double spending within a block.
    People making transactions send them to the network, and miners select which ones they want to add to their block. Miners prefer to pick transactions that are:
    • small, as less bytes means less hashing costs. Small generally means "doesn't have a gazillion inputs/outputs".
    • have higher transaction fees, for obvious reasons
  • the ID of its parent block. Blocks therefore form a linear linked list of blocks, except for temporary ties that are soon resolved. The longest known list block is considered to be the valid one.
  • a nonce, which is an integer chosen "arbitrarily by the miner"
For a block to be valid, besides not containing easy to check stuff like double spending, the miner must also select a nonce such that the hash of the block starts with N zeroes.
For example, considering the transactions from Code 1. "Sample Bitcoin transaction graph", the block structure shown at Code 2. "Sample Bitcoin blockchain" would be valid. In it block0 contains two transactions: tx0 and tx1, and block1 also contains two transactions: tx2 and tx3.
 block0           block1             block2
+------------+   +--------------+   +--------------+
| prev:      |<----prev: block0 |<----prev: block1 |
+------------+   +--------------+   +--------------+
| txs:       |   | txs:         |   | txs:         |
| - tx0      |   | - tx2        |   | - tx4        |
| - tx1      |   | - tx3        |   | - tx5        |
+------------+   +--------------+   +--------------+
| nonce: 944 |   | nonce: 832   |   | nonce: 734   |
+------------+   +--------------+   +--------------+
Code 2.
Sample Bitcoin blockchain
.
The nonces are on this example arbitrary chosen numbers that would lead to a desired hash for the block.
block0 is the Genesis block, which is magic and does not have a previous block, because we have to start from somewhere. The network is hardcoded to accept that as a valid starting point.
Now suppose that the person who created tx2 had tried to double spend and also created another transaction tx2' at the same time that looks like this:
  tx2'
+---------------+
| in0           |
| out: tx0 out1 |
+---------------+
| out0          |
| value: 2      |
+---------------+
Clearly, this transaction would try to spend tx0 out1 one more time in addition to tx2, and should not be allowed! If this were attempted, only the following outcomes are possible:
  • block1 contains tx2. Then when block2 gets made, it cannot contain tx2', because tx0 out1 was already spent by tx2
  • block1 contains tx2'. tx2 cannot be spent anymore
Notably, it is not possible that block1 contains both tx2 and tx2', as that would make the block invalid, and the network would not accept that block even if a miner found a nonce.
Since hashes are basically random, miners just have to try a bunch of nonces randomly until they find one that works.
The more zeroes, the harder it is to find the hash. For example, on the extreme case where N is all the bits of the hash output, we are trying to find a hash of exactly 0, which is statistically impossible. But if e.g. N=1, you will in average have to try only two nonces, N=2 four nonces, and so on.
The value N is updated every 2 weeks, and aims to make blocks to take 10 minutes to mine on average. N has to be increased with time, as more advanced hashing hardware has become available.
Once a miner finds a nonce that works, they send their block to the network. Other miners then verify the block, and once they do, they are highly incentivized to stop their hashing attempts, and make the new valid block be the new parent, and start over. This is because the length of the chain has already increased: they would need to mine two blocks instead of one if they didn't update to the newest block!
Therefore if you try to double spend, some random miner is going to select only one of your transactions and add it to the block.
They can't pick both, otherwise their block would be invalid, and other miners wouldn't accept is as the new longest one.
Then sooner or later, the transaction will be mined and added to the longest chain. At this point, the network will move to that newer header, and your second transaction will not be valid for any miner at all anymore, since it uses a spent output from the first one that went in. All miners will therefore drop that transaction, and it will never go in.
The goal of having this mandatory 10 minutes block interval is to make it very unlikely that two miners will mine at the exact same time, and therefore possibly each one mine one of the two double spending transactions. When ties to happen, miners randomly choose one of the valid blocks and work on top of it. The first one that does, now has a block of length L + 2 rather than L + 1, and therefore when that is propagated, everyone drops what they are doing and move to that new longest one.
Read the full article