Topic: Is it good? Create different wallet types and addresses by same seed (Read 368 times)

That's actually a pretty good idea to start using Tagged Hashes for ECDSA nonce generation too considering RFC6979 is rather slow and expensive. But you have to slightly modify the algorithm to find a way to be able to generate more than one k in case you want to grind to get low r values to avoid 33 byte r in DER encoding.

Technically you are not selecting a number, you are generating a random number using a random entropy. Considering the output is also 256 bit, there shouldn't be any collisions.

When generating wallets, the secret nonce K can be generated like this:

ECDSA:


b = RandomBytes(256)
k = SHA256_{algorithm/ECDSA}(b)


Schnorr:


b = RandomBytes(256)
k = SHA256_{algorithm/Schnorr}(b)


Where SHA256_abc(x) is a tagged hash, defined in BIP340 as SHA256(SHA256(abc) || SHA256(abc) || SHA256(x)).
This was never made a standard or even recommended, it's just something I have conjenctured just now.

---

Let's be realistic - Nobody's going to make a BIP just for nonces in signature algorithms. But the problem is, nobody has defined the steps for ECDSA signing (well, until I did so but that's a different matter), so as far as ECDSA generation goes, it's the wild west out there.

The solution that is necessary for this is some algorithm that guarrantees a unique number is taken from a set of numbers (which have a high chance of collision).

The above is a mathematical explanation of the problem - or at least I tried to describe it that way.

EDIT: I wrote a blog post about it: https://notatether.com/talk-cryptography/ecdsa-and-schnorr-signatures-from-the-same-private-key/

We also have the problem where same deterministic algorithm used for nonce generation could generate the same k which would leak the private key (eg. signing a message from both P2PKH and P2TR addresses using RFC6979 for nonce generation).
ECDSA:
R = k.G
s = k⁻¹(e + rd) (mod n)
ECSDSA:
R = k.G
s = k + e*d (mod n)

If private key (d) is the same and the nonce (k) is also the same, we already have values for signature (r and s) and the message digest (e) ergo we have two equations with 2 variables (k and d). It is trivial to solve it and find the two values.

I am also curious about this.


Re-reading this with my newly gained Taproot and Schnorr experience, it confounds me at this point: Why is reusing a private key for ECDSA and Schnorr signatures dangerous? I don't see any inherent flaw in Shnorr that'll leak the private key used in conjunction with an ECDSA signature.

Edit: I found this - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018384.html

The TL;DR is basically "nobody constructed a proof that demonstrates that ECDSA signatures cannot be correlated to Schnorr signatures (with different nonces), but also, nobody has been able to show that this is possible".

In other words, ECDSA/Schnorr correlation is an NP-hard problem - it can't be solved in polynomial time, but an answer can be verified to be correct (using some inverse algorithm) in polynomial time.

Can I ask you to elaborate on the risk of using the same private key for both P2TR and other type of a transactions (P2PKH, P2WPKH), please? Is there an exploit that I could examine and experiment with, perhaps?

That's true but technically the derivation paths have a common standard among BIPs that wallets use and in each wallet the path itself is hard-coded and chosen based on the address type so you don't need to remember them as long as the same software is used for both creation and recovery.

Yes, it is trivial to recover the private keys at any arbitrary derivation path, however you need to know which path you are recovering from. There are a very large number of potential paths, and it is not trivial to check all of them.

Pedantic nit-pick, but that derivation path is invalid because the indices at levels 3 and 4 are beyond the valid range (0 - 2³¹ for either hardened or unhardened).

But otherwise I agree. Relying on the luck of someone not generating a specific address type (especially when some software such as Core automatically generates all address types when you import a private key), or making up your own wild derivation path which will be difficult to back up accurately and easy to make a mistake with, are both poor ideas. If you want to hide coins on the same seed phrase, then use one or more complex passphrases, and back these up separately to the seed phrase.

If your seed phrase is physically compromised, you should no longer assume that part of your funds is still relatively safe because you were smart enough to utilize different derivation paths for different purposes. Instead, you should transfer immediately all your remaining coins to addresses associated with a completely different seed phrase. If you insist on using the same seed words for multiple purposes or address types, it is better to use non-standard derivation paths which are not that trivial to determine or brute force. Something like m/44'/0'/643697879697'/365869767365/764668486/... will do the trick, but you should have these non-standard paths properly backed up so that you don't lose yourself access to your coins. If I were you, I would instead utilize passphrases functionality, and, for concrete passphrases, I would have a concrete purpose assigned. Passphrases are more convenient because they are easier to write down, remember and recognize, whereas weird constructs such as derivation schemes are tough to deal with. Alternatively, there is such an interesting solution as deterministic seed phrases, which are described in BIP85. In a nutshell, it is a derivation scheme that allows users to have thousands and thousands of seed phrases deterministically derived from a root seed using specific formula and index. Even if one of these child seeds is compromised, the funds associated with other child seeds stay safe.

Actually one of the ways to brute force seed phrases (like when you are missing 1 or 2 words and don't have any addresses) is to check the derived key against a database of addresses not just one type. It's trivial to turn that database into hashes (eg. hash160 of pubkey and hash160 of wit program 0) to not even care about the type.

P2PKH has been around for a long time and any software that is old enough is already safe. But when they implement P2TR they could introduce this vulnerability without knowing it.

It is trivial to recover all at different derivation paths. Lets say you use P2PKH and P2WPKH, all you have to do is to tell the wallet you used these two (like checking 2 checkboxes in UI) and the wallet simply derives both branches and their respective children in the background.
The complication is in the implementation and balance checking which is not a concern for the end user.

I don't think this is a serious enough risk to warrant different deprivation paths to be used for each address type. If someone is using P2PKH addresses, you could similarly argue that their private keys would be leaked if the implementation is flawed. I think it would be better to use the default path for each address type for the wallet software you are using. This will make it simpler to recover your private key from the seed if you need to access your keys from a backup, which is a more realistic problem.

Reading the discussion in this thread prompted some thoughts.

As already mentioned, it is technically possible to implement the creation of several addresses of various types from one seed-phrase. After all, this is a great way (really?) for safe storage of crypto. From one seed-phrase we create an address type1 (of your choice) to which you will transfer a small amount of bitcoin. From the same seed-phrase, we create a type2 address (possibly obsolete or rarely used) to store the bulk of cryptocurrency. Even if seed-phrase is compromised in any way, only a small part of BTC will be lost. This method will even allow to protect yourself from physical compromise seed-phrase. It is unlikely that anyone will guess to check all types of addresses. The attacker will find seed-phrase, gain access to the wallet using this and see a small amount of crypto. Of course, he will transfer this to himself and forget this seed, deciding that he got exactly what he wanted.

What can you say about it?

Like the first comment said, I don't think there is any issue with this practice from a technical aspect, there was a time I was using mycelium Bitcoin wallet, I imported my old Bitcoin keys to the wallet and after the operation was successful, i got my wallet, and I also discovered I have three different address types which consist of a
Legacy address(P2PKH) which starts with the number "1"
Native Segwit address which starts with " bc1q"
Pay to Script Hash (P2SH) which starts with the number "3"
I found this feature very helpful and convenient at the time, I don't know if this feature is still available on the wallet cus its been long I used the Mycelium wallet brand last.

There is hardly a reason to use Legacy addresses anymore - they are unofficially "deprecated" by the grassroots community (they have not been deprecated on an official level), and a Nested Segwit address should only be used if the receiver tells you they can't send funds to one of the newer addresses for technical reasons.

That depends on the software. For example if you use bitcoin core, because it is implemented properly and by competent developers then you are fine but if you are using some other implementation that is done by incompetent developers (like blockchain.com) then you are never fine regardless of what you do.

That's correct.

If it is a risk to use a same software to create different address types, that software is not safe.

I understand like a protection of my private key depends on me and a wallet software I use.

Mycelium offers this in the wallet (for Android - I use it to check balances from my trezor) - their adverts are shady though as a prewarning. They only do legacy, nested segwit and native segwit so far but import them as being one wallet with one balance.

If you read my comment again I used two big "ifs" there that should be correct at the same time. That is normal in cryptography. If you use cryptography the way it is supposed to then you are safe; if not you are not safe!

First big IF is if you use the same private key for a P2TR (Schnorr signature) and any of the older addresses using ECDSA.
Second big IF is if the implementation of Schnorr is flawed so that it uses the same nonce generation algorithm used in ECDSA, ie. RFC6979 instead of using a different algorithm such as the the new proposal using Tagged hashes.

Leak of private key ?

I read that Bitcoin tech is safe. Own a key, and it is safe. No one can steal my coin if I don't leak my key.

But why a private key can be leaked by making a transaction?

I think it is leak of public key.

If private key is leaked by a transaction, Bitcoin is not safe in tech.

There is nothing technically wrong with doing something like that.

Also considering privacy and security, as long as each address type is derived from a different key then you are fine. Meaning you should never use key at m/0/0 for both P2PKH and P2TR addresses, instead you should use keys at different paths like this: m/0/0 for P2PKH and m/0/1 for P2TR.
If this is not followed and the implementation is flawed, you could easily leak your private key each time you spend from both P2TR and P2PKH/P2WPKH addresses.
Note that it only works for Taproot (Schnorr sigs) and any of the older address types that use ECDSA.

The other problem would be recovering the wallet from seed. The wallet that offers you such an option to generate multiple types of addresses from the same seed, should also offer you an easy way of recovering that wallet. I don't think any wallet has that option.
If you did it manually by forcing the wallet to generate such address types then you have to remember the derivation paths you used to be able to recover the wallet later.