Woher wissen die Wallets bei der HD Wallet-Wiederherstellung, welche Adressen wiederhergestellt werden sollen?

Ich habe den BIP32-Vorschlag gelesen, in dem erklärt wird, wie HD funktioniert, aber es wurde an keiner Stelle erwähnt, wie sich eine Brieftasche in einem Telefon von einem einfachen mnemonischen Seed erholen kann.

  1. Versucht es einfach alle möglichen Adressen, die sich auf den Hauptschlüssel dieses Seeds beziehen, indem die gesamte Blockchain gleichzeitig nach Adressen sucht? (Das scheint imo unpraktisch).

  2. Gibt es Standards für die maximale n-te Adresse, die von der Wallet-Seite generiert werden soll?

Antworten (1)

Versucht es einfach alle möglichen Adressen, die sich auf den Hauptschlüssel dieses Seeds beziehen? (Das scheint imo unpraktisch).

Nein, das ist eigentlich unmöglich, da es praktisch eine unendliche Anzahl von Adressen gibt, die aus einem einzigen privaten Hauptschlüssel generiert werden können.

Stattdessen generieren Wallets Schlüssel auf standardisierten Ableitungspfaden und gehen davon aus, dass andere Wallets denselben Standards folgen. Dies ist im Allgemeinen eine sichere Annahme. Brieftaschen, die nicht den Standard-Ableitungspfaden folgen, verfügen normalerweise über eine Dokumentation, die angibt, welche Ableitungspfade sie verwenden, sodass Sie in einer anderen Brieftasche angeben können, welche Ableitungspfade verwendet werden sollen.

Die meisten Wallets folgen der BIP 44- Spezifikation für Ableitungspfade.

Gibt es Standards für die maximale n-te Adresse, die von der Wallet-Seite generiert werden soll?

Nein. Typischerweise generieren Wallets Adressen, bis sie nungenutzte Adressen generiert haben (bekannt als das Lückenlimit). Das Gap-Limit ist nicht standardisiert und viele Wallets erlauben es Ihnen, es zu konfigurieren. Bei vielen Wallets liegt das Gap-Limit bei 20 Schlüsseln, was aber beim Restaurieren wohl nicht ausreicht. In anderen Brieftaschen können es 100 Schlüssel sein und in anderen 1000.

Ausgezeichnete Antwort. Ich habe ein paar Fragen: 1. Bedeutet das, dass ein Wallet-Softwareentwickler für jeden erweiterten privaten Schlüssel erwarten kann, dass 20 bis 1000 Adressen wiederhergestellt werden, wenn er ein neues Software-Wallet entwirft. 2. Kann das nicht ein Hindernis sein, wenn die Idee, Schlüssel lokal aufzubewahren und die Größe des Smartphones mit Hunderttausenden von generierten erweiterten privaten Schlüsseln zusammenhängt? Nochmals vielen Dank für Ihre Antwort.
1. Ja. 2. Nein, Schlüssel können dynamisch generiert werden und müssen nicht gespeichert werden. Außerdem sind sie sehr klein und erfordern Hunderttausende von Schlüsseln, um irgendwohin zu gelangen, um wirklich merklich viel Platz einzunehmen.
Typischerweise generieren Wallets Adressen, bis sie n unbenutzte Adressen generiert haben. Bedeutet das, dass die Software-Wallet einen vollständigen Blockchain-Scan durchführen muss, um zu prüfen, ob die Adresse unbenutzt ist?
Ja, Wallets müssen die Blockchain scannen. Ein vollständiger erneuter Scan für jeden privaten Schlüssel ist jedoch nicht erforderlich, da die Benutzer die Adressen normalerweise der Reihe nach verwenden. Dies bedeutet, dass derselbe Rescan verwendet werden kann und neue Schlüssel verwendet werden, die als alte generiert werden. Es ist unwahrscheinlich, dass die neu generierten Schlüssel vor einem bereits bekannten Schlüssel verwendet wurden, insbesondere wenn die Lückengrenze groß ist.
Bitte erlauben Sie mir, mein Verständnis hier zusammenzufassen, Sie werden mir sagen, ob ich immer noch etwas falsch verstehe. Die Art und Weise, wie ich verstehe, dass diese Probleme gelöst werden, ist von einem erweiterten privaten Schlüssel, besuchen Sie Geschwisteradressen von Index 0 bis n, wenn Sie eine Adresslücke von 20 finden, gehen wir eine weitere Adressgeneration tief, beginnend mit den Kindern des 0. Kindes, und wiederholen die gleichen Dinge bis die Lücke wird von der Generationsebene aus der Baumperspektive gefüllt ? Wenn ~20 die Lückengrenze von den Geschwisteradressen ist, was wird als Lückengrenze von der Eltern-zu-Kind-Beziehung betrachtet?
Die Lückenbegrenzung gilt nur für die Geschwisterschlüssel. Es gibt keine Lückenbegrenzung von übergeordneten zu untergeordneten Schlüsseln. Wir suchen nicht durch tiefere und tiefere Ebenen, wir suchen nur höchstens 2 Ebenen, wobei angenommen wird, dass der Startpunkt mit einem Standardableitungspfad übereinstimmt. Wenn wir beispielsweise BIP 44 annehmen, würden wir mit dem Schlüssel bei m/44'/0'/0'/0/0 beginnen. Wir würden auch m/44'/0'/0'/1/0 suchen. Wir durchsuchen jedoch keine anderen Ebenen.