vostrnad

bitcoin

Definitive explanation of my weird Bitcoin transaction

Years of learning about the Bitcoin protocol, mostly by asking and answering questions on Bitcoin Stack Exchange. If you want to start somewhere, learn what are all the components of a raw transaction.

Here it is: https://github.com/vostrnad/bitcoin-easter-egg-tx

Only in SegWit, they're standard in legacy scripts. There also exist "hybrid keys" that are non-standard everywhere.

Yes, the [first ever transaction](https://mempool.space/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16) from Satoshi to Hal used the block 9 coinbase reward. A certain fraudster also claimed to have this key in possession.

Because it only uses standard input and output types, that's why! Note that sending to (but not spending from) any not-yet-defined SegWit output type is standard.

Analysis of 0xB10C's weird bitcoin transaction

supertestnet

Vanity hashes are hardly anything new, 0xB10C has done a similar one (see https://b10c.me/7). I don't have any mining infrastructure, and I don't think you could even use it for vanity hashes. However, 5 custom bytes isn't that expensive, it took me around a month on a relatively recent CPU.

On testnet it would probably go unnoticed, and testnet is occasionally reset. I wanted to make something that would last.

The part that needed rewriting in Rust was grinding the vanity TXID and WTXID by repeatedly generating signatures. Even with all sorts of elliptic curve optimizations and porting the code to Rust, it still took over a month of grinding on my relatively recent CPU.

Sure! It might take a bit of work to clean up, but if people are interested then I'll do it.

For anyone interested, I've published the full list of Easter eggs: https://stacker.news/items/600187

If you've been on Twitter or Stacker News last week, you may have seen this strange Bitcoin transaction:

https://mempool.space/tx/b10c0000004da5a9d1d9b4ae32e09f0b3e62d21a5cce5428d4ad714fb444eb5d

![](https://m.stacker.news/38308)

It caught a lot of people's attention, and they had two pressing questions: Who made it? And what secrets does it hide? Here I give an answer to both.

Message:

```
Transaction b10c0000004da5a9d1d9b4ae32e09f0b3e62d21a5cce5428d4ad714fb444eb5d was created by Vojtěch Strnad.
```

Address:

```
1J7SZJry7CX4zWdH3P8E8UJjZrhcLEjJ39
```

Signature:

```
H6WHgwnYtggJH5yqVpeL9NRxWJ+8hqUW31Mc1J9e9Q3cZGEdDjixYT6jnPpIHM2FVHDbeEstP8KzDsj5U01BNSo=
```

If you're going to verify the signature yourself (and I highly recommend you do), make sure not to use Bitcoin Core or Electrum downloaded over a hotel Wi-Fi.

With that out of the way, here is every Easter egg in that transaction. The last two are the only ones that weren't noticed by anyone as far as I know:

- The transaction was included in block 850000.
- The transaction's locktime is the genesis block timestamp.
- The transaction has a vanity TXID and WTXID. The TXID starts with `b10c0000004da5...` which is an homage to the Bitcoin developer 0xB10C who has created a transaction with a similar TXID in the past (see https://b10c.me/7). The WTXID starts with `0000000001d54...` i.e. a bunch of zeroes, just like a block hash.
- The transaction uses every possible standard input and output type: P2PK, P2PKH, P2MS (bare multisig), P2SH, P2WPKH, P2WSH, P2TR, OP_RETURN, and a 2-byte SegWit v1 output (with a script borrowed from the Ephemeral anchors proposal). Some of these are used multiple times on the input side: P2SH is split into legacy P2SH, wrapped P2WPKH and wrapped P2WSH, and P2TR is split into key path spend and script path spend.
- The inputs have various multisig and Lightning-related scripts: bare multisig is a 2-of-3, legacy P2SH is a 3-of-5 multisig, wrapped P2WSH is a revoked Lightning HTLC, P2WSH is a revoked Lightning force close (often called "penalty transaction") with an unusually short CSV delay of 42, and P2TR script path is a 5-of-7 multisig (continuing the prime number pattern, and also a reference to the "5/7" meme).
- The input amounts have special meaning: 6102 is a reference to Executive Order 6102, 1913 is the year the Fed was created, 1971 is the year the USA abandoned the gold standard, 2140 is the year the last halving is expected to occur and the block subsidy to go to zero, 5139 refers to CVE-2010-5139 (value overflow incident), 3220 refers to CVE-2013-3220 (March 2013 accidental fork), 17144 refers to CVE-2018-17144 (never exploited inflation bug), 8149 is the Bitcoin Core pull request that implemented SegWit, 9001 is a reference to the "It's over 9000!" meme, and 19953 is the Bitcoin Core pull request that implemented Taproot.
- The output amounts demonstrate the dust limit of each output type: 576 for compressed P2PK, 546 for P2PKH, 582 for 1-of-1 compressed bare multisig, 540 for P2SH, 294 for a 20-byte SegWit output (P2WPKH), 330 for a 32-byte SegWit output (P2WSH and P2TR), 240 for a 2-byte SegWit output, and 0 for OP_RETURN.
- The input sequence numbers have special meaning: 20090103 refers to the date in the genesis block, 20081031 refers to the publication date of the white paper, 19750504 refers to Satoshi's self-reported birthday, 16 refers to BIP-16 (P2SH), 141 refers to BIP-141 (SegWit), 0xdeadbeef is a well-known magic number (used here to comment on the 80-bit security of wrapped P2WSH), 21000000 is the number we all know and love, 0xf9beb4d9 is the magic number used in the Bitcoin P2P protocol, 341 refers to BIP-341 (Taproot), and 342 refers to BIP-342 (Tapscript).
- The transaction uses DER-encoded ECDSA signatures of lengths 71, 70, 69, 68, 67, 66, 65, 59, 58 and 57. Signatures are normally 71 or 72 bytes long, but can be made shorter with repeated signing attempts; this is called "signature grinding". The last three are especially short because they use [a known short r-value specific to the secp256k1 curve](https://crypto.stackexchange.com/a/76010).
- The transaction uses every possible sighash flag: SIGHASH_DEFAULT, SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ALL | SIGHASH_ANYONECANPAY, SIGHASH_NONE | SIGHASH_ANYONECANPAY, and SIGHASH_SINGLE | SIGHASH_ANYONECANPAY.
- The OP_RETURN output includes the push opcodes for numbers 0 to 16 after its initial text push. Multiple pushes don't violate any standardness rules, as long as the output as a whole stays under the size limit.
- The transaction uses uncompressed keys in multiple inputs, and unusually mixes compressed and uncompressed keys within multisig scripts.
- In the P2MS and legacy P2SH inputs, the unused multisig keys are the genesis block coinbase key, block 9 coinbase key, and Hal Finney's key used in [the first ever Bitcoin transaction](https://mempool.space/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16#vin=0). The two unused keys in the P2TR script path multisig are the two vanity keys from [the first ever P2TR script path transaction](https://mempool.space/tx/37777defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8). The internal key in the P2TR script path is the SHA-256 hash of the white paper. Finally, the 20-byte hash in the HTLC script corresponds to the address 17TASsYPbdLrJo3UDxFfCMu5GXmxFwVZSW used in the 2010 value overflow incident, where the 0.5 BTC used in the attack remains unspent to this day.
- The P2TR script path input has a Merkle tree of depth 21, much more than any before it (the previous record was 7). The Merkle branch steps revealed in the control block are not just random hashes, but are the TXIDs of 21 transactions significant to Bitcoin's history:

	- 2009-01-03 Genesis block coinbase transaction:  
	  4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
	- 2009-01-12 First non-coinbase transaction (from Satoshi to Hal):  
	  f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
	- 2009-01-16 First transaction sending to P2PKH:  
	  6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516
	- 2010-05-22 Laszlo Hanyecz's 10,000 BTC pizza transaction:  
	  a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
	- 2010-11-14 First duplicate transaction (BIP-30 violation #1):  
	  d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
	- 2010-11-15 Second duplicate transaction (BIP-30 violation #2):  
	  e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468
	- 2011-11-16 Largest amount ever sent in one transaction (550,000 BTC):  
	  29a3efd3ef04f9153d47a990bd7b048a4b2d213daaa5fb8ed670fb85f13bdbcf
	- 2013-04-06 Transaction that contains the entire white paper:  
	  54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713
	- 2013-11-05 Rickroll transaction:  
	  d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b
	- 2015-07-07 F2Pool's "Megatransaction" that took 25 seconds to verify (see [blog post by Rusty Russell](http://rusty.ozlabs.org/2015/07/08/the-megatransaction-why-does-it-take-25-seconds.html)):  
	  bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 
	- 2015-07-11 Similar transaction by F2Pool made in collaboration with Greg Maxwell that uses the SIGHASH_SINGLE bug to be easy to verify and the short r-value trick for smaller signatures:  
	  9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
	- 2016-04-26 Highest fee ever paid (291 BTC):  
	  cc455ae816e6cdafdb58d54e35d4f46d860047458eacf1c7405dc634631c570d
	- 2017-02-23 SHA-1 collision bounty claimed:  
	  8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
	- 2017-08-24 First SegWit spending transaction:  
	  8f907925d2ebe48765103e6845c06f1f2bb77c6adc1cc002865865eb5cfd5c1c
	- 2021-07-23 0xB10C's anyone-can-spend P2TR transaction (see https://b10c.me/7):  
	  b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41
	- 2021-11-14 First Taproot spending transaction:  
	  33e794d097969002ee05d336686fc03c9e15a597c1b9827669460fac98799036
	- 2021-11-14 First Taproot script path transaction:  
	  37777defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8
	- 2021-12-07 Chun's 1 BTC donation to Luke Dashjr with a 8999 BTC change output:  
	  fd456524104a6674693c29946543f8a0befccce5a352bda55ec8559fc630f5f3
	- 2022-10-09 Burak's 998-of-999 multisig that broke LND:  
	  7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73
	- 2022-11-01 Burak's second transaction that broke LND:  
	  73be398c4bdc43709db7398106609eea2a7841aaf3a4fa2000dc18184faa2a7e
	- 2023-11-23 Highest fiat-denomiated fee ever paid (86 BTC or $3.13M):  
	  b5a2af5845a8d3796308ff9840e567b14cf6bb158ff26c999e6f9a1f5448f9aa

This project took me over a year to complete. Initially it was just meant to be a transaction with every input and output type, serving as a reference transaction for comparing features of blockchain explorers, but as I got more and more ideas the complexity eventually exploded into what you see here. I learned so much, not just about the Bitcoin protocol but also Bitcoin's history. I wrote the code that generated this transaction in TypeScript using BitcoinJS; a few performance-sensitive parts were later rewritten in Rust, a language I had to learn for this purpose.

Shoutout to mononaut for [being the first to notice the transaction](https://x.com/mononautical/status/1807189726501499268) a mere few hours after it was created, and for being the first to notice the significance of its TXID. Next, shoutout to Super Testnet for writing a [Stacker News post](https://stacker.news/items/593226) detailing every Easter egg known at the time and being the first to notice many of them. Finally, shoutout to these people who also found Easter eggs: Sebastian Falbesoner, Rob Hamilton, Tom Honzik, iWarp, Jiří Jakeš, Portland.HODL, pycan, Gregory Sanders, Tomer Strolight, and Peter Todd.

Many thanks to the Bitcoin developer community, Bitcoin technical writers, and people who answer questions at Bitcoin Stack Exchange. This project could never happen without them. Many thanks also to people who had words of appreciation about the transaction, it means a lot.

If you have any questions, I'll be more than happy to answer them. If they are of the kind that could be answered by other people, please consider posting them to Bitcoin Stack Exchange where they will be more likely to help future readers.

sp1qqv0ytnsv52xk2wpkde6efxusndhk3dvqdt3t7g60qx5pp7yjwk2yqqnscz2fwsnq6067xcy2q7pjjarch6uj9xpuzcfs3cx5up9mcfuyuvf3gel5

@vostrnad's bio

On mempool.space, you need to click the "Details" button which reveals more details about each input and output. These 17 numbers can be seen in the decoded output script ("ScriptPubKey").

That would require a different layout of inputs/outputs, since the only input with index higher than all outputs is a P2TR input, and the sighash_single bug is fixed in Taproot.