Reading up on what the derivation path actually is bips/bip-0044.mediawiki at master · bitcoin/bips · GitHub, it seems really only 2 indices out of the 5 can be modified to construct different valid bitcoin addresses, namely “account”, and “address index”.
In a Nat8 context, required by at least the Bitcoin Example code, that would reduce the number of valid bitcoin addresses controlable by a single canister in practice to only 255^2 = 65 025.
I believe I read somewhere that one canister can control up to around 2^31 ~= 2 billion addresses.
How many valid and real bitcoin addresses can a canister control in practice? What I mean by that is addresses that:
won’t show “invalid address” when searched for in a traditional bitcoin block explorer,
won’t flag “invalid address” in many bitcoin wallets or from many centralised exchanges when attempting a withdrawal and/or prevent transfers to it,
will just work with the existing bitcoin network ecosystem without causing headaches for users.
But it would seem from the bitcoin repo’s documentation that if you use all those, most of the generated address will not be considered valid by most existing wallets and block explorers?
Yes. Bip32 is as you quote it. If you want to follow that standard, then you should foĺlow that standard…meaning that, in context of TECSDA, leave the hardened paths alone… work at address_index level?
I’m trying to understand how many usable, real life bitcoin addresses each canister can control. What I mean by that is addresses that:
won’t show “invalid address” when searched for in a traditional bitcoin block explorer,
won’t flag “invalid address” in many bitcoin wallets or from many centralised exchanges when attempting a withdrawal and/or prevent transfers to it,
will just work with the existing bitcoin network ecosystem without causing headaches for users.
If the answer is only 231 (address_index), or only 231^2 (address_index + account), that is an insufficiently small number for many applications, and would require a substantially different architecture of many such applications.
That’s what I mean by how many valid and real bitcoin addresses can a canister control in practice, which is admittedly not the best wording for the question. I’m editing it.
The number of usable Bitcoin addresses is practically unbounded.
It is important to understand that there is no way to tell if a Bitcoin address adheres to the BIP-32 (or a related) standard, so there are no “receiver-side checks”.
If you don’t care about BIP-32 compliance, you can use arbitrary byte arrays as the derivation path as specified here.
If you want to follow the BIP-32 standard, you are free to create as many derivation levels as you wish, giving you up to 2³¹ addresses per level (the highest-order bit must be 0 because hardened derivation is not supported).
The longer answer: the derivation gives you a derived public key. It only matters that a valid signature can be computed for this public key, which is exactly what the sign_with_ecdsa function does.
You can get an “invalid address” error if there is an error in how you compute the Bitcoin address (encoded in Base58 or Bech32) from the derived public key.
The only other scenarios that I can think of: The destination (for example, an exchange) does not support the address format or the Bitcoin address was blacklisted for whatever reason (which is improbable if it is a freshly derived address).
