Deterministic wallets

[jonald_fyookball]

quick question: deterministic wallets like electrum that have a master public key from which the public addresses may be (re-)generated subsequently. does one really need the master public key in order to generate those addresses or would it be possible to generate the subsequent addresses from e.g. the first public key (address)?

Yes you do need the master key.

An address is just a hash, and even if you knew the public keys
of specific addresses, you would not be able to determine
the other elliptic curve points of other addresses without the
master key.

Ah, alright, thanks! But you would be able to do that with the master public key, even though thats also just a public key!?

The master public key can generate addresses but not the private keys of those addresses.

[1714019592]

1714019592

[1714019592]

1714019592

[1714019592]

1714019592

[1714019592]

1714019592

[leanne]

quick question: deterministic wallets like electrum that have a master public key from which the public addresses may be (re-)generated subsequently. does one really need the master public key in order to generate those addresses or would it be possible to generate the subsequent addresses from e.g. the first public key (address)?

Yes you do need the master key.

An address is just a hash, and even if you knew the public keys
of specific addresses, you would not be able to determine
the other elliptic curve points of other addresses without the
master key.

Ah, alright, thanks! But you would be able to do that with the master public key, even though thats also just a public key!?

The master public key can generate addresses but not the private keys of those addresses.

that's clear, I was just making sure that indeed the master public key is needed in order to generate subsequent addresses even though it's just a public key (is it still a hash, though? what is it compromised of?)

[jonald_fyookball]

quick question: deterministic wallets like electrum that have a master public key from which the public addresses may be (re-)generated subsequently. does one really need the master public key in order to generate those addresses or would it be possible to generate the subsequent addresses from e.g. the first public key (address)?

Yes you do need the master key.

An address is just a hash, and even if you knew the public keys
of specific addresses, you would not be able to determine
the other elliptic curve points of other addresses without the
master key.

Ah, alright, thanks! But you would be able to do that with the master public key, even though thats also just a public key!?

The master public key can generate addresses but not the private keys of those addresses.

that's clear, I was just making sure that indeed the master public key is needed in order to generate subsequent addresses even though it's just a public key (is it still a hash, though? what is it compromised of?)

I can only tell you how it works in Electrum:

The master public key is not a hash.  It's simply a hex-encoded
public key to the master private key, which is an elliptic curve
key based on the deterministic seed.

New addresses are generated from the master key by
generating new ECDSA coordinates, basically by
combining new sequence numbers with that master key
to create a new point.

As with a normal Bitcoin address, you can calculate
the public key from the private key, but not the
other way around.  This is no different.

One consequence of the master key scheme,
is that if a single address in your wallet is compromised
(the private key becomes known), and the
attacker knows the master public key,
they can crack the entire wallet, because
they could use the one private key together
with the master public key to discover the
master private key.

For that reason, the master public key should be
kept secret.  Its purpose (at least in Electrum)
is to create a watching-only wallet.

[leanne]

I can only tell you how it works in Electrum:

The master public key is not a hash.  It's simply a hex-encoded
public key to the master private key, which is an elliptic curve
key based on the deterministic seed.

New addresses are generated from the master key by
generating new ECDSA coordinates, basically by
combining new sequence numbers with that master key
to create a new point.

As with a normal Bitcoin address, you can calculate
the public key from the private key, but not the
other way around.  This is no different.

One consequence of the master key scheme,
is that if a single address in your wallet is compromised
(the private key becomes known), and the
attacker knows the master public key,
they can crack the entire wallet, because
they could use the one private key together
with the master public key to discover the
master private key.

For that reason, the master public key should be
kept secret.  Its purpose (at least in Electrum)
is to create a watching-only wallet.

Ah alright, thanks! That's interesting, I really didn't know that the master public key may actually be an attack vector when compromised (in combination with an according private key). But it makes sense if it isn't a hash after all.

[fbueller]

Public keys in bitcoin are calculated by multiplying a private key by the generator point of the secp256k1 curve. This is a trapdoor function, where there are a lot of possible private keys, and a lot of public keys, and the oeration

Similarly, you can add numbers to private keys to get a new number, which would yield a different point.
You can also add two points together, which is equivalent to adding two numbers together.

Since public keys are by definition public, no harm comes by revealing them besides a loss of privacy. Public keys can be used to generate deterministic offsets between points on the elliptic curve.

By hashing the 'master public key', and a sequence number for the public key, you have deterministic 'offset' from the master public key - which is just a 256bit integer.. Which like private keys, can also be converted to a point.

So for public derivations, you have the master public key (a point) and an offset (another point), and you add these two together.

The private derivation assumes you have the private key, and want to obtain a child private key. You take the private key (a number), generate the offset from the master public key (a number, but this time it's not converted to a point, you keep the number), and then you do modulo addition..

Lo and behold, it yields a number (the private key), which when multiplied by the generator, gives the same point as when you added two points together using purely public information. The private derivation works because the person has the master public key and could hash it also.

The reason you cannot share a master public key AND private key, is that someone can deduce it in this way (in a simple example)

// Attacker has Master Public Key, Address6/PublicKey6, PrivKey6
hash = hash('mpk'+'6')
offset = hash * G
Pub6 = PointMPK(x,y) + offset

Priv6 = k.

Main Priv Key = Priv6 - offset
Main Priv Key * G == mpk.

Now to calculate every private key in the chain:
PrivKey(n) = MainPrivKey + hash('mpk' + n)

[cmartin1069]

At it's core, this is an HD Wallet question: 

I'm looking into developing a special purpose alt-coin and would like keep it largely the same as bitcoin except for what follows.  I would appreciate if someone would help me by telling me if a new protocol could be developed to support these requirements:

1.  we need to be able to have an internal organization create the seeds on behalf of a user (at their request.)
2.  this internal org would securely and confidentially maintain the user-to-seed relationship (no one else would know and it's a key requirement
3.  the user would be able to create any number of private or public keys themselves but always maintain the connection back to the original seed

Users would send and receive coins as bitcoin works today, with a blockchain as the ledger.  Users would be awarded coins by the company and can spend them/trade them with anyone else who also has a PK.

With these requirements, I would essentially have an audit trail of everyones transactions but only the internal organization could tie the transactions to a real employee.

[iddo]

1.  we need to be able to have an internal organization create the seeds on behalf of a user (at their request.)

I don't think that you want this organization to create the "seed" because it implies that this organization can also steal the user's coins.

Maybe what you want is that any user can generate a fresh seed (that derives privkey/pubkey pairs so that only the user knows the privkeys), where the master pubkey and master chaincode (that are derived from the seed that he generated) must be signed by this organization before this "user account" becomes valid on this network? This implies that new users are at the mercy of this organization, e.g., this organization may refuse to sign a new account unless it receives a bribe on the side. Also, if the signing key of this organization is compromised then all bets are off.

[cmartin1069]

I don't think that you want this organization to create the "seed" because it implies that this organization can also steal the user's coins.

Maybe what you want is that any user can generate a fresh seed (that derives privkey/pubkey pairs so that only the user knows the privkeys), where the master pubkey and master chaincode (that are derived from the seed that he generated) must be signed by this organization before this "user account" becomes valid on this network? This implies that new users are at the mercy of this organization, e.g., this organization may refuse to sign a new account unless it receives a bribe on the side. Also, if the signing key of this organization is compromised then all bets are off.

Agree with your initial observvation.   You idea sounds fantastic.  If I understand correctly, the governing organization would just know the master PUBLIC key and link that to the identify.  Perfect.

Perhaps you could explain a bit how the signing by the governing org of the pubkey and chaincode would validate it and the lack of the signing would prohibit use?  is this just something that the protocol would need to be coded to support?   and can I have more than one of the govening orgs? 

Thanks!