Transaktion an Adresse die es nicht gibt

Hallo liebes Forum,

was passiert eigentlich wenn ich eine Transaktion auf eine Adresse machen möchte, die es nicht gibt?

Danke
mfg

Versuch mal eine solche Adresse einzugeben :wink:
Es wird nur eine Fehlermeldung auftauchen.

Nichts. Deine Wallet erkennt die ungültige Adresse und beschwehrt sich.

Vorsicht: Eine Adresse, die niemand benutzt, existiert natürlich trotzdem, sofern sie formal gültig ist, und eine Transaktion kann ohne Probleme stattfinden.

4 „Gefällt mir“

Dazu habe ich pauschal weitere Fragen:

Wenn ich das richtig verstanden habe, wird nicht der gesamte Bereich von 256 Bit unterstützt. Ein Private Key darf eine bestimmte Zahl nicht überschreiten. Ist das soweit korrekt?

Wenn ja, werden dann Transaktionen, welche an einen solchen ungültigen Key gehen, direkt vom Netzwerk abgelehnt?

Kann man anhand einer Adresse überhaupt erkennen dass ein ungültiger Private Key dahinter steckt?

Warum sind diese hohen Zahlen überhaupt ungültig?

Du hast da was falsch verstanden. Das Netzwerk kennt natürlich keine privaten Schlüssel – die sind privat! Es gibt in dem Sinne auch keine ungültigen Private Keys, es sind schließlich nur Zahlen.*

Es geht hier um Adressformate. Genau wie auf einem Brief bei der Post muss ein gewisses Muster eingehalten werden, um als gültig durch zu gehen. Bei den Adressen wird z.B. mit Base58 Check oder Bech32 codiert. Die Adressen haben dann eine Checksumme um z.B. Tippfehler abzufangen. Die neueren Bech32 Adressen (Segwit) können Fehler sogar korrigieren.

Auch die Mnemonic hat eine Checksumme im letzten Wort – reine Absicherung gegen Fehler. Dahinter stehen trotzdem rohe 256 bit Zufall. Das hat damit also nichts zu tun.

Gültige Adresse:

bc1q2hcwf0yxhl0qq6uzmadye8cx5d2jaazdzt33cr

Ungültige Adresse – eingebauter Tippfehler:

bc1q2hcwf0yxhx0qq6uzmadye8cx5d2jaazdzt33cr
             ^

Eine Transaktion an letztere Adresse würde abgelehnt werden weil es keine Bitcoin Adresse ist.

* Private Keys werden, ähnlich wie Adressen, natürlich auch für den Nutzer in ein anderes Format codiert, z.B. als WIF. Ich meinte hier jetzt den rohen Schlüssel.

Doch, es gibt 2256 Private Keys.

Eine einfache Bitcoin Adresse ist ein Hash des öffentlichen Schlüssels. Unter anderem wird hier die Hashfunktion RIPEMD-160 verwendet, die einen Output von „nur“ 160 bit hat. Das bedeutet einfach dass es mehrere Private Keys für die selbe Adresse geben muss, da es „nur“ 2160 Adressen geben kann.

Du kannst nicht 20 Autos auf 10 Parkplätze stellen. Das ist hier im Bitcoin Kontext, durch die Größenordnung der Zahlen, aber nicht weiter relevant.

2 „Gefällt mir“

Da der Adressraum letztlich sowieso auf 2¹⁶⁰ Adressen eingeschränkt ist, ist es wie du erklärt hast in diesem Kontext hier eigentlich nicht relevant. Trotzdem gibt es tatsächlich auch wie @lerpy sagt weniger als 2²⁵⁶ unterscheidbare Private Keys.

Als zugrundeliegenden Zahlenraum für die Punkt-Koordinaten auf der elliptischen Kurve verwendet man einen endlichen Körper mit Primzahlordnung p (Ganze Zahlen modulo p), wobei p etwas geringer als 2²⁵⁶ ist.

Die Punkte auf der Kurve, welche durch die Vielfachen des Generators erreicht werden können, bilden eine zyklische Gruppe und werden als Schlüsselraum für die Public Keys verwendet. Die Ordnung n dieser Gruppe ist hier nochmal geringfügig kleiner als die des Körpers.

Bei Bitcoin wird Secp256k1 mit folgenden Ordnungen verwendet:

p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

Bei den Private Keys wird modulo der Gruppenordnung gerechnet, da die Gruppe zyklisch ist. Die Private Keys laufen also von 0 bis n-1.

Der Private Key n entspricht dann wieder dem Private Key 0, der Private Key n+1 dem Private Key 1 usw. .
Das kann man aus Spaß mal ausprobieren und sieht, dass bei Private Keys m und n+m die gleichen Public Keys und Adressen herauskommen (vermeintliche Kollisionen).

Wie man sieht ist n aber nahezu 2²⁵⁶, also nicht wirklich relevant.

4 „Gefällt mir“

Streber! :smiley:

Bedeutet, selbst wenn man 2^256 „erwürfeln“ würde, es trotzdem einen validen Private Key ergäbe!?

Wäre dies dann der selbe Private Key wie der von p-n?

Können solche Private Keys, wie von 2^256 bzw. >=n, als sicher betrachtet werden?

Angenommen ich „erwürfel“ n+1, wäre dies zwar eine sehr hohe Zahl, und würde damit vielleicht fälschlicher weise als sicher erachtet werden. Bei einem Brute Force Angriff jedoch würde 1 vermutlich einer der ersten Versuche sein. Demnach wäre dieser Private Key sehr unsicher, richtig?

Theoretisch könntest du beliebig hohe Zahlen modulo n als gültigen Private Key betrachten. Auch 2²⁵⁶ oder noch größere ganze Zahlen. Spätestens wenn du damit signierst, rechnest du aber sowieso modulo n. Und ansonsten kennt niemand deinen Private Key.

Wenn du einen Private Key allerdings „erwürfeln“, also zufällig bestimmen möchtest, ist es sinnvoll, dass alle möglichen Private Keys gleich wahrscheinlich sind. In diesem Fall würde ich also alle Private Key Resultate außerhalb des Bereichs 1…(n-1) verwerfen. Ansonsten gibt es mehrere Resultate, die zum gleichen Private Key führen würden.

Der Private Key 0 wäre identisch zum Private Key n. Der entsprechende Punkt auf der Kurve (= Public Key) ist das neutrale Element der zyklischen Gruppe. Dieses wird aus anschaulichen Gründen „Point at Infinity“ genannt, ist allerdings ein abstraktes Konstrukt ohne Koordinaten, das nicht als Public Key verwendet werden kann. Deshalb habe ich es ebenfalls aus dem gültigen Bereich ausgeschlossen.

Wenn ich eine Wallet programmiere, würde ich evtl. aus den von dir genannten Gründen auch den Bereich der kleinsten Private Keys ausschließen. Mindestens den Wert 1, da diesem der Public Key 1∙G = G entspricht, aber der Generator G bekannt ist und auffällig wäre.

Der Ausschluss aller Werte ≥ n scheint in der Kryptographie auch Konvention zu sein. Vermutlich auch bei den meisten Wallets, siehe unten. Schließlich gibt es diese Werte in der verwendeten zyklischen Gruppe einfach nicht.

Übrigens ist die ganze Diskussion dazu rein akademisch. Falls man in der Praxis eine Zufallszahl im Bereich 0… (2²⁵⁶-1) erzeugt, ist die Wahrscheinlichkeit sehr gering im ungültigen Bereich zu landen. Und zwar ähnlich gering, wie zufällig eine 12 Wort Seedphrase zu erraten. Schließlich ist n eben fast gleich 2²⁵⁶.

Selbst im BIP32, welches die Key Derivation in HD Wallets standardisiert, steht dazu:

In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2¹²⁷.)

D.h. auch beim Ableiten von Private Keys werden nur Werte innerhalb von 1…(n-1) als gültig behandelt.

2 „Gefällt mir“

Vielen Dank für deine immer sehr ausführlichen Antworten.

1 „Gefällt mir“