Analysis of 0xB10C's weird bitcoin transaction

The following is an analysis of this bitcoin transaction: https://mempool.space/tx/b10c0000004da5a9d1d9b4ae32e09f0b3e62d21a5cce5428d4ad714fb444eb5d

That transaction does a lot of interesting things. Here is a partial list:

- it sends money to a non-standard bitcoin address that only contains 2 bytes ("bc1pfeessrawgf") where the standard is for addresses to be 20 bytes long

- that nonstandard address *should* appear on bitcoin explorers as the plain text term "non-standard" but the transaction author knew that mempool.space has a naive/buggy address parser and exploited that to make the address look like a valid-but-incredibly-short segwit address

- the transaction seems to attempt use every form of valid bitcoin input and output type: p2pk (the oldest output type, where you send money directly to someone's public key), legacy (the format widely used from 2010 to 2017 -- also tied for oldest, since Satoshi included this format as a non-default option in bitcoin v0), "bare multisig" where the output is a list of two or more public keys, P2SH multisig where the output is a "hash" of two or more public keys, "nested segwit," "native segwit v0," segwit v1 (i.e. taproot), plus two unusual lightning-related utxos: an in-flight HTLC and a force closure tx

- the input amounts contain several interesting numbers: 6102 is the executive order by which Roosevelt implemented a partial ban on self-custodied gold in the USA, 1913 is the year he did that, 1971 is the year the USA abandoned the gold standard, 2140 is the year bitcoin's block subsidy stops, 5139 refers to the CVE report number of bitcoin's inflation bug from 2010 where someone created billions of bitcoins and the network forked & rolled back to override it, 3220 refers to the CVE report number of one of bitcoin's only hard forks: the berkeley database fork, 17144 refers to the CVE report number of the 2018 "would-be" inflation bug that never got exploited, 8149 refers to the pull request that integrated segwit, 19953 refers to the pull request that integrated schnorr signatures, and I don't know what 9001 refers to, but there was a relatively minor bug in bitcoin core which was fixed in 2016 and had that issue number -- it involved getting a corrupted database if you had pruning enabled in bitcoin core and your pc crashed during initial block download...if it happened you would have to restart from scratch. I suspect 9001 is more likely a reference to the "It's over 9000!" meme from Dragon Ball Z

- the output amounts are the dust limits for bitcoin's various address formats: 576 for p2pk addresses, 540 for legacy addresses, 582 for bare multisig addresses, 546 for p2sh addresses, 294 for segwit v0 "regular addresses," 330 for segwit v0 "script addresses" and segwit v1 "taproot addresses", 240 for the non-standard 2-byte address, and 0 for OP_RETURNs

- the first and third inputs use uncompressed pubkeys, which are unusual in bitcoin because compressed pubkeys are smaller and cheaper (and not valid in segwit addresses)

- the fourth input (p2sh multisig) use a proof-of-work technique called "signature grinding" to produce a valid bitcoin signature that is only 57 bytes long. Normal bitcoin signatures are 73 bytes long (except schnorr signatures, which are shorter). It took the tx author a long time to do that and it was very expensive.

- the various signatures in the transaction use all of bitcoin's six sighash flags: SIGHASH_ALL, SIGHASH_NONE, SIGHASH_ONE, SIGHASH_ALL | ANYONE_CAN_PAY, SIGHASH_NONE | ANYONE_CAN_PAY, and SIGHASH_ONE | ANYONE_CAN_PAY -- and the last input (which is a taproot input) also uses SIGHASH_DEFAULT which was added for taproot and means you do "not" use a sighash flag, which bitcoin (post taproot) now interprets as being equivalent to SIGHASH_ALL (that is the flag most commonly used in bitcoin, and not adding a sighash flag saves you 1 byte, thus slightly lowering tx fees)

- the OP_RETURN output not only pushes text (which is normal) but also pushes all 17 numbers that bitcoin has special opcodes for

- the transaction hash is customized to have the tx author's twitter handle and a bunch of leading zeroes, which is very expensive to do and takes a lot of work