Теперь BIP32 или HD часть. Документация BitGo говорит:
котировка
BitGo бумажники в настоящее время жестко закодированы с их корнем в м / 0/0 во всех 3-х брелоков (однако, старые устаревшие бумажники могут использовать различные ключевые пути). Ниже корня, бумажник поддерживает две цепочки адресов, 0 и 1. 0-цепь для внешних приемных адресов, в то время как 1-цепь для внутренних (изменить) адресов.
Первый принимающий адрес бумажника находится на пути BIP32 м / 0/0/0/0, который также идентификатор, используемый для обозначения бумажника в системе BitGo в. Первый адрес изменения кошелька находится на м / 0/0/1/0.
Первый принимающий адрес бумажника находится на пути BIP32 м / 0/0/0/0, который также идентификатор, используемый для обозначения бумажника в системе BitGo в. Первый адрес изменения кошелька находится на м / 0/0/1/0.
Так если предположить, что Bitfinex и BitGo как создать новый ключ за бумажником, первые и последние ключи для кошелька должны быть уникальными для каждого адреса, так как путь цепи будет меняться для каждого адреса, например, SomeKey / 0/0/0/0, SomeKey / 0/0/0/1, SomeKey / 0/0/0/2 и т.д. Таким образом, эти ключи будут уникальными как в адресах бумажника, и по адресам всех Ключницы ,
Тем не менее, если резервный ключ должен находиться в холодильниках (который до сих пор позволяет создавать дочерний pubkeys, только не privkeys), то хотя ребенок ключи будет уникальным по адресам в бумажнике, я бы ожидать, бумажники, чтобы иметь же сгенерированные дочерние ключи, так как пути цепи будет таким же ("Первый принимающий адрес бумажника находится на пути BIP32 м / 0/0/0/0").
Глядя на предполагаемый перечень операций, связанных с хака, Я не видел экземпляр дубликата ключа резервного копирования.
Например, эта сделка имеют следующие уникальные сценарии выкупа, содержащие три pubkeys каждые:
Код:
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
Второй столбец, где резервный ключ должен быть. Я открыл около 20 или 30 других сделок из списка и извлекаюсь все pubkeys из второго столбца, и никаких две транзакций не разделяли эти ключи.
Это означало бы, что Bitfinex генерирует резервный ключ для каждого пользователя, а не с помощью ключа холодного хранения?