At least 14(!) unique public addresses from one single seed (0 derivation paths)

[BTCW]

Do you agree that a not-uncommon Bitcoin discussion goes along the lines:

"Remember that one private key controls two public addresses, the uncompressed and the compressed." Next, someone smart-ass says, "You're forgetting nested and native segwit - it's four addresses, guys."

What about newer stuff like Taproot? What about crazy things like 1-of-1-multisig? What about older formats like P2K and P2MS that no one has used in years but would still be accepted by the network?

I decided to give it a shot.

The overall goal here is to show how many unique public addresses are actually derived from one single seed, using no "HD Wallet wizardry" with optional additional keyphrases and derivation paths. I decided no input other than the "bad_seed" string is allowed; absolutely no mnemonic phrases or derivations paths from BIPs.

By the way, I call the only input "seed" rather than password/passphrase, and I define a seed to be a 64-character hexadecimal number, such as

Code:

0000000000000000000000000000000000000000000000000000000000000001

because it can then be interpreted as 32 bytes or as a script. (This example wouldn't run as a script, but that's a separate story).

For this project, I've experimented with Python and cross-verified outputs with online services as needed, but I thought my actual code was of limited interest. If you, against all odds, wanna take a look at my scripts, say when.

Back to the title subject. From the seed, I can begin with deriving:

Code:

[[[OUTPUTS]]]

Master root XPRV:
xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21TeqtDeZVxb

Uncompressed public key:                                    0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
Compressed public key:                                      0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Uncompressed RIPEMD160 a.k.a. HASH160:                      91b24bf9f5288532960ac687abb035127b1d28a5
Compressed RIPEMD160 a.k.a. HASH160:                        751e76e8199196d454941c45d1b3a323f1433bd6


Private keys
~~~~~~~~~~~~

Uncompressed (WIF):                                         5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf
Compressed (WIF):                                           KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn

Nothing special so far, except maybe my XPRV experiment.

But how about this? I've never found anything online that is this extensive (and way too many examples on Github that do bits and pieces of it).

Code:

Public addresses
~~~~~~~~~~~

Public script - rare but valid (P2S)**                      0000000000000000000000000000000000000000000000000000000000000001
Old 1-of-1 multisig uncompressed - rare but valid (P2MS):   51410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b851ae
Old 1-of-1 multisig compressed - rare but valid (P2MS):     51210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179851ae
Uncompressed public key - rare but valid (P2PK):            0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
Compressed public key - rare but valid (P2PK):              0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Uncompressed legacy public key (P2PKH):                     1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
Compressed legacy public key (P2PKH):                       1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH
Nested SegWit public address (P2WPKH-P2SH):                 3JvL6Ymt8MVWiCNHC7oWU6nLeHNJKLZGLN
Nested SegWit script public address (P2SH)**:               3D24NWLpGxY9x8WZYpvowwyNPyZyN7aRNB
New 1-of-1 multisig uncompressed - weird (P2SH):            33RjLdp9usumz3BNqa5PB9umJZjiw7kmjK
New 1-of-1 multisig compressed - weird (P2SH):              3DicS6C8JZm59RsrgXr56iVHzYdQngiehV
Native SegWit public address (P2WPKH):                      bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
Native Segwit public address (P2WSH)**:                     bc1qa3y3dhfgl3xpp4uw9p72tkwv28hp4eeuhl0q334nwvjvh74v30zs5faqjp
Taproot public address (P2TR):                              bc1pmfr3p9j00pfxjh0zmgp99y8zftmd3s5pmedqhyptwy6lm87hf5sspknck9

[Those marked with ** require the underlying script to be executbale, or the address is unspendable.]

My comments:

I thought I'd take it from the beginning and in chronological order of appearance from 2009 until today.

Pay-to-script (P2S) has, to the best of my knowledge, always been allowed, but there are few examples from the past decade. Paying to the script used in this example but be advised against; it is probably not spendable.

The same goes for early-day multi-signature addresses, for which you had to write the public key(s) in clear text (P2MS). As far as I understand, they are still legal but very scarce. The special case of 1-of-1 was probably never an intended feature - it makes little sense - but they weren't disallowed back then, and they are still accepted today. We can write one each for the uncompressed and the compressed public keys, respectively.

Then, we have the two legacy addresses that reigned for many years (especially the compressed ones).

First among the "3-addresses" is one with many names. I like "nested Segwit" best, but if you prefer P2WPKH-P2SH, I'm cool.

Next in line is "Nested SegWit script public address (P2SH)**" - and I would like you to suggest a better name. The code I use to construct them is:

Code:

base58.b58encode_check(bytes.fromhex('05'+ hashlib.new('ripemd160', hashlib.sha256(bytes.fromhex(bad_seed)).digest()).hexdigest())).decode()

They are, I think, only good if the corresponding script is good (and I strongly suspect "bad_seed" will not pass as a valid Bitcoin Script).

Then we have these weird 1-of-1 multi-sig transactions again. Take a look at this link collection about "Crazy1to1" and good luck getting any wiser! In any case, we can easily create two 1-of-1 multi-sig addresses, one for the uncompressed public key and one for the compressed ditto, and wrap them up in P2SH containers.

Native Segwit, or shall we call them "bc1"-addresses shouldn't surprise anyone. At least not the first. The second one, which I call "(P2WSH)**", is just me using the seed as a script again; hence, 32 instead of 20 bytes and a longer address. In honor of full transparency, I think the address format is correct, but since "bad_seed" isn't a real script, I doubt the address is spendable.

The last one is "just" a regular Taproot. It is also the format that I know the least about. I am struggling with theory in combination with super-enthusiastic Youtubers, but it is still to little avail - I am not sure I get "it" when it comes to Taproot/bc1p and how it changes the world for the better. Is it possible to make Taproot variations without introducing arbitrary extra code? I take pride in that all the above are derived from one single seed and that anyone who reproduces parts or all of them should get the same public addresses.

I am super excited about your feedback! Did I leave anything obvious out? Did I make any mistakes, big or small? In other words, what should I correct? Have others derived more than 14 public addresses from one hardcoded seed in a deterministic and reproducible manner? Should I make public my Python script?

For good measure, iteration 2 yields:

Code:

[[[INPUT]]]]                                                [[[We treat this single input a private key OR a script (HEX)]]]

Bad seed:                                                   0000000000000000000000000000000000000000000000000000000000000002

[[[OUTPUTS]]]

Master root XPRV:
xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21TeqtEE6Pxo

Uncompressed public key:                                    04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee51ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a
Compressed public key:                                      02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
Uncompressed RIPEMD160 a.k.a. HASH160:                      d6c8e828c1eca1bba065e1b83e1dc2a36e387a42
Compressed RIPEMD160 a.k.a. HASH160:                        06afd46bcdfd22ef94ac122aa11f241244a37ecc


Private keys
~~~~~~~~~~~~

Uncompressed (WIF):                                         5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAvUcVfH
Compressed (WIF):                                           KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74NMTptX4

Public addresses
~~~~~~~~~~~

Public script - rare but valid (P2S)**                      0000000000000000000000000000000000000000000000000000000000000002
Old 1-of-1 multisig uncompressed - rare but valid (P2MS):   514104c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee51ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a51ae
Old 1-of-1 multisig compressed - rare but valid (P2MS):     512102c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee551ae
Uncompressed public key - rare but valid (P2PK):            0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
Compressed public key - rare but valid (P2PK):              0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Uncompressed legacy public key (P2PKH):                     1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m
Compressed legacy public key (P2PKH):                       1cMh228HTCiwS8ZsaakH8A8wze1JR5ZsP
Nested SegWit public address (P2WPKH-P2SH):                 3FWHHE3RVgyv5vYmMrcoRdA25uugWvQbso
Nested SegWit script public address (P2SH)**:               3CNVyupnE7C8FMCv9vPWSpriuVQZVt6Fzh
New 1-of-1 multisig uncompressed - weird (P2SH):            3G1kW5oNxKs2whEgi6cwVy5KEoAqkwuGHr
New 1-of-1 multisig compressed - weird (P2SH):              32KTvowh8quz8eFfxgX98QJUdUGgryn28R
Native SegWit public address (P2WPKH):                      bc1qq6hag67dl53wl99vzg42z8eyzfz2xlkvxechjp
Native Segwit public address (P2WSH)**:                     bc1qjfna8kldsq55zjplrtaz567x3hjlv5cj3t9fhu2xr3ws5wkndmfqhhl956
Taproot public address (P2TR):                              bc1pet7ep3czdu9k4wvdlz2fp5p8x2yp7t6ttyqg2c6cmh0lgeuu9lasmp9hsg

[Those marked with ** require the underlying script to be executable, or the address is unspendable.]

[runlola]

Can you link to or show how these addresses are constructed/derived?

[vjudeu]

Public script - rare but valid (P2S)**

Code:

decodescript 0000000000000000000000000000000000000000000000000000000000000001
{
  "asm": "0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [error]",
  "desc": "raw(0000000000000000000000000000000000000000000000000000000000000001)#mwhr8r2w",
  "type": "nonstandard"
}

Well, I don't know exactly, what do you mean here by "P2S": do you want to push just some 32 bytes on a stack, and get it evaluated as OP_TRUE or what? Because by just taking raw 32 bytes, without any OP_PUSH, it will be invalid in a lot of cases.

Also, if you use P2PK, then you have to add OP_CHECKSIG (0xac) at the end, in other cases, every miner can move those coins, without any signatures.

Did I leave anything obvious out?

Very far from obvious, but possible: Pay to Proof of Work: https://mempool.space/testnet4/address/tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d

Code:

decodescript 82013c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
  "asm": "OP_SIZE 60 OP_LESSTHAN OP_VERIFY 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
  "desc": "raw(82013c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#y8swm8mh",
  "type": "nonstandard",
  "p2sh": "2N794vgkX9KyJqfFPtqB1jTUx7QwvZgurZr",
  "segwit": {
    "asm": "0 14253cba80c4fd4cd7006c31a195874c894cce1d9e01b62bea99d4178289a2ff",
    "desc": "addr(tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d)#swj9w4n7",
    "hex": "002014253cba80c4fd4cd7006c31a195874c894cce1d9e01b62bea99d4178289a2ff",
    "address": "tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N9LCwnfvYcCCtapo2E3hcTr1SqStuJTuMo"
  }
}

It is standard, if you wrap it in P2WSH. And it requires revealing the private key, by producing a weak, small signature.

Have others derived more than 14 public addresses from one hardcoded seed in a deterministic and reproducible manner?

Let's see:

Code:

decodescript 5175210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
  "asm": "1 OP_DROP 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
  "desc": "raw(5175210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#0q96kq66",
  "type": "nonstandard",
  "p2sh": "2NDwf2Xr6UMZGaA6DuiiS1EuiPyijQnXNe5",
  "segwit": {
    "asm": "0 ca52abb47d6f4f2902fff048bf23893199c75366a87d7e2e620e51784a8537ad",
    "desc": "addr(tb1qeff2hdrada8jjqhl7pyt7gufxxvuw5mx4p7hutnzpeghsj59x7ksxtfxl8)#kyrsneam",
    "hex": "0020ca52abb47d6f4f2902fff048bf23893199c75366a87d7e2e620e51784a8537ad",
    "address": "tb1qeff2hdrada8jjqhl7pyt7gufxxvuw5mx4p7hutnzpeghsj59x7ksxtfxl8",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2NGUcprCu3pFZJnoPDJQHrV7qCWm86xS4S9"
  }
}
decodescript 5275210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
  "asm": "2 OP_DROP 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
  "desc": "raw(5275210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#4tk04hgg",
  "type": "nonstandard",
  "p2sh": "2MtBVYdKqsstfHygZorDJLiSUdqZ58XQKUh",
  "segwit": {
    "asm": "0 55c1c0569af0d71601529746b54ccea971ae6d07a37dc7eea477b22d5ddb053f",
    "desc": "addr(tb1q2hquq4567rt3vq2jjart2nxw49c6umg85d7u0m4yw7ez6hwmq5lsk7rjl8)#y4p7699h",
    "hex": "002055c1c0569af0d71601529746b54ccea971ae6d07a37dc7eea477b22d5ddb053f",
    "address": "tb1q2hquq4567rt3vq2jjart2nxw49c6umg85d7u0m4yw7ez6hwmq5lsk7rjl8",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2NCF2rsgKqiGfmVnfx4DikFvMu7Y5N9DKvF"
  }
}
decodescript 5375210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
  "asm": "3 OP_DROP 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
  "desc": "raw(5375210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#y4qm56xx",
  "type": "nonstandard",
  "p2sh": "2MvUnmTgKHTN67dZixCQVEs9yZSh1qvhqeS",
  "segwit": {
    "asm": "0 958db9e12de412d684148259e392333f7157fe18cfeb4b53aacc2cbc41d49e62",
    "desc": "addr(tb1qjkxmncfdusfddpq5sfv78y3n8ac40lscel45k5a2esktcsw5ne3qxwz09x)#aacfhc34",
    "hex": "0020958db9e12de412d684148259e392333f7157fe18cfeb4b53aacc2cbc41d49e62",
    "address": "tb1qjkxmncfdusfddpq5sfv78y3n8ac40lscel45k5a2esktcsw5ne3qxwz09x",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N2fQz3cw8Asf1PeBJkNdmG77Eig4o5Etfg"
  }
}
...

As you can see, by using "<someData> OP_DROP <pubkey> OP_CHECKSIG", from a single public key, you can produce a lot of addresses. But if they won't be wrapped in P2WSH or P2TR, then they would be probably non-standard, if used as P2SH, or raw scripts.

Also, if someone would protest, that "those stack pushes are ignored", then it can be replaced with OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY, and then it will produce a different address for each locktime.

how these addresses are constructed/derived?

First, start from this page: https://en.bitcoin.it/Script

You have the list of opcodes there. Then, you can craft anything, by typing some hex numbers, and then decode your Script with Bitcoin Core:

Code:

decodescript 5252935487
{
  "asm": "2 2 OP_ADD 4 OP_EQUAL",
  "desc": "raw(5252935487)#hfghpu9a",
  "type": "nonstandard",
  "p2sh": "2NEYLKEvXeoUkbgT1d4Q6oWbwqGYXKiDv7w",
  "segwit": {
    "asm": "0 c0858cc028681baa9fbf976f719d95e3eedef5066662a5ec1ee57cf9f62ce38c",
    "desc": "addr(tb1qczzcespgdqd648aljahhr8v4u0hdaagxve32tmq7u470na3vuwxqlqgg9a)#yu7zmzve",
    "hex": "0020c0858cc028681baa9fbf976f719d95e3eedef5066662a5ec1ee57cf9f62ce38c",
    "address": "tb1qczzcespgdqd648aljahhr8v4u0hdaagxve32tmq7u470na3vuwxqlqgg9a",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2NCMxv8zDoXAhjvxzxXCjdxnoQTR9MgryB3"
  }
}

Many things are possible. For example, you can require solving some math puzzle, and providing a valid signature for a given public key. And it will produce yet another address. So, for the generator of ECDSA, it could be:

Code:

decodescript 012201239388210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
  "asm": "34 35 OP_ADD OP_EQUALVERIFY 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
  "desc": "raw(012201239388210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#2wqyxgrx",
  "type": "nonstandard",
  "p2sh": "2NDYdXkA5ETeeQiKN62t3igAjuPtceKtPPC",
  "segwit": {
    "asm": "0 c39474cba9c940725653b035e62bd48d4f1266199c6ae119cce010d41f23589f",
    "desc": "addr(tb1qcw28fjafe9q8y4jnkq67v2753483yesen34wzxwvuqgdg8ertz0s5ls2q5)#4lquc6kr",
    "hex": "0020c39474cba9c940725653b035e62bd48d4f1266199c6ae119cce010d41f23589f",
    "address": "tb1qcw28fjafe9q8y4jnkq67v2753483yesen34wzxwvuqgdg8ertz0s5ls2q5",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N16wdbG6GzB5Wa1kxCY264ZtERAv6xPj4h"
  }
}

See? Yet another address. There are a lot of possibilities, if you want to think about all P2WSH combinations, there are probably enough, to collide with every other address, which would use some other public key.

[seoincorporation]

Something that is awesome from my point of view is the fact that all those address:

Code:

Public script - rare but valid (P2S)**                      0000000000000000000000000000000000000000000000000000000000000001
Old 1-of-1 multisig uncompressed - rare but valid (P2MS):   51410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b851ae
Old 1-of-1 multisig compressed - rare but valid (P2MS):     51210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179851ae
Uncompressed public key - rare but valid (P2PK):            0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
Compressed public key - rare but valid (P2PK):              0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Uncompressed legacy public key (P2PKH):                     1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
Compressed legacy public key (P2PKH):                       1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH
Nested SegWit public address (P2WPKH-P2SH):                 3JvL6Ymt8MVWiCNHC7oWU6nLeHNJKLZGLN
Nested SegWit script public address (P2SH)**:               3D24NWLpGxY9x8WZYpvowwyNPyZyN7aRNB
New 1-of-1 multisig uncompressed - weird (P2SH):            33RjLdp9usumz3BNqa5PB9umJZjiw7kmjK
New 1-of-1 multisig compressed - weird (P2SH):              3DicS6C8JZm59RsrgXr56iVHzYdQngiehV
Native SegWit public address (P2WPKH):                      bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
Native Segwit public address (P2WSH)**:                     bc1qa3y3dhfgl3xpp4uw9p72tkwv28hp4eeuhl0q334nwvjvh74v30zs5faqjp
Taproot public address (P2TR):                              bc1pmfr3p9j00pfxjh0zmgp99y8zftmd3s5pmedqhyptwy6lm87hf5sspknck9

Have the same Compressed RIPEMD160 a.k.a. HASH160:

Code:

751e76e8199196d454941c45d1b3a323f1433bd6

And the awesome part of it is the limit that we have came from that sha, and not from the public script.

The rank of address can be considered from RIPEMD160:

0000000000000000000000000000000000000000 (1111111111111111111114oLvT2)

To:
ffffffffffffffffffffffffffffffffffffffff (1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr)

Sadly with the RIPEMD160 we can't get the privatekey, only the multiple kinds of addresses. But is something cool to know and we are talking about 16^40 total addresses of each kind.

[achow101]

Did I leave anything obvious out?

Yes.

Off the top of my head, P2PK and P2PKH can both be nested within P2SH, P2WSH, and P2TR. Segwit (native and nested) allows uncompresed pubkeys by consensus, although not by standardness. In Taproot, the pubkey can be the output key directly, or the internal key.

Additionally, Taproot can include any script as well.

Another wrench is that there's actually a third kind of pubkey called hybrid pubkeys that you can use in a bunch of places. They're basically uncompressed pubkeys but also indicate parity in the first byte like compressed pubkeys do.

Within P2SH, P2WSH, and P2TR, you can construct basically infinitely many scripts that all boil down to a single key check. The basics would just be inserting OP_NOPs, but you can go crazy with all of the other opcodes and construct scripts that basically do nothing.

[NotATether]

Can you link to or show how these addresses are constructed/derived?

The compressed/uncompressed legacy addresses and the compressed segwit address are generated traditionally. I *think* the P2TR generation is similar to P2WPKH but with Bech32m instead of Bech32.

The P2PK scripts are just the legacy addresses without the HASH160 step.

The P2PKH-P2SH addresses have a guide here: https://bitcointalk.org/index.php?topic=5249246.0 , by the same OP.

The others I'm not very familiar with, except for old P2SH multisigs that uses the OP_CHECKMULTISIG opcode to make a script hash.

[satscraper]

The new 28.0 release has got us the new script, namely P2A and ^{(in line with it)} the new addresses which will look like  bc1pfeessrawgf

The transaction with such kind of addresses can be already found,  for instance these ones ^{(thanks to amaclin1 who found it)} though they will be limited in number until sufficient number of nodes will be able to support their propagation

[garlonicon]

the new addresses which will look like bc1pfeessrawgf

1. It is keyless.
2. There will be only this single new address.
3. Testnet4 faucets use it: https://mempool.space/testnet4/address/tb1pfees9rn5nz