About a strange transaction I created

Author: Vojtěch Strnad

Source: https://stacker.news/items/600187

Translator's note: This article introduces a deliberately strange transaction that demonstrates the complexity and flexibility of the Bitcoin protocol itself.

If you’re a regular on Twitter or Stacker News, you might have noticed people discussing a strange Bitcoin transaction that appeared on the mainnet:

https://mempool.space/tx/b10c0000004da5a9d1d9b4ae32e09f0b3e62d21a5cce5428d4ad714fb444eb5d

It attracted a lot of attention, and people were eager to know: Who made this strange deal? What secrets does it hide?

Let me reveal the answers to these two questions.

information:

 Transaction b10c0000004da5a9d1d9b4ae32e09f0b3e62d21a5cce5428d4ad714fb444eb5d was created by Vojtěch Strnad.

address:

 1J7SZJry7CX4zWdH3P8E8UJjZrhcLEjJ39

sign:

 H6WHgwnYtggJH5yqVpeL9NRxWJ+8hqUW31Mc1J9e9Q3cZGEdDjixYT6jnPpIHM2FVHDbeEstP8KzDsj5U01BNSo=

If you want to verify the signature yourself (which I highly recommend), please do not use Bitcoin Core or Electrum on hotel Wi-Fi.

With that out of the way, we’re ready to reveal every Easter egg in this deal. The last two of which, as far as I know, haven’t been noticed by anyone as of this writing:

• The transaction was first confirmed in block 850000.
• The locktime of this transaction is the timestamp of the Bitcoin Genesis Block. (Translator's note: locktime is a method of implementing an absolute time lock at the transaction level; here, it means that the transaction can only be confirmed after the Genesis Block appears.)
• This transaction has a fancy TXID and WTXID. The TXID starts with b10c0000004da5... , which is the personal homepage of Bitcoin developer 0xB10C, who once made a transaction with a similar TXID (see: https://b10c.me/7 ). The WTXID starts with 0000000001d54... , which is a series of zeros, just like the block hash value.
• This transaction uses every possible standard input and output type: P2PK, P2PKH, P2MS (naked multi-signature), P2SH, P2WPKH, P2WSH, P2TR, OP_RETURN, and a 2-byte SegWit v1 output (using a script borrowed from the "temporary anchor" protocol). Some types are used multiple times in inputs: P2SH is split into traditional P2SH, wrapped P2WPKH, and wrapped P2WSH, and P2TR is split into key path spend and script path spend. (Translator's note: In the Bitcoin network, nodes will propagate transactions with certain characteristics by default; and "standard input/output" is one of such characteristics. The type of input/output refers to the "template" of the script used to lock the funds; since different funds are independent of each other, we can apply slightly different verification rules to scripts using different templates, which is the origin of the possibility of Bitcoin soft fork upgrades. The so-called "encapsulated P2WPKH/P2WSH" here is a type of P2SH script specially designed to make it easier for old wallets that do not yet support the segregated witness feature to send funds to the segregated witness script when segregated witness is enabled.)
• There are multiple multi-signature scripts and lightning channel related scripts in the input: the naked multi-signature input uses a 2-of-3 multi-signature setup, the traditional P2SH is a 3-of-5 multi-signature, the wrapped P2WSH is a revoked lightning channel HTLC, the P2WSH is a revoked lightning channel forced closure (commonly called a "penalty transaction") with an unusually short CSV delay (42 blocks), and the P2TR script path uses a 5-of-7 multi-signature (both to continue the prime number pattern and to reference the "5/7" meme). (Translator's note: CSV is a script-level relative time lock).
• The input amounts all have special meanings: 6102 refers to US Executive Order 6102, 1913 is the year the Federal Reserve (Fed) was founded, 1971 is the year the US ended the gold standard, 2010 is the expected last Bitcoin halving (when the block subsidy will drop to 0), 5139 refers to CVE-2010-5139 (Bitcoin numerical overflow vulnerability), 3220 refers to CVE-2013-3220 (an unexpected fork in 2013), 17144 refers to CVE-2018-17144 (an unexploited inflation vulnerability), 8149 refers to the PR number for Bitcoin’s implementation of Segregated Witness, 9001 refers to the “Over 9000!” emoji, and 19953 refers to the PR number for Bitcoin Core’s implementation of Taproot.
• The output amounts show the dust threshold for each output type: P2PK outputs using compressed public keys are 576 satoshis, P2PKH are 546 satoshis, 1-of-1 naked multi-signature outputs using compressed public keys are 582 satoshis, P2SH are 540 satoshis, 20-byte segwit outputs (P2WPKH) are 294 satoshis, 32-byte segwit outputs (P2WSH and P2TR) are 330 satoshis, 2-byte segwit outputs are 240 satoshis, and OP_RETURN is 0 satoshis.
• The sequence numbers entered have special meanings: 20090103 refers to the date the Genesis Block was created, 20081031 refers to the publication date of the white paper, 19750504 refers to Satoshi Nakamoto’s self-revealed date of birth, 16 refers to BIP-16 (P2SH upgrade), 141 refers to BIP-141 (Segregated Witness upgrade), 0xdeadbeef is a well-known magic number (used here as a comment on the 80-bit security of encapsulated P2WSH), 21000000 is a number we all know and love, 0xf9beb4d9 is a magic number used in the Bitcoin P2P protocol, 341 refers to BIP-341 (Taproot upgrade), and 342 refers to BIP-342 (Tapscript).
• The transaction used DER-encoded ECDSA signatures of varying lengths: 71 bytes, 70, 69, 68, 67, 66, 65, 59, 58, and 57. Signatures are typically 71 or 72 bytes long, but shorter signatures can be obtained through repeated attempts; this is called "signature grinding." The last three are particularly short because they use a known short r value on the secp256k1 curve .
• This transaction uses all kinds of sighash tags: 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 after the initial text push contains the push opcodes numbered 0 to 16. Multiple pushes do not break any standard rules, as long as the output size does not exceed the limit.
• Uncompressed public keys are used in multiple inputs, and a mix of compressed and uncompressed public keys are used in multi-signature scripts.
• In P2MS and traditional P2SH inputs, the unused multi-signature public keys are the Genesis Block’s coinbase public key, the coinbase key of block 9, and the public key Hal Finney used in the first Bitcoin transaction ever . The two unused public keys in the P2TR script spend multi-signature device are the two public keys from the first P2TR script spend transaction ever . The inner public key in the P2TR script spend is the SHA-256 hash of the whitepaper. Finally, the 20-byte hash in the HTLC script corresponds to the address 17TASsYPbdLrJo3UDxFfCMu5GXmxFwVZSW, which was used in a numerical overflow vulnerability in 2010, and the 0.5 BTC used in the attack has not been moved since then.
• The P2TR script spend input has a Merkle tree with a depth of 21, which is deeper than any other tree that has ever appeared before (the previous record was 7 layers). The Merkle branch value revealed in the control block is not a random hash value, but the TXID of 21 transactions that have had a significant impact on Bitcoin history:
  • The coinbase transaction of the Genesis Block on 2009-01-03:
    4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
  • 2009-01-12 First non-coinbase transaction (sent from Satoshi to Hal):
    f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
  • 2009-01-16 The first transaction sent to the P2PKH script:
    6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516
  • 2010-05-22 Laszlo Hanyecz's pizza transaction (worth 10,000 BTC):
    a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
  • 2010-11-14 First transaction with overlapping TXID (first exception to BIP-30):
    d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
  • 2010-11-15 First transaction with overlapping TXID (second exception to BIP-30):
    e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468
  • 2011-11-16 The largest Bitcoin transaction to date (550,000 BTC):
    29a3efd3ef04f9153d47a990bd7b048a4b2d213daaa5fb8ed670fb85f13bdbcf
  • 2013-04-06 Transaction containing the complete Bitcoin white paper:
    54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713
  • 2013-11-05 Rickroll Transaction:
    d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b
  • 2015-07-07 F2Pool's "Megatransaction" takes 25 seconds to verify (see blog post by Rusty Russell ):
    bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
  • On 2015-07-11, F2Pool collaborated with Greg Maxwell to create another similar transaction, which used the SIGHASH_SINGLE bug to make it easier to verify, and also used the short r-value trick to get a smaller signature:
    9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
  • 2016-04-26 The single transaction with the highest fee paid so far (291 BTC):
    cc455ae816e6cdafdb58d54e35d4f46d860047458eacf1c7405dc634631c570d
  • 2017-02-23 Transaction for claiming SHA-1 collision bonus:
    8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
  • 2017-08-24 The first segwit spending transaction:
    8f907925d2ebe48765103e6845c06f1f2bb77c6adc1cc002865865eb5cfd5c1c
  • 2021-07-23 0xB10C’s P2TR transaction that anyone can spend (see: https://b10c.me/7 ):
    b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41
  • 2021-11-14 The first Taproot spending transaction:
    33e794d097969002ee05d336686fc03c9e15a597c1b9827669460fac98799036
  • 2021-11-14 The first Taproot script spending transaction:
    37777defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8
  • 2021-12-07 Wang Chun donated 1 BTC to Luke Dashjr (change is 8999 BTC):
    fd456524104a6674693c29946543f8a0befccce5a352bda55ec8559fc630f5f3
  • 2022-10-09 Burak’s 998-of-999 multi-signature spend breaks LND:
    7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73
  • 2022-11-01 Burak breaks LND deal again:
    73be398c4bdc43709db7398106609eea2a7841aaf3a4fa2000dc18184faa2a7e
  • 2023-11-23 Transactions with the highest fees in fiat currency (86 BTC or $3.13 million):
    b5a2af5845a8d3796308ff9840e567b14cf6bb158ff26c999e6f9a1f5448f9aa

The whole project took more than a year to complete. Initially I just wanted to make a transaction with every possible input and output type as a reference transaction to compare the features of various block explorers, but as I had more and more ideas, the complexity gradually exploded and eventually became what you see. I learned a lot, not only about the Bitcoin protocol, but also about the history of Bitcoin. I wrote the code to generate this transaction in TypeScript and BitcoinJS; a few performance-sensitive parts were later written in Rust, which I learned specifically for this purpose.

Thanks to mononaut for being the first to notice my transaction , just a few hours after I created it, and for being the first to notice the significance of its TXID. Then, Super Testnet wrote a Stacker News post listing every Easter egg known at the time (and being the first to spot many of them). Finally, thanks to a few others who also spotted Easter eggs: Sebastian Falbesoner, Rob Hamilton, Tom Honzik, iWarp, Jiří Jakeš, Portland.HODL, pycan, Gregory Sanders, Tomer Strolight, and Peter Todd.

A big thank you to the Bitcoin developer community, Bitcoin technical writers, and the people who answered questions on Bitcoin Stack Exchange. This project would not have been possible without you all. I'm also very grateful to the people who gave their thumbs up to this transaction, it means a lot to me.

If you have any further questions, I'd be happy to answer them. If your question is one that others can answer, please consider posting it on Bitcoin Stack Exchange, where it's more likely to help other readers.

(over)