Skip to main content
added 63 characters in body
Source Link
Nick ODell
  • 29.5k
  • 11
  • 73
  • 132

Why one would need extended public keys for the auditing a bip32 wallet?

You don't need them. You could also just make a list of all of the addresses that have a balance, and send that to your auditor.

Auditing a Bitcoin wallet is not a very good example of what this is capable of. Here are some other uses of BIP32:

  • You could have a script on a server with an extended public key generate addresses for people to donate to, without having that same server be able to spend money sent to those addresses. Without BIP32, you'd have to make a long list of addresses, put them on your server, and replenish them whenever they ran out.
  • You could have an e-commerce app generate addresses like the above, and detect payments to those addresses without, again, having the ability to spend them.

Wouldn't the (non-extended) elliptic curve encryption's public keys work too?

No. You also need the chain code to calculate the subkeys. Collectively, these two things make up an extended public key.

Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key.

It's... debatably safe. I don't think there's a real-word situation where someone would compromise one of your non-hardened private keys without having access to all of them.

Why one would need extended public keys for the auditing a bip32 wallet?

You don't need them. You could also just make a list of all of the addresses that have a balance, and send that to your auditor.

Auditing a Bitcoin wallet is not a very good example of what this is capable of. Here are some other uses of BIP32:

  • You could have a script on a server with an extended public key generate addresses for people to donate to, without having that same server be able to spend money sent to those addresses. Without BIP32, you'd have to make a long list of addresses, put them on your server, and replenish them whenever they ran out.
  • You could have an e-commerce app generate addresses like the above, and detect payments to those addresses without, again, having the ability to spend them.

Wouldn't the (non-extended) elliptic curve encryption's public keys work too?

No. You also need the chain code to calculate the subkeys.

Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key.

It's... debatably safe. I don't think there's a real-word situation where someone would compromise one of your non-hardened private keys without having access to all of them.

Why one would need extended public keys for the auditing a bip32 wallet?

You don't need them. You could also just make a list of all of the addresses that have a balance, and send that to your auditor.

Auditing a Bitcoin wallet is not a very good example of what this is capable of. Here are some other uses of BIP32:

  • You could have a script on a server with an extended public key generate addresses for people to donate to, without having that same server be able to spend money sent to those addresses. Without BIP32, you'd have to make a long list of addresses, put them on your server, and replenish them whenever they ran out.
  • You could have an e-commerce app generate addresses like the above, and detect payments to those addresses without, again, having the ability to spend them.

Wouldn't the (non-extended) elliptic curve encryption's public keys work too?

No. You also need the chain code to calculate the subkeys. Collectively, these two things make up an extended public key.

Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key.

It's... debatably safe. I don't think there's a real-word situation where someone would compromise one of your non-hardened private keys without having access to all of them.

Source Link
Nick ODell
  • 29.5k
  • 11
  • 73
  • 132

Why one would need extended public keys for the auditing a bip32 wallet?

You don't need them. You could also just make a list of all of the addresses that have a balance, and send that to your auditor.

Auditing a Bitcoin wallet is not a very good example of what this is capable of. Here are some other uses of BIP32:

  • You could have a script on a server with an extended public key generate addresses for people to donate to, without having that same server be able to spend money sent to those addresses. Without BIP32, you'd have to make a long list of addresses, put them on your server, and replenish them whenever they ran out.
  • You could have an e-commerce app generate addresses like the above, and detect payments to those addresses without, again, having the ability to spend them.

Wouldn't the (non-extended) elliptic curve encryption's public keys work too?

No. You also need the chain code to calculate the subkeys.

Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key.

It's... debatably safe. I don't think there's a real-word situation where someone would compromise one of your non-hardened private keys without having access to all of them.