You're not going to get duplicate keys, as the pub / priv keys will be different for every address generated. m/1/53 and m/0/53 and m/0/54 will all generate different key pairs, so there would never be duplicates.
Considering 120,000 was stolen, I have a difficult time believing Bitfinex compartamentalized user's funds via different BIP32 master keys as they say they do.
From the sounds of things, what they did is the equivalent of a bank teller having $70 million cash sitting in her register.
Topic: Bitfinex, multisig, and BIP32/HD wallets (Read 889 times)
It is possible that bitfinex did have a new cold storage key for every user, but I find this to be very unlikely as it would be hard to maintain for cold storage.
Rather it is likely that they had one cold storage master key and each users cold storage keys were generated from that. They probably had a derivation path of m/0/i where i would be a unique id for each user. Then the internal and external keys would be derived as normal from that prefix path.
Rather it is likely that they had one cold storage master key and each users cold storage keys were generated from that. They probably had a derivation path of m/0/i where i would be a unique id for each user. Then the internal and external keys would be derived as normal from that prefix path.
I guess I was assuming that the backup key passed to BitGo would be a root key. If they were generating child keys and BitGo's API accepted them, that would explain the backup keys being unique. I agree that generating new cold storage keys per user is impractical.
It is possible that bitfinex did have a new cold storage key for every user, but I find this to be very unlikely as it would be hard to maintain for cold storage.
Rather it is likely that they had one cold storage master key and each users cold storage keys were generated from that. They probably had a derivation path of m/0/i where i would be a unique id for each user. Then the internal and external keys would be derived as normal from that prefix path.
Rather it is likely that they had one cold storage master key and each users cold storage keys were generated from that. They probably had a derivation path of m/0/i where i would be a unique id for each user. Then the internal and external keys would be derived as normal from that prefix path.
Honestly speaking. I don't even understand even a single thing you are saying in this topic. It is the fact that, im not in this line of job. And im still studying and do not have tge knowledge about bitcoin, I just kbow that Bittfinex was hacked lately and that's it.
It is possible that bitfinex did have a new cold storage key for every user, but I find this to be very unlikely as it would be hard to maintain for cold storage.
Rather it is likely that they had one cold storage master key and each users cold storage keys were generated from that. They probably had a derivation path of m/0/i where i would be a unique id for each user. Then the internal and external keys would be derived as normal from that prefix path.
Rather it is likely that they had one cold storage master key and each users cold storage keys were generated from that. They probably had a derivation path of m/0/i where i would be a unique id for each user. Then the internal and external keys would be derived as normal from that prefix path.
I was looking at some transactions that were purportedly part of the Bitfinex hack to see if I could verify that the two keys used were the user and BitGo keys (as opposed to the user and backup keys). BitGo uses HD wallets, and requires three xpub keys. The first two keys are from the client (a user key and a backup key), the third key is generated by BitGo. Both client and server know all the pubkeys, but only the client knows the privkeys of the first two, and only BitGo knows the privkey of the third key.
Now, the BIP32 or HD part. The BitGo documentation says:
So assuming that Bitfinex and BitGo both create a new key per wallet, the first and last keys for a wallet should be unique for every address since the chain path will change for every address, e.g. SomeKey/0/0/0/0, SomeKey/0/0/0/1, SomeKey/0/0/0/2, etc. So these keys would be unique both within a wallet's addresses, and across all wallets' addresses.
However, if the backup key is supposed to be in cold storage (which would still allow the creation of child pubkeys, just not privkeys), then although the child keys would be unique across addresses in a wallet, I would expect wallets to have the same generated child keys because the chain paths would be the same ("The first receiving address of a wallet is at the BIP32 path m/0/0/0/0").
From looking at an alleged list of transactions related to the hack, I haven't seen an instance of a duplicate backup key.
For example, this transaction has these unique redeem scripts containing three pubkeys each:
The second column is where the backup key should be. I've opened up around 20 or 30 other transactions from the list and extracted all the pubkeys from the second column, and no two transactions shared these keys.
Would this mean that Bitfinex is generating a backup key per user, and not using a cold storage key?
Now, the BIP32 or HD part. The BitGo documentation says:
Quote
BitGo wallets currently are hard-coded with their root at m/0/0 across all 3 keychains (however, older legacy wallets may use different key paths). Below the root, the wallet supports two chains of addresses, 0 and 1. The 0-chain is for external receiving addresses, while the 1-chain is for internal (change) addresses.
The first receiving address of a wallet is at the BIP32 path m/0/0/0/0, which is also the ID used to refer to a wallet in BitGo’s system. The first change address of a wallet is at m/0/0/1/0.
The first receiving address of a wallet is at the BIP32 path m/0/0/0/0, which is also the ID used to refer to a wallet in BitGo’s system. The first change address of a wallet is at m/0/0/1/0.
So assuming that Bitfinex and BitGo both create a new key per wallet, the first and last keys for a wallet should be unique for every address since the chain path will change for every address, e.g. SomeKey/0/0/0/0, SomeKey/0/0/0/1, SomeKey/0/0/0/2, etc. So these keys would be unique both within a wallet's addresses, and across all wallets' addresses.
However, if the backup key is supposed to be in cold storage (which would still allow the creation of child pubkeys, just not privkeys), then although the child keys would be unique across addresses in a wallet, I would expect wallets to have the same generated child keys because the chain paths would be the same ("The first receiving address of a wallet is at the BIP32 path m/0/0/0/0").
From looking at an alleged list of transactions related to the hack, I haven't seen an instance of a duplicate backup key.
For example, this transaction has these unique redeem scripts containing three pubkeys each:
Code:
0284c4c970e2da3a63aebdc1459c0d2f70ff19cafd2b6fb9bd115890d7ebd8d5b6 0307884e242ca277ff2084cebf24e8d4b5628b680e4a55c716543296100eb7ada3 0329dd501cf2519c438aae291e95d6e13d02776140c3458d996203c4e85284e238
025eb5b8e8172a92476a3d28cc7799e01e58d95dbc37a6ab166452d5ec2ea8e78e 03e13de2d5bbe607953a5e6e40f25f119905334207e4fca50062a8e163395aa5ca 024be7d2ade6fe9c40b0713a4c724b26a3ea90611e368caf18b24468f0360e60dd
0341c4944a252d59a749d42acfb3142872f395c74189bb809b0b7996cdf624692b 037f8940d3e120bf98fc4d65c71aa2330da3f9b7e619e9b8e8f1c556a251e338b6 025bb4ae3a91519cfe402955715558d0c8e0e20dc38a1b7f22f3625779b4f577c1
0372b610e40fcba937335d1f08420713c1ffae2fb98ca157538529e87fbe118692 03c07708c95fbc409b2bc38cc7ccf04abf6cf3f528834e285a008997eb64357497 02be1337116bf8bb0545efdbf31996bae918eea1c0a4ab0c89bfc3ea1bfb949408
02e3b8ec11e6febdbcd7ea849e035a97cdcdc41d1bb51ce2418e45ddb33f21c066 02ac9cda2a09d9d7842a3b60829ab31079a773bb3d489d0f165aed370d2cec93a2 023162f21fb3747cf5363a768c8556513cf3785eee5d9f6e657e696d0b0891fad4
02e91ee0cb1ebcd58b73d17d0b2fac3d22aba0276be45535fa3bd8e2fe8bc6a075 038d6eabb7fb57a626ff3c01b2ff51cd59b8c68f7b858c817d7bb141c9e865e7b8 03560711056f70407a12bd4ba84ed9e7a7ca38f9ff73782e01c35a8102f7e07e75
036f11106a0cdb554780d728d84d62810036eeca3909f2cbf23f2b6a359003c7a4 02f2d2ea546a6f08ecbf3a50ae776ec11224f0e5b3b94c8c85d6ea4e2bb9ef789f 03622705d1e8bb6a1ec60227f7525a2dca1071097d83e63b52ce72b28865496970
027d821abed78f593fa8ac5ef0871b34844924cc3b3fece7f8f6855493034f03c7 02bf68b6b643749b86903fe4b4a3f568b9cb88e7166c6621a7046177856d7096fc 03ce2b8b6ad2a57ff9e2e83eb2ff705ac667747325dd4b0ea819f8df1f2a891e7d
02db4ef974d8ed04312a9d49b1fbcfc3ecf9f3d5d087b3317ab688bcd3d02df094 03f1c8ea70f011b8924a82674b0c3baeb0e04634fb7b699f7a0df53ebde1fe5257 03709c2040ecff1dde911f2b5c283c473e31befc92afbc2621e4abd140303aa052
025eb5b8e8172a92476a3d28cc7799e01e58d95dbc37a6ab166452d5ec2ea8e78e 03e13de2d5bbe607953a5e6e40f25f119905334207e4fca50062a8e163395aa5ca 024be7d2ade6fe9c40b0713a4c724b26a3ea90611e368caf18b24468f0360e60dd
0341c4944a252d59a749d42acfb3142872f395c74189bb809b0b7996cdf624692b 037f8940d3e120bf98fc4d65c71aa2330da3f9b7e619e9b8e8f1c556a251e338b6 025bb4ae3a91519cfe402955715558d0c8e0e20dc38a1b7f22f3625779b4f577c1
0372b610e40fcba937335d1f08420713c1ffae2fb98ca157538529e87fbe118692 03c07708c95fbc409b2bc38cc7ccf04abf6cf3f528834e285a008997eb64357497 02be1337116bf8bb0545efdbf31996bae918eea1c0a4ab0c89bfc3ea1bfb949408
02e3b8ec11e6febdbcd7ea849e035a97cdcdc41d1bb51ce2418e45ddb33f21c066 02ac9cda2a09d9d7842a3b60829ab31079a773bb3d489d0f165aed370d2cec93a2 023162f21fb3747cf5363a768c8556513cf3785eee5d9f6e657e696d0b0891fad4
02e91ee0cb1ebcd58b73d17d0b2fac3d22aba0276be45535fa3bd8e2fe8bc6a075 038d6eabb7fb57a626ff3c01b2ff51cd59b8c68f7b858c817d7bb141c9e865e7b8 03560711056f70407a12bd4ba84ed9e7a7ca38f9ff73782e01c35a8102f7e07e75
036f11106a0cdb554780d728d84d62810036eeca3909f2cbf23f2b6a359003c7a4 02f2d2ea546a6f08ecbf3a50ae776ec11224f0e5b3b94c8c85d6ea4e2bb9ef789f 03622705d1e8bb6a1ec60227f7525a2dca1071097d83e63b52ce72b28865496970
027d821abed78f593fa8ac5ef0871b34844924cc3b3fece7f8f6855493034f03c7 02bf68b6b643749b86903fe4b4a3f568b9cb88e7166c6621a7046177856d7096fc 03ce2b8b6ad2a57ff9e2e83eb2ff705ac667747325dd4b0ea819f8df1f2a891e7d
02db4ef974d8ed04312a9d49b1fbcfc3ecf9f3d5d087b3317ab688bcd3d02df094 03f1c8ea70f011b8924a82674b0c3baeb0e04634fb7b699f7a0df53ebde1fe5257 03709c2040ecff1dde911f2b5c283c473e31befc92afbc2621e4abd140303aa052
The second column is where the backup key should be. I've opened up around 20 or 30 other transactions from the list and extracted all the pubkeys from the second column, and no two transactions shared these keys.
Would this mean that Bitfinex is generating a backup key per user, and not using a cold storage key?
Jump to: