(Im Anschluss an diese Frage .)
Um einen Bitcoin unbrauchbar zu machen, bestand die Antwort darin, eine erfundene Adresse auszuwählen. Da dies keine formelle Vernichtung von Bitcoins ist, besteht die Gefahr, dass die privaten Schlüssel gefunden werden, um diese „zerstörten“ Bitcoins auszugeben.
Wenn jemand eine Adresse vorschlägt, könnten die Leute vermuten, dass diese Adresse ausgewählt wurde, weil diese Person sorgfältig nach einer Adresse gesucht hat, die wie eine erfundene Adresse aussah.
Wie kann eine Adresse für die Bitcoin-Vernichtung ausgewählt werden, bei der jeder einigermaßen sicher sein kann, dass niemand die privaten Schlüssel kennt, um die zerstörten Bitcoins auszugeben?
Bitcoin-Adressen sind der Pubkeyhash (nicht Pubkey) plus Versions- und Prüfsummeninformationen, codiert in Base 58.
Bitcoin address = version + RIPEMD-160(SHA-256( Public Key )) + checksum
Die Schritte zum Konvertieren eines öffentlichen Schlüssels in eine Adresse finden Sie hier: https://en.bitcoin.it/wiki/Address
Da die Adresse den Pubkeyhash und nicht den eigentlichen Pubkey verwendet, können wir dies ausnutzen, indem wir einen ungültigen Pubkey hashen (einen, der unmöglich existieren kann) und so aus einem ungültigen Pubkey eine gültige Adresse erzeugen.
Also finden wir zunächst einen ungültigen öffentlichen Schlüssel. Alle gültigen öffentlichen Schlüssel beginnen unkomprimiert mit 0x04 und komprimiert mit 0x02 oder 0x03. Ein Pubkey, der mit einem anderen Wert beginnt, ist undefiniert, und daher gibt es keine mögliche Signatur, die erstellt werden kann, um diese Schlüsselanforderung zu erfüllen. Da das Ausgeben von Münzen das Signieren der Transaktion mit dem richtigen privaten Schlüssel erfordert, ist eine Adresse, die keinen bekannten privaten Schlüssel hat, nicht auszugeben. Durch die Verwendung eines öffentlichen Schlüssels, von dem bekannt ist, dass er keinen privaten Schlüssel hat, können andere bestätigen, dass kein privater Schlüssel existiert.
Ein gültiger öffentlicher Bitcoin-Schlüssel (keine Adresse):
04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
Ein ungültiger öffentlicher Schlüssel
0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Es gibt andere Möglichkeiten, einen bekanntermaßen ungültigen öffentlichen Schlüssel zu erzeugen. ECDSA-Schlüssel müssen unkomprimiert genau 65 Bytes oder komprimiert 33 Bytes lang sein, sodass ein Schlüssel mit einer anderen Länge ebenfalls ungültig ist. Bei unkomprimierten Schlüsseln muss der y-Wert korrekt aus dem x-Wert gebildet werden. Der Punkt muss auch auf der Kurve liegen. Es kann auch nicht über dem Modul für die Kurve liegen. Es gibt also viele Möglichkeiten, nachweislich ungültige Schlüssel zu erzeugen, aber es ist am besten, einen zu wählen, der offensichtlich ungültig ist. Dies ist wahrscheinlich der einfachste offensichtlich ungültige öffentliche Schlüssel.
0x00
Dieser öffentliche Schlüssel ist aus einer Reihe von Gründen ungültig (wird nicht durch den vom Generator multiplizierten privaten Schlüssel erzeugt, befindet sich nicht auf der Kurve, ist kein gültiger Punkt, aber noch einfacher, er hat kein gültiges Präfix und hat nicht die richtige Länge). .
Wichtig ist, dass dies nicht nur ein wahrscheinlich ungültiger Schlüssel ist, sondern ein nachweislich ungültiger Schlüssel.
Sie sollten Ihren ungültigen öffentlichen Schlüssel mit dem Referenzclient testen, um sicherzustellen, dass der Client ihn ebenfalls als ungültig meldet. Die Gültigkeit von Schlüsseln ist ein Konsensthema, daher wird sich dies nicht kurz vor einer Hard Fork ändern.
Sie fragen sich vielleicht, warum wir wollen, dass die Adresse gültig ist. Alle Kunden sollten die von den Benutzern angegebenen Adressen validieren, um einen versehentlichen Geldverlust zu vermeiden. Eine ungültige Adresse ist also auch nicht auszahlbar, aber die meisten Benutzer werden es unmöglich finden, Geld an die Adresse zu senden. Eine P2PkH-Adresse ist der Pubkeyhash mit Versions- und Prüfsummeninformationen, die in Base58 codiert sind.
Wenn Sie einem Bitcoin-Client eine Adresse zur Verfügung stellen, dekodiert er die Adresse zurück in den „rohen“ Pubkeyhash. Das Erzeugen einer gültigen Adresse bedeutet also, mit einem gültigen Pubkeyhash zu beginnen. Dies ist kein Problem, da der Hash von irgendetwas ein gültiger Hash ist. Clients wissen nicht, welcher Pubkey gehasht wird, um den Pubkeyhash zu erzeugen, da der zugrunde liegende Pubkey nicht bereitgestellt wird und Hash-Funktionen eine Möglichkeit sind.
Das Bitcoin-Netzwerk verifiziert nur, dass eine Adresse die richtige Form, Länge und die richtige Prüfsumme hat, wenn sie "validiert" wird. Das Erstellen einer Adresse aus einem Pubkey geht über den Rahmen dieser Frage hinaus, aber es gibt Dienstprogramme, und der obige Link enthält die Schritte. Der resultierende Pubkeyhash und die verschlüsselte Adresse werden vom Netzwerk und Client als gültig angesehen, es ist jedoch ein nachweislich unmöglicher privater Schlüssel erforderlich, um an diese Adresse gesendete Gelder auszugeben.
Jetzt kann ein Benutzer nur mit der Adresse (und dem dekodierten Pubkeyhash) nicht überprüfen, ob der zugrunde liegende Pubkey ungültig ist, also sollten Sie den rohen Pubkey zusammen mit der Adresse veröffentlichen. Benutzer können die Adresse mit jedem Bitcoin-Client oder -Tool neu erstellen und erhalten dieselbe Adresse, die Sie angeben. Benutzer haben jetzt eine vertrauenswürdige Möglichkeit, um zu überprüfen, ob die Münzen tatsächlich nicht ausgegeben werden können. Alle an die Adresse gesendeten Münzen können niemals ausgegeben werden und werden effektiv zerstört.
Technisch gesehen ist es möglich, aber unwahrscheinlich, dass mehr als ein öffentlicher Schlüssel dieselbe Bitcoin-Adresse hat. Dies wird als Hash-Kollision bezeichnet. Wenn der öffentliche Schlüssel p1 und der öffentliche Schlüssel p2 beide an dieselbe Adresse A hashen, können die privaten Schlüssel für einen dieser öffentlichen Schlüssel das Geld ausgeben. Die Wahrscheinlichkeit dafür ist jedoch sehr gering. Sofern der RIPEMD-Hash-Algorithmus nicht gebrochen ist, beträgt die Wahrscheinlichkeit, zwei öffentliche Schlüssel zu finden, die denselben Hash (Bitcoin-Adresse) erzeugen, 1 zu 2^160, was unsere Rechenleistung bei weitem übersteigt.
Die Verwendung einer "Nichts-in-der-Ärmel-Nummer" (wie eine einzelne Null, alle Nullen, einzelne sich wiederholende Ziffern, fortlaufende Zahlen, Ziffern von pi usw.) ist nicht erforderlich, da jeder ungültige öffentliche Schlüssel gleichermaßen unverbraucht ist, aber dies würde das Vertrauen der Öffentlichkeit stärken Sie haben noch keine Kollision gefunden (so unwahrscheinlich das auch ist).
Wenn Sie nur einen zufälligen ungültigen Schlüssel nehmen, sagen Sie:
00000fdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
Einige fragen sich vielleicht, warum Sie diesen speziellen Schlüssel gewählt haben. Die Befürchtung wäre, dass Sie diesen Schlüssel nicht zufällig wählen, sondern weil Sie auf eine Kollision zwischen diesem Schlüssel und einem gültigen Schlüssel gestoßen sind. Es gibt keine Möglichkeit zu beweisen, dass der Schlüssel zufällig ist, daher wird die Angst immer bleiben. Kryptografische Funktionen (wie RIPEMD oder SHA-256) verwenden häufig „nothing up my sleeve“-Werte, um sicherzustellen, dass keine Konstante gewählt wurde, um einen kryptografischen Fehler oder eine „Hintertür“ im Algorithmus zu aktivieren. Beispielsweise verwendet SHA-256 Konstanten für die Anfangswerte der Blocksegmente. Technisch könnte dies eine beliebige Zufallszahl sein, aber das würde zu Bedenken führen, dass die "Zufallszahl" nicht wirklich zufällig ist. SHA-256 verwendet also die ersten 32 Bit des Bruchteils der Kubikwurzel der ersten 8 Primzahlen. Dies ermöglicht eine Überprüfung, wenn eine Pseudozufallszahl benötigt wird. Es ist sehr unwahrscheinlich, dass zwischen dem Bruchteil der Kubikwurzel von aufeinanderfolgenden Primzahlen eine magische Eigenschaft besteht, die SHA-256 untergräbt.
http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number
Es ist jetzt einfacher, dies zu tun, indem eine OP_RETURN-Ausgabe (Nulldaten) verwendet wird, und es bläht den UTXO nicht mit Ausgaben auf, die nicht ausgegeben werden können, aber das Netzwerk weiß nicht, dass sie nicht ausgegeben werden können. Alle Gelder, die an eine Ausgabe gesendet werden, die OP_RETURN enthält, sind nachweislich nicht auszahlbar und das Netzwerk wird die Ausgabe von UTXO löschen. Das UTXO (unspent tx output set) ist eine kritische Ressource, die für die Validierung neuer Transaktionen und Blöcke erforderlich ist, sodass das Zerstören/Verbrennen von Coins mit UTXO eine verantwortungsbewusstere Nutzung dieser gemeinsam genutzten Ressource darstellt.
Es gibt vier grundlegende Möglichkeiten, die alle funktionieren:
Überlegen Sie sich eine Adresse, die die grundlegenden Plausibilitätsprüfungen besteht, aber intern ungültig ist. Sie können sicher sein, dass kein Schlüssel mit dieser Adresse übereinstimmen könnte.
Fügen Sie Zeichenfolgen in die Adresse ein, die weit über das hinausgehen, was jeder in einer Vanity-Adresse generieren könnte. Wenn zum Beispiel die Bitcoin-Adresse „FourScoreAndSevenYearsAgo“ enthält, liegt es eindeutig außerhalb der Möglichkeiten von irgendjemandem, einen entsprechenden privaten Schlüssel zu finden.
Verwenden Sie einen öffentlichen Schlüssel, der offensichtlich erfunden ist, z. B. einen, der nur aus Null-Bytes besteht oder alle aufeinanderfolgenden Ziffern von Pi enthält. Es liegt eindeutig außerhalb der Möglichkeiten von irgendjemandem, einen entsprechenden privaten Schlüssel zu finden. (Damit dieser funktioniert, müssen Sie den öffentlichen Schlüssel offenlegen.)
Verwenden Sie einen offensichtlich erfundenen Hash des öffentlichen Schlüssels. Dies funktioniert genauso wie die obige Option, aber die Schwierigkeit besteht darin, überhaupt einen öffentlichen Schlüssel mit einem solchen Hash zu finden, geschweige denn den entsprechenden privaten Schlüssel zu finden.
Wenn Sie ziemlich sicher sein wollen, dass niemand die Bitcoins abrufen kann:
Was ist der Haken? Da Sie normalerweise den öffentlichen Schlüssel aus einem privaten Schlüssel generieren und ihn ein paar Mal hashen würden, müsste man, um Münzen von der von Ihnen generierten Adresse abzurufen, in Punkt 1 eine so spezifische Nummer finden, dass nach den Punkten 2 und 3 würde Ihre falsche Nummer generieren. Die Wahrscheinlichkeit, dass Sie einen finden, liegt bei etwa 1 zu 2^160, was bei den derzeitigen Rechengeschwindigkeiten unmöglich ist. Je ordentlicher die Nummer ist, die Sie in Punkt 3 verwendet haben, desto mehr Leute würden glauben, dass es sich um eine offensichtlich gefälschte Adresse handelt.
Wenn Sie eine Adresse verwenden möchten, wäre es schön, eine Adresse zu generieren, die von einem Menschen als offensichtlich unverbrauchbar verifiziert werden kann, indem Sie einfach auf Base58 schauen. Wenn Sie sich diese Adressen ansehen, werden Sie sagen: „Wow, das ist offensichtlich unersetzlich.“
1CounterpartyXXXXXXXXXXXXXXXUWLpVr<- von der Gegenpartei verwendet
1ChancecoinXXXXXXXXXXXXXXXXXZELUFD<- von Chancecoin verwendet
Diese Adressen sind gekennzeichnet durch eine menschenlesbare Kennung am Anfang, gefolgt von einer großen Anzahl von X's. Um das Geld von einer solchen Adresse auszugeben, müssten Sie zuerst den Hash umkehren (unmöglich) und dann den privaten Schlüssel finden, der dem öffentlichen Schlüssel entspricht, den Sie erhalten haben (ebenfalls unmöglich).
Beachten Sie, dass die letzten sechs Ziffern dieser Adressen Base58Check-Prüfsummen sind. Dies ist der einzig knifflige Teil des Prozesses: Sie müssen über etwa 4 Milliarden Zeichenfolgen suchen, bis Sie eine gültige Base58Check-Zeichenfolge finden. Dies dauert jedoch nur einen Augenblick. Sie können diese Adressen einfach mit adamkrellenstein/unspendable auf GitHub generieren.
Inspiriert von dieser anderen StackExchange-Antwort .
Die von DeathAndTaxes beschriebenen Methoden sind angemessen. Die OP_RETURN-Methode ist eindeutig die beste, wenn Sie sich an die Bitcoin-Empfehlungen halten möchten.
Ich möchte jedoch eine alternative Methode vorstellen, bei der man Coins nachweislich verbrennen kann und auch genügend Informationen in die Adresse einfügt. Wir haben diese Methode in den ersten Versionen von OpenBazaar verwendet und sie wird "Fast-Kollisions-Münzenverbrennung" genannt.
Der De-facto-Standard für das Brennen von Münzen in Bitcoin ist ein OP-RETURN-Skript. Dieses Skript hat den wichtigen Vorteil, dass es zur Netzwerkskalierbarkeit von Bitcoin beiträgt, da es Full Nodes ermöglicht, ihre UTXO zu beschneiden, wenn Beweise für Burn-Transaktionen erkannt werden. Der Mechanismus, der dazu verwendet wird, ist einfach: Während ein UTXO für alle nicht ausgegebenen regulären Transaktionen beibehalten wird, kann der vollständige Knoten vermeiden, diese Transaktion vollständig zum UTXO hinzuzufügen, wenn eine OP-RETURN-Transaktion von einem vollständigen Knoten empfangen wird, da das OP- Das RETURN-Skript stellt einen Beweis dafür dar, dass der Betrag nicht ausgegeben werden kann, und daher kann keine zukünftige Transaktion diese baumelnde Ausgabe an ihre Eingabe anhängen; es handelt sich somit um eine permanent baumelnde Ausgangskante.
OP-RETURN-Skripte funktionieren, indem der erste Operator des Bitcoin-Skripts ein OP-RETURN ist, der eine sofortige Ausnahme bei der Ausführung des Skripts anzeigt und somit Ausgaben unmöglich macht. Nach dem anfänglichen OP-RETURN-Operator können die restlichen Skriptdaten Informationen darüber enthalten, warum die Münze gebrannt wurde, sodass unterschiedliche Anwendungen unterschiedliche Verbrennungen fordern können und damit die Zuordnung zu einem Konto möglich ist. Im Fall von OpenBazaar ist es beispielsweise wichtig, die verbrannte Menge mit einer OpenBazaar-GUID zu verknüpfen, die als nicht ausführbarer Code nach dem OP-RETURN eingefügt werden kann. Dass dieser Code nicht ausführbar ist, folgt daraus, dass er aufgrund der früheren Ausnahme niemals ausgeführt wird. Dem OP-RETURN-Ansatz fehlen jedoch bestimmte Usability-Eigenschaften, die wir in unserer OpenBazaar-Implementierung beibehalten wollten. Insbesondere aus Gründen der Einfachheit der Implementierung und Verwendung sowie aus Gründen der Trennung von Bedenken haben wir entschieden, dass OpenBazaar keine Bitcoin-Wallet-Implementierung enthalten muss. Stattdessen kann der Benutzer jede beliebige vorhandene Wallet-Software verwenden. Um Zahlungen zu leisten, die von OpenBazaar verlangt werden, entweder für Produktkäufe oder für Burn-Transaktionen, müsste der Benutzer seine Brieftasche direkt verwenden.
Heutzutage haben Brieftaschen nicht die Möglichkeit, OP-RETURN-Skripte auf brauchbare Weise zu erstellen. Die einzige Möglichkeit zum Erstellen von Brenntransaktionen besteht in der manuellen Ausgabe von Skriptbefehlen durch den Benutzer, die für einen durchschnittlichen Benutzer ohne Programmierkenntnisse verwirrend oder unmöglich auszuführen sein können. Darüber hinaus muss das OP-RETURN-Skript mit einer OpenBazaar-GUID verknüpft werden, was die Aufnahme dieser Fähigkeit in bestehende Wallets erschwert. Während eine Wallet-Software eine API dafür anbieten könnte, sind uns solche Implementierungen noch nicht bekannt.
Aus diesen Gründen haben wir einen alternativen Mechanismus zum Brennen von Münzen entwickelt, der einfache standardmäßige Pay-to-Pubkey-Hash-Transaktionen verwendet. Diese Transaktionen werden von den Bitcoin Full Nodes normal behandelt, daher werden sie nach Bedarf weitergegeben. Darüber hinaus ist es für normale Wallets einfach, solche Transaktionen zu erstellen, und Benutzer können den Vorgang leicht verstehen und die Zahlung vornehmen, ohne sich Sorgen machen zu müssen, dass ein unnötiger Geldbetrag übertragen wird, und ohne dass spezielle Programmierkenntnisse erforderlich sind.
Unser Schema zum Brennen basiert auf der folgenden kryptografischen Annahme, einem Widerstand gegen eine Beinahe-Kollision: Es ist rechnerisch nicht machbar, zwei Hash-Pre-Image-Werte x1, x2 so zu berechnen, dass:
||H(x1)- H(x1)|| < ε
Wobei die Norm den Hamming-Abstand zweier Strings bezeichnet und ε eine kleine Konstante ist, in unserem Fall 1. Diese Annahme wird stark durch die Tatsache gestützt, dass eine Hash-Funktion kryptografisch sicher ist; Wenn diese Gleichung nicht zutreffen würde, wäre eine Kollision gefunden worden, modulo ein Bit, was anzeigt, dass der Hash in fast alle seine Bits zerlegt ist.
Unter dieser Annahme für H = RIPEMD160 fordert unser Schema den Brenner auf, den öffentlichen ECDSA-Schlüssel, der seiner OpenBazaar-Identität zugeordnet ist, zu nehmen und ihn in eine Bitcoin-Adresse umzuwandeln, indem er dem regulären Schema für Bitcoin-Adressen mit dem Präfix 1 folgt. Reguläre Bitcoin-Adressen werden aus regulären Bitcoin-ECDSA-Schlüsseln generiert, wie im standardmäßigen Bitcoin-Adressengenerierungsalgorithmus gezeigt .
Um eine Adresse zu generieren, die nachweislich nicht ausgegeben werden kann, beginnt der Brenner mit seinem öffentlichen ECDSA OpenBazaar-Schlüssel und wendet denselben Prozess an. Der Brenner stört jedoch den ersten SHA256-Hash um ein Bit, bevor er ihn an den RIPEMD160-Hash weiterleitet. Insbesondere drehen sie das letzte Bit der Hash-Ausgabe um. Der Rest des Prozesses folgt identisch. Abschließend überträgt der Burner die Menge an Coins, die er verbrennen möchte, an diese generierte Adresse. Ich werde nun die Eigenschaften Korrektheit, Eindeutigkeit und Sicherheit für dieses Schema veranschaulichen.
Korrektheit . Um die Korrektheit des Brennens zu überprüfen, führt ein Dritter die gleiche Transformation wie der Brenner durch. Sie beginnen mit dem öffentlichen ECDSA-Schlüssel des OpenBazaar-Knotens, dessen Vertrauen sie überprüfen möchten, und folgen dem Prozess der Bitcoin-Adressgenerierung, wobei sie die gleiche Störung anwenden wie der Brenner nach der SHA256-Phase. An der endgültigen Bitcoin-Adresse angekommen, überprüft der Prüfer die Blockchain auf Geld, das an diese Adresse gesendet wurde. Daraus folgt, dass die Verbrennung, die ein ehrlicher Brenner durchführt, von einem ehrlichen Verifizierer korrekt verifiziert wird. (Dies ist ein erheblicher Vorteil im Vergleich zu alternativen Schemata, die keine warum-verbrannten Informationen enthalten, wie z. B. Nichts-in-den-Ärmel-Adressen.)
Einzigartigkeit . Unter der Annahme, dass RIPEMD160 schwer rückgängig zu machen ist und die Tatsache, dass SHA256 eine kryptografisch sichere Hash-Funktion ist, Annahmen, die bereits von Bitcoin getroffen wurden, folgt die Eindeutigkeit der Brennadresse für jeden OpenBazaar-Schlüssel direkt.
Sicherheit . Damit dieses System sicher ist, müssen wir beweisen, dass das verbrannte Geld von niemandem tatsächlich ausgegeben werden kann. Wenn das Geld ausgegeben werden könnte, müsste der Spender tatsächlich den privaten Schlüssel kennen, der mit einem öffentlichen Schlüssel verbunden ist, der zu dem gestörten SHA256-Wert gehasht wird. Dies würde jedoch die Generierung einer Beinahe-Kollision in RIPEMD160 ermöglichen, da der öffentliche Schlüssel, der zum Ausgeben des verbrannten Geldes verwendet werden kann, und der öffentliche Schlüssel der OpenBazaar-Identität Vorabbilder von Hashes darstellen würden, die sich nur um ein Bit unterscheiden. Aus der Fast-Kollisionswiderstandsannahme schließen wir, dass dies rechnerisch nicht machbar ist.
Die Fast-Kollision-Methode des Münzverbrennens stellt die Skalierbarkeit der Bitcoin-Software vor Herausforderungen. Wir haben uns in OpenBazaar aus zwei Gründen nicht mit solchen Herausforderungen befasst. Erstens waren wir der Meinung, dass Bitcoins Skalierungsfehler angesichts der massiven motivierten Community-Nutzung unseres Primitivs ein Sicherheitsproblem für Bitcoin selbst darstellt, das angegangen werden muss, ohne dass die Spieler sich fair gegenüber dem System verhalten müssen. Dies ist ein Problem für Bitcoin, nicht für OpenBazaar. Ist Bitcoin mit solchen Mitteln anfällig für Denial-of-Service-Angriffe, muss der Einsatz von Bitcoin als Zahlungssystem überdacht werden.
Zweitens, was am wichtigsten ist, weil wir das Bitcoin-Ökosystem unterstützen und Vorschläge zur Lösung seiner Skalierbarkeitsprobleme machen möchten, können sie tatsächlich eliminiert werden, wenn Proof-of-Burn-Transaktionen von dem Pre-Image vor der Störung begleitet werden. Das begleitende Vorabbild stellt einen Beweis dafür dar, dass das Geld unverbrauchbar ist, ähnlich wie OP-RETURN-Skripte einen Beweis für die Unverbrauchbarkeit darstellen. Da diese Pre-Images im OpenBazaar-Netzwerk öffentlich verfügbar sein werden, können vollständige Bitcoin-Knoten das OpenBazaar-Netzwerk nutzen, um kürzbare UTXO-Ausgaben zu erkennen, die einen Proof-of-Burn durch Fast-Kollisions-Pay-to-Pubkey durchführen, falls OpenBazaar weit verbreitet wird -Hash-Skripte. Trotzdem,
Insgesamt sollten jedoch, sobald die OP_RETURN-Methode zu einer verwendbaren Alternative wird, die anderen Brennmethoden aus Gründen der Eleganz und Skalierbarkeit eliminiert werden.
Eine Alternative zum Generieren einer Adresse ist die Verwendung einer gültigen Adresse, von der bekannt ist, dass es fast unmöglich ist, Coins abzurufen, z. B. https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE .
Dies ist so gut wie zerstört, denn wenn jemand den privaten Schlüssel für diese Adresse zurückentwickeln könnte, könnte er aufgrund der Vanity-Länge dieselbe Methode verwenden, um den privaten Schlüssel für jede Adresse zurückzuentwickeln. Oder sie hatten Glück, so wie es Glück ist, ein Jahr lang jede Woche den Jackpot im Lotto zu gewinnen.
Sie können die Adresse mit vanitygenoder generieren und den privaten Schlüsselvanitygen-plus ignorieren . Lesen Sie hier mehr darüber: https://en.bitcoin.it/wiki/Vanitygen
Z.B
$ ./vanitygen 1Love
Difficulty: 4476342
[48165 K/s][total 2080000][Prob 37.2%][50% in 21.2s]
Pattern: 1Love
Address: 1LoveRg5t2NCDLUZh6Q8ixv74M5YGVxXaN
Privkey: 5JLUmjZiirgziDmWmNprPsNx8DYwfecUNk1FQXmDPaoKB36fX1o
Verwenden Sie einfach die Address, speichern Sie nicht die Privkey.
Steven Rose
Tod und Steuern
Earlz
Willtech