Nelson-Mandela.jpg analysis Updated 2024-12-15 +Created 1970-01-01
View more
The toplevel transaction is 78f0e6de0ce007f4dd4a09085e649d7e354f70bc7da06d697b167f353f115b8e
Like all AtomSea & EMBII uploads, the data it is encoded as P2FKH.
The full concatenated payload contains the following ASCII characters:
8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba|396*8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba
575061146335bd57f2dc132112152d0eeea44cf187ea6a52ac02435a7e5bea44
674c7cc34ea44bb276c6caf76f2b28fa1597380ab6e6a6906076d8f7229ca5b3
8e2642416ad20924b43f51a633fa1c0a5ba8e4a7b631877db1c64540a42081c9
a3084018096b92af04df57b6116e01ff4b7c7e8bd228235ed49e23f4a2817029
39348722b841afa0c5b67e5af10839afe965ed1b24874e89336bea9fa4ef3091
tomSea & EMBII
Output 2 is a change, so it contains no data and has been excluded. Change appear to be randomly placed in the list of output of the uploads, but they can be easily removed because they are the only output with a different value.
The newlines shown above are explicitly encoded as CR LF newlines with characters 0d 0a.
396 is the number of payload bytes between 396*8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba and the last txid 39348722b841afa0c5b67e5af10839afe965ed1b24874e89336bea9fa4ef3091, including newlines but exclusding the last line.
The last line appears to contain arbitrary data to fill out the 20 byte payload granularity:
  • A is missing from AtomSea
  • there is a NUL character just after EMBII, possibly part of the protocol?
Now let's inspect the transactions linked to from toplevel.
tx 8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba contains only payloads without any change. It starts with the following UTF-8 string with CR LF spaces;
"396\“There is nothing like returning to a place
 that remains unchanged to find the ways in 
 which you yourself have altered.”
 -Nelson Mandela


Nelson Rolihlahla Mandela was a South African anti-apartheid revolutionary, politician and philanthropist who served as President of South Afrd۽^2c'︨`ica from 1994 to 1999. -Wikipedia

Born: July 18, 1918, Mvezo, South Africa
Died: December 5, 2013
396 is once again the number of payload bytes present in that string.
This is immediately followed without any separator by a filename, and another size marker:
Nelson-Mandela.jpg?14400/
then followed by all the 14400 - len(Nelson-Mandela.jpg?) + len(/) JPEG bytes bytes, starting with the two JPEG file signature byte "FF D8".
Further toplevel transaction payloads are then simply concatenated with the previous ones, until the last bytes of the image "FF D9" appears at the end of the payload.
00000430  d2 81 de 80 0c 52 f1 40  ea 29 68 03 ff d9 6f 6d  |.....R.@.)h...om|
00000440  53 65 61 20 26 20 45 4d  42 49 49 00              |Sea & EMBII.|
padded once again by an AtomSea & EMBII string fragment terminated by a NUL character.
Read the full article
How Bitcoin works Updated 2024-12-15 +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 halvening"
  • 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
Who bought Laszlo Hanyecz pizza? Updated 2024-12-15 +Created 1970-01-01
View more
TODO who bought the Bitcoins? Is anyone else besides Jeremy Sturdivant
The original forum thread bitcointalk.org/index.php?topic=137.msg1195 suggests multiple purchases were made, until he had to withdrawl the offer. Perhaps an easier question is how many pizzas he got in the first place.
www.reddit.com/r/Bitcoin/comments/13on6px/comment/jl55025/?utm_source=reddit&utm_medium=web2x&context=3 mentions without source:
I know. Laszlo Hanyecz estimates that he spent 100,000 BTC on pizza in 2010. Laszlo is the man that invented GPU mining and he mined well over 100,000 BTC.
One source is: bitcoinmagazine.com/culture/the-man-behind-bitcoin-pizza-day-is-more-than-a-meme-hes-a-mining-pioneer
Related thread from May 2023: bitcointalk.org/index.php?topic=5453728.msg62286606#msg62286606 "Did Laszlo Hanyecz exchange 40000 BTC for 8 pizzas, not 10000 BTC for 2 pizzas?" but their Googling is so bad no one had found the 100,000 quote before Ciro.
As per bitcoin.stackexchange.com/questions/113831/searching-the-blockchain-based-on-transaction-amount-and-or-date at blockchair.com/bitcoin/outputs?s=time(asc)&q=value(1000000000000),time(2010-05-18..2010-08-05) we can list all the transactions made between the offer and withdrawal dates for value exactly 10k. There are only about 20 of them, and including someone the 22nd of May, so it is extremely likely that this will contain the hits. No repeated recipients however, so it is hard to progress with more advanced analytics tools
Some of the transactions are:
8 d1a429c05868f9be6cf312498b77f4e81c2d4db3268b007b6b80716fb56a35ad (29 May) is a common looking transaction with a single input from 1Bc7T7ygkKKvcburmEg14hJKBrLD7BXCkX and two outputs, one likely being the change to 1GH4dRUAagj67XVjr4TV6J9RFNmGYsLe7c and the other the actual value to 138eoqfNcEdeU9EG9CKfAxnYYz62uHRNrA.
The input chain is complex, but it does contain one block reward on the third level: 17PBFeDzks3LzBTyt6bAMATNhowrvx5kBw + 79 rewards 4th level at 045795627ca29ec72a94c23a65ee775ea1949d60b6fba0938b75e1cfe1e6643e.
Read the full article