Gap Limit legt fest, nach wie vielen unbenutzten Adressen in Folge eine Wallet nicht mehr weitersucht. Bei der Wiederherstellung aus einer Sicherung berechnet sie die Adressen erneut und prüft, ob es dazu Transaktionen gibt. Eine Abbruchregel verhindert, dass sie endlos einen riesigen Bereich von Möglichkeiten durchsucht. Eine Zahlung jenseits dieser Grenze kann in der Übersicht fehlen, obwohl der Besitzer die richtigen Schlüssel hat. Die Grenze zu überschreiten löscht kein Geld und begrenzt nicht die Zahl ableitbarer Schlüssel.
Anna nutzt eine Wallet, eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Sie hat viele Empfangsadressen im Voraus erzeugt, also Angaben, mit denen andere ihr eine Zahlung senden können, manche aber nie benutzt. Nach der Wiederherstellung fehlen Zahlungen. Stellen wir uns eine Suche mit dem Limit 20 vor: Adresse mit Index 0 hat eine Historie, die folgenden Indizes 1–20 nicht, und auf Index 21 ging eine Zahlung ein. Der Index ist lediglich die Position der Adresse in der Reihe; gezählt wird ab null. Nach der leeren Folge stoppt der Scan vor Index 21 und übersieht die Zahlung. Würde innerhalb der untersuchten Folge eine benutzte Adresse auftauchen, begänne der Lückenzähler von vorn. Das Limit bedeutet also nicht, dass die ganze Wallet höchstens zwanzig Adressen haben darf. [1] [6]
Was heißt hier unbenutzt? Gemeint ist nicht eine Adresse, auf der gerade kein Geld liegt. Anna kann eine Zahlung erhalten und später vollständig ausgegeben haben. Der Saldo ist dann null, doch die Transaktionshistorie bleibt bestehen und die Adresse gilt bei der Suche weiterhin als benutzt. BIP 44 arbeitet deshalb mit der Historie, nicht nur mit dem aktuellen Guthaben. Jede leere Adresse als nie benutzt zu behandeln könnte die Wiederherstellung zu früh abbrechen. Auch ein längst ausgegebener Eingang hilft daher bei der Prüfung einer wiederhergestellten Wallet. [1]
BIP 44 beschreibt als Standard die Anordnung von Konten und Adressen in einer hierarchischen Wallet, die Schlüssel und Adressen wie einen Baum mit verschiedenen Zweigen ordnet. Seine Regel Address gap limit setzt für die Suche im externen Empfangszweig eine Grenze von 20. Dieser Zweig ist die Reihe der für eingehende Zahlungen vorgesehenen Adressen. Beim Erzeugen einer Adresse jenseits der Grenze soll die Software warnen. Das ist eine Vereinbarung zur Wiederherstellung, keine Konsensregel darüber, ob das Netzwerk eine Transaktion annimmt. Andere Wallets können andere Einstellungen oder Suchverfahren verwenden. Daraus folgt auch keine Empfehlung, dauerhaft dieselbe Empfangsadresse zu benutzen. [1]
Die ursprüngliche Wallet kann weit im Voraus erzeugte Adressen kennen. Wird nur aus einer Sicherung der Schlüssel wiederhergestellt, weiß die neue Software möglicherweise nicht, wie weit du zuvor gegangen bist. Electrum warnt ausdrücklich davor: Adressen jenseits des Gap Limit werden bei einer gewöhnlichen Wiederherstellung eventuell nicht automatisch gefunden. Die Dokumentation nennt als Abhilfe ein höheres Limit oder das Ableiten weiterer Adressen bis zur benutzten Position. Passende Einstellungen hängen jedoch von Software und Wallet-Typ ab. Der FAQ-Standardwert von 20 bezieht sich auf Electrum 2.0 und ist kein allgemeingültiger Wert für heutige Wallets. [2]
Eine Wallet lässt sich als geordneter Baum vorstellen. Konten trennen Gruppen von Guthaben, und innerhalb eines Kontos gibt es verschiedene Adresszweige. Bei BIP 44 bezeichnet change=0 den Empfangszweig und change=1 den Zweig für eigenes Wechselgeld, also den Betrag, der nach einer Zahlung beim Absender bleibt. Die Kontensuche beginnt mit Konto 0 und dessen externem Zweig. Findet sie eine Historie, folgt das nächste Konto; das erste Konto ohne Historie beendet die Kontensuche. Deshalb soll laut Standard kein neues Konto angelegt werden, solange das vorherige keine Historie hat. Eine Lücke in einem Adresszweig und ein übersprungenes leeres Konto sind unterschiedliche Probleme. Ein höheres Limit allein bestimmt nicht, welche weiteren Konten die Software durchsucht. [1]
BIP 32 beschreibt deterministische Schlüsselableitung: Gleiche Ausgangsdaten und derselbe Pfad ergeben dieselben Schlüssel. Ein Derivation Path ist der Weg durch diesen Baum. Zusammen mit dem Script-Typ, also den Ausgaberegeln, bestimmt er die beobachteten Adressen. Die richtige Seed Phrase, deine Sicherungswörter, ist deshalb nur ein Teil der nötigen Information. Bei BIP 39 fließt auch eine optionale Passphrase in die Berechnung des Seeds ein, des Ausgangsgeheimnisses für die Schlüsselableitung. Die Passphrase ist ein zusätzlicher geheimer Text, der vom Anwendungspasswort zu unterscheiden ist. Eine andere Passphrase führt zu einer anderen Wallet; ein höheres Gap Limit korrigiert das nicht. Ein privater Schlüssel ist ein geheimer Zahlenwert, mit dem die Wallet eine digitale Signatur zur Freigabe einer Ausgabe erstellt. Für Fortgeschrittene: Ein xpub ist ein erweiterter öffentlicher Schlüssel, mit dem sich weitere öffentliche Schlüssel ableiten lassen. Er hilft beim Beobachten von Adressen und Zahlungen, kann aber allein keine Ausgabe freigeben. Er allein kann keinen hardened Ableitungsschritt überwinden, der den privaten Elternschlüssel benötigt. Weiterzusuchen ersetzt diese fehlende Möglichkeit nicht. [4] [5] [6]
Bitcoin Core 29.0 stellt importdescriptors über RPC bereit, die Programmierschnittstelle des Knotens. Ein Descriptor beschreibt, wie aus Schlüsseln Ausgabebedingungen und zu beobachtende Adressen entstehen. range legt den abzuleitenden Indexbereich fest und ist keine Abbruchregel nach einer leeren Lücke. next_index bestimmt bei einem aktiven Descriptor den nächsten Index zur Adresserzeugung. timestamp legt dagegen fest, ab wann Transaktionen gesucht werden. now ist für Outputs gedacht, die nachweislich noch nie benutzt wurden; es ersetzt nicht die Wiederherstellung älterer Zahlungen. Die Dokumentation berücksichtigt auch Blöcke bis zu zwei Stunden vor dem frühesten timestamp der importierten Descriptors sowie den Mempool, die lokale Sammlung unbestätigter Transaktionen. Auch eine korrekt abgeleitete Adresse kann daher in der Übersicht fehlen, wenn der betreffende Zeitraum nicht durchsucht wurde. [3]
Zurück zu Anna: Hat sie eine bekannte Empfangsadresse oder einen Zahlungsbeleg aus der ursprünglichen Wallet, kann sie prüfen, ob die neue Wallet diese tatsächlich gefunden hat. Vergleiche auch bereits ausgegebene Eingänge, nicht nur das Endguthaben. Ein längerer Scan kann übersehene Historie finden, benötigt aber Zeit und mehr Abfragen. Bei einem entfernten Server kann er diesem weitere zusammengehörige Adressen offenlegen. Die Suche allein überträgt kein Geld und verändert die Blockchain nicht. Stimmt die Historie weiterhin nicht, müssen Sicherungsdaten, Konto, Pfad, Adresstyp und verfügbare historische Daten geprüft werden, statt nur das Limit weiter zu erhöhen. Eine gefundene Adresse beweist noch nicht, dass die ganze Wiederherstellung vollständig ist. [1] [2] [4]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Change Address, Seed Phrase. Auf diesen Eintrag verweisen außerdem HD Wallet, Derivation Path.