If you've been on Twitter or Stacker News last week, you may have seen this strange Bitcoin transaction:
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.
  • 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. The two unused keys in the P2TR script path multisig are the two vanity keys from the first ever P2TR script path transaction. 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):
      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 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 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.
177 sats \ 1 reply \ @petertodd 7 Jul
Probably the most sophisticated Easter egg to have ever been added to the blockchain.
It certainly beats me rick-rolling testnet!
reply
Everyone loves a good Rick roll though.
reply
110 sats \ 7 replies \ @pycan 7 Jul
Mad respect, well done!!
Any chance to make the code public?
reply
Sure! It might take a bit of work to clean up, but if people are interested then I'll do it.
reply
reply
Amazing thanks!!
reply
Yes please! This code can be extremely valuable both historically and academically.
reply
100 sats \ 0 replies \ @pycan 7 Jul
I've just built my first raw transaction yesterday (here's the code) and learned a ton (also learning Rust as TS dev :) ). A chance to have a sneak peak into yours would be tremendous! Thank you.
reply
0 sats \ 1 reply \ @pycan 7 Jul
I'd also be very interested in those performance sensitive parts that had to be written in Rust. After all, I'd expect putting together bunch of bytes isn't that performance sensitive.
reply
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.
reply
How did you learn to do this?
reply
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.
reply
37 sats \ 0 replies \ @kruw 8 Jul
This may be the literal coolest thing ever.
reply
🤯
reply
Very cool. Thanks for breaking it down for us.
reply
Incredible. And now it will be recorded forever.
reply
A lot of hidden lore in this one! One of the things I love about the Bitcoin community are these subtle nods to significant historical economic events. Great detective work here
reply
alot of nerds will jerks on this, simply well done !
reply
Absolutely epic and mind blowing transaction. One for the history books. Most transactions simply move value from one id to another, but you have exposed the full suite of tools available and filled it with Bitcoin lore on top of that. Satoshi would be proud.
reply
10 sats \ 0 replies \ @delta1 8 Jul
this is absolutely incredible 👏
well done! amazing proof of work.
reply
Thank you. This is so fascinating
reply
reply
Amazing! You've achieved something great!
Much Respect!!
reply
10 sats \ 1 reply \ @tomh 7 Jul
Awesome transaction and breakdown. You mentioned the block 9 coinbase key, is there anything special about block 9 in particular?
reply
Yes, the first ever transaction from Satoshi to Hal used the block 9 coinbase reward. A certain fraudster also claimed to have this key in possession.
reply
Skvělá práce. Great job.
reply
10 sats \ 0 replies \ @Fabs 7 Jul
Damn, I'm impressed, you absolutely nailed it!
reply
fun facts
reply
I understood the word "transaction"
reply
Bravo
reply
0 sats \ 0 replies \ @OT 7 Jul
That's an interesting way to spend your time. It looks like the possibilities of using Bitcoin are just getting started
reply
Why was this transaction relayed by nodes as a standard tx?
reply
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.
reply
Isn't it non-standard to use uncompressed keys in inputs?
reply
Only in SegWit, they're standard in legacy scripts. There also exist "hybrid keys" that are non-standard everywhere.
reply
impressive!
reply
deleted by author
deleted by author