ich stelle mir schon länger eine Frage zur BitBox02 (oder auch anderen Hardware-Wallets):
Wie genau stellt das Wallet sicher, alle relevanten Adressen „gescannt“ zu haben, um z.B. den Bitcoin-Bestand zu ermitteln? Wird einfach eine vordefinierte Liste bis zu einer gewissen Obergrenze durchgescannt? Die BitBox gibt einem ja auch die nächsten 20 Adressen aus, von denen man nicht alle nutzen braucht (oder dies in beliebiger Reihenfolge tun kann und zwischendurch welche auslassen kann), sodass ein Kriterium wie „schaue auf alle Adressen einer vordefinierten Reihenfolge, bis Du zu einer transaktionsfreien Adresse kommst“ auch nicht perfekt funktionieren dürfte.
Weiß jemand, wie das genau funktioniert? Es werden ja unmöglich alle theoretisch möglichen 2^256 (Korrektur: 2^160) Adressen gescannt werden können
Meistens werden Adressen eines Accounts so lange überprüft bis man auf 20 leere Adressen hintereinander stößt. Also wenn du bisher die ersten 6 Adressen verwendet hast (/0 bis /5) dann sucht die Wallet insgesamt 26 Adressen, also bis zur Adresse /25. Sollte es Adressen „weiter hinten“ geben die Bitcoin kontrollieren dann weiß die Wallet Software davon erstmal nichts und zeigt sie auch nicht an.
Adressen werden nach einem Ableitungsbaum deterministisch abgeleitet und nicht zufällig generiert. Die „1. Adresse“ eines Accounts ist also überall die selbe, und es wird auch immer mit dieser 1. Adresse begonnen.
Man kann allerdings auch das Gap Limit, die Anzahl an leeren Adressen die gesucht werden, erhöhen. Das geht nicht mit der BitBox App, aber mit der Sparrow Wallet oder Electrum ist das kein Problem. In der Praxis braucht man das nur sehr selten, da man mit solchen Adressen nicht so einfach in Kontakt kommt, eben weil man i.d.R. nur Zugriff auf die jeweils nächsten 20 hat.
Deswegen ist das Kriterium auch „schaue auf alle Adressen bis du 20 Transaktionsfreie Adressen hintereinander gefunden hast“.
Es gibt keine 2^{256} Adresen sondern durch RIPEMD-160 „nur“ 2^{160}. Public Keys bzw. Skripte werden zunächst mit SHA-256 gehasht, dann mit RIPEMD-160 und anschließend in ein Adressformat codiert. Pigeonhole principle.
Ah, verstehe, besten Dank für die schnelle Antwort und für die Klarstellung! Das heißt, die nächsten 20 Adressen, die mir die BitBox anzeigt, sind immer die „ersten“ transaktionsfreien Adressen? Im Sinne von, wenn die Adressen 1,2,3,4,5 und 11,12,13,14,15 bereits Transaktionen haben (und die Adressen zwischendrin noch keine Transaktionen haben), dann zeigt mir die BitBox als nächste Empfangsadressen die Adressen 6,7,8,9,10,16,17,18,19,20,21… an? Bzw. andersherum gefragt, Adressen können erst aus der Anzeige der nächsten 20 verschwinden, wenn diese eine Transaktion haben, richtig?
Nein, ich glaube dann werden dir ausschließlich Adressen 16-35 angezeigt. Es werden immer die nächsten 20 nach der größten (Index) verwendeten Adresse angezeigt. Die angezeigten Adressen entsprechen also immer auch den Adressen die beim Scannen überprüft werden.
Zu 100% bin ich mir da nicht sicher, vielleicht kann das @Stadicus beantworten.
Mir ist das jedenfalls so aufgefallen als ich die Sparrow Wallet zum ersten Mal verwendet habe.
Du kannst das selbst mal ausprobieren. Wenn du Adresse /19 verwendest werden dir in der Sparrow Wallet 40 Adressen aufgelistet (die ursprünglichen 20 + die neuen 20). In der BitBox App wiederum werden dann nur die neuen 20 angezeigt.
(In der Sparrow Wallet werden benutzte Adressen nicht ausgeblendet sondern übersichtlich aufgelistet)
Doch das geht, man muss die Applikation einfach mit einem Zusatzparameter starten. Die Synchronisation mit dem Bitcoin Node dauert dann natürlich auch entsprechend länger.
dann werden dir ausschließlich Adressen 16-35 angezeigt. Es werden immer die nächsten 20 nach der größten (Index) verwendeten Adresse angezeigt
Korrekt, es könnte ja sein, dass eine der dazwischen liegenden Adressen schon herausgegeben, aber noch nicht bezahlt wurde. Da die Anzahl möglicher Adressen praktisch unbegrenzt ist, spielt das keine Rolle.
Danke für die Infos! Jedenfalls entkräftet das meine Bedenken, dass man irgendwann in eine Situation kommt, in der man sich eine Adresse erstellt hat und man BTC auf diese sendet, und durch zwischenzeitliches Auslassen von Adressen die Bestandsanzeige nicht vollständig ist.
Application Bundles (.app Dateien) sind halt eigentlich Verzeichnisse. ./funktioniert hier nicht da es nichts zum ausführen gibt. Man müsste in die .app rein navigieren und die Executable suchen.
Vielleicht liegt es auch daran, dass ich das AppImage verwende. Diese Application Bundles (.app Dateien), von denen du sprichst, kenne ich gar nicht. Ich habe die Bezeichnung oben nur beispielhaft verwendet.
Unter Linux mache ich das AppImage zuerst ausführbar und führe es dann aus. Ich habe gerade sogar gesehen, dass das auch auf der ShiftCrypto Seite genau so angegeben ist:
chmod +x ./BitBox-[version]-x86_64.AppImage
./BitBox-[version]-x86_64.AppImage
Das sieht man, wenn man auf der Download Seite zuerst auf Linux, dann auf Linux64 other distros klickt.
Ja, das ist nicht optimal dokumentiert. Kenn mich mit Mac nicht so aus, aber unter Linux gibt’s die von dir beschriebene AppImage-Version, und die von mir selber verwendete Deb-Pakete.
Beim installierten Deb-Paket starte ich die BitBoxApp einfach so:
wenn bei der BitBox02 nicht alle Coins einer Wallet gezeigt werden und im gleichen Konto auf dem Ledger schon, kann es sein dass Index gap limit
bei der BitBox02 überschritten wurde?
Wie reduziere ich die Gaps im Nachhinein?
Gibt es eine Möglichkeit alle Coins auf Index=0 rückzuführen und zusammenzufassen?
Edit: die Schuld lag nicht an der Bitbox02, sondern an der Ledger-Software, die einen viel höheren Bestand angezeigt hat und auch nicht mehr sendend funktionierte. Nach dem leeren des Cache der Ledger Wallet zeigen beide nun wieder den gleichen Bestand…
kann man trotzdem irgendwie mal durch alle möglichen Indexe scannen und dann „defragmentieren“, das heisst alles auf Index=0 zusammenfassen?
Auch wenn es bei dir jetzt nicht der Grund war, das wäre schon möglich. Das wäre in diesem Fall aber sehr unwahrscheinlich, da man beim normalen Benutzen von Ledger Live oder der BitBox App mit gar keinen Adressen außerhalb vom Limit in Berührung kommt.
Sowas passiert eigentlich nur wenn man selber damit rumgespielt hat oder z.B. nach einem CoinJoin.
Gap Limit kann man mit der BitBox App übrigens auch als Argument beim Starten anpassen:
Der Index steht deterministisch für ein Schlüsselpaar mit einer Adresse! Diese Reihenfolge beim Derivieren kannst (und solltest) du nicht ändern.
Indem du alle deine UTXO auf die Adresse #0 sendest. Aber was soll dir das denn bringen? (Vom Konsolidieren mal abgesehen)
Standardmäßig werden immer die nächsten 20 Adressen nach dem höchsten verwendeten Adressindex abgesucht. Solange du auch nur in diesem Bereich ableitest wirst du auch nie Probleme damit haben.
Beispielanwendung (neben Sicherstellen, dass auf Grund eines Gaps nicht „Beträge übersehen werden“):
wenn ich die Thorchain swap exchange nutze, verlangt diese einen Index und addiert die einzelnen indexe nicht automatisch zusammen. Ergo: ich kann erst nach Zusammenfassung meiner UTXOs(?) diese App richtig nuzten…
