Ever notice how Bitcoin chats often go like this?
"Hey, one private key gives you two public addresses: uncompressed and compressed." Then, someone chimes in, "Don't forget about nested and native segwit that makes it four!"
But what about the latest things like Taproot? Or the wild ideas like 1-of-1-multisig? Let's not ignore old formats like P2K and P2MS that are practically dead but still recognized by the network.
I thought I’d put this to the test.
My main goal here is to show just how many unique public addresses can come from a single seed, without resorting to any HD wallet tricks or optional keyphrases and derivation paths. I’m keeping it simple: the only input will be the "bad_seed" string; no mnemonic phrases or BIP paths allowed.
I prefer to call this input a "seed" rather than a password or passphrase, and I see a seed as a 64-character hexadecimal number, which can be understood as 32 bytes or a script. (This particular example wouldn’t execute as a script, but that’s a whole different discussion).
For this project, I’ve played around with Python and checked my outputs against some online tools, but honestly, my actual code isn’t that exciting. If you’re curious and wanna see my scripts, just let me know.
So, back to the main point. From this seed, I can start generating:
So far, nothing groundbreaking, except maybe my XPRV experiment.
But how about this? I’ve yet to find anything out there that’s as comprehensive (and way too many GitHub examples that do bits of this)!
14 unique public addresses generated from a single seed without derivation paths
8 replies 210 views
Can you link to or show how these addresses are constructed/derived?
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.
Very far from obvious, but possible: Pay to Proof of Work: https://mempool.space/testnet4/address/tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d
It is standard, if you wrap it in P2WSH. And it requires revealing the private key, by producing a weak, small signature.
Let's see:
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.
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:
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:
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.
HumbleBullFull Member
Posts: 54 · Reputation: 378
#4Dec 24, 2017, 01:26 PM
Something that is awesome from my point of view is the fact that all those address:
Have the same Compressed RIPEMD160 a.k.a. HASH160:
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.
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.
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.
silentchainHero Member
Posts: 473 · Reputation: 2317
#7Dec 26, 2017, 09:08 AM
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
1. It is keyless.
2. There will be only this single new address.
3. Testnet4 faucets use it: https://mempool.space/testnet4/address/tb1pfees9rn5nz
Is there any wallet that can easily sweep 1-of-1 multisigs? Electrum doesn't, nor does it support taproot. If we need to use bitcoin core rpc calls, it would be nice if we could have a list of the required commands to make it scriptable.
Related topics
- Erlay seems to have some issues here’s a better proposal for a bitcoin protocol without invites 3
- How does Bitcoin keep inputs unique at the consensus level 0
- Bitcoin Core displaying coins (UTXOs) in a new tab 13
- Are you in favor of BIP-110? Let's get a Bitcoin poll going. 0
- New Optional Hourglass Implementation is Live 3
- Ways to earn some sats by contributing to bitcoin core development 5