Hallo, ich habe mal eine allgemeine Verständisfrage zu Seed Phrase, Walletadresse, Puplic Key und Private Key:
Bisher habe ich meine Coins auf Paperwallets „gespeichert“. Darauf stand dann immer ein private Key und ein puplic Key. Soweit war alles klar.
Nun habe ich mir eine Bitbox gekauft und wollte, bevor ich die benutze, auch das mit der Seed Phrase verstehen.
Ich kann ,wenn ich mir beispielsweise unter BIP39 - Mnemonic Code eine zufällige 24 Wort Seedphrase erstelle, auch ein paar daraus abgeleitete publicKeys mit dazugehörigen Private Keys anzeigen lassen. Wenn ich mir jetzt aber einen Private Key davon raussuche und mir dann unter https://walletgenerator.net/ eine Paperwallet erstelle zeigt es mir einen anderen public key an.
warum?
und was ist der unterschied zwischen public Key und Walletadresse? ich dachte bisher, das wäre das selbe.
ok, hat sich geklärt. das eine ist wohl die compressed adresse.
Wenn ich ein gewisses Bitcoinguthaben an die Compressed adresse und eine an du unkomprimierte Adresse schicke, habe ich dann 2 wallets mit guthaben oder zeigt es beide transaktionen auf beiden adressen an?
und ich kann beide „guthaben“ mit dem private Key bewegen? stimmt das?
Unter den fetten Überschriften links steht jeweils folgendes.
Öffentliche Adresse (130 Zeichen [0-9A-F]):
Uncompressed Public Key (hexadezimal), hat immer 64 Byte + 1 Byte 04 am Anfang
Öffentliche Adresse komprimiert (66 Zeichen [0-9A-F]):
Compressed Public Key (hexadezimal), hat immer 32 Byte + 1 Byte 02 oder 03 am Anfang
Privater Schlüssel hexadezimal (64 Zeichen [0-9A-F]):
Private Key (hexadezimal), hat immer 32 Byte
Der Private Key gehört immer zum gleichen Public Key. Der Public Key kann aber unterschiedlich dargestellt werden, uncompressed oder compressed, um Platz zu sparen.
Bei den 1er und 3er Bitcoin Adressen können beide Darstellungen verwendet werden, führen aber zu unterschiedlichen Adressen. Bei den bc1 Adressen werden nur noch compressed Public Keys verwendet.
Die QR Codes sowie die zugehörige Zeichenkette darunter geben folgendes an.
QR Öffentliche Adresse:
Adresse, die aus dem Uncompressed Public Key berechnet wurde
(Uncompr. PubKey → SHA256 → RIPEMD160 → +VersionPrefix → Base58)
QR Öffentliche Adresse komprimiert:
Adresse, die aus dem Compressed Public Key berechnet wurde
(Compr. PubKey → SHA256 → RIPEMD160 → +VersionPrefix → Base58)
QR Privater Schlüssel WIF, 51 Zeichen Base58:
Private Key im Wallet Import Format, beginnt immer mit 5
(PrivKey → +VersionPrefix → Base58)
QR Privater Schlüssel WIF komprimiert, 52 Zeichen Base58:
Private Key im Wallet Import Format, allerdings so codiert, dass die Wallet erkennt, dass der zugehörige Public Key in der Darstellung als Compressed Public Key verwendet werden soll. Beginnt mit K oder L.
(PrivKey → +VersionPrefix → +Suffix 01 → Base58)
Gerade letzteres ist sehr irreführend, da der Private Key immer der gleiche ist. Er selbst ist nicht wirklich komprimiert (compressed). Er wird nur unterschiedlich codiert, um die Verwendung der jeweiligen Public Key Darstellung und der verwendeten Adresse klarzumachen.
Solange du den Private Key hast, kann auf jeden Fall nichts schief gehen. Du kannst notfalls auch die unterschiedlichen Darstellungen ineinander umrechnen. Bei den Adressen kann man im Gegensatz dazu nicht ineinander umrechnen.
ich hab schon probiert, die base58 konvertierung in hexadezimal umzurechnen. aber irgendwie klappts nicht.
egal.
Sorry, wenn ich etwas laienhaft rüberkomme. ich bin zwar neu im Forum, aber eigentlich schon ne Weile im Cryptospace (mittlerweile aber Bitcoinmaximalist) und denke, dass ich das ganze grundsätzlich verstanden habe. (für mich war halt der Public Key = Walletadresse, da ich praktisch mit dem eigentlichen publicKey nichts zu tun hatte)
Überhaupt kein Problem! Ich habe auch gerade selbst festgestellt, dass die Beschriftung auf der Paper Wallet noch seltsamer ist als ich in meinem letzten Beitrag gedacht habe.
Ich korrigiere das in meinem Beitrag oben, damit dort kein Unsinn steht.
Zum Herumprobieren kannst du z.B. diesen Rechner verwenden, der ausgehend vom Private Key den compressed und den uncompressed Public Key, sowie die zugehörigen Adressen berechnet:
→ Bitcoin address test tool – darkVane
Hier dein Test Private Key von oben:
59BEE6BC091BCA6DFD2DB93580CF4E5C7FA86B69CBD8EC823E1D217C35FE8AA7
Die Adresse, die aus dem compressed Public Key berechnet wird, wird an manchen Stellen tatsächlich als compressed Address bezeichnet. Das wusste ich nicht und ergibt für mich auch keinen Sinn, dient aber der Unterscheidung.
(im zweiten Link steht teilweise „private address“, was „private key“ heißen muss)
Jetzt verstehe ich auch deine Frage von oben, sorry!
Auf beiden Adressen würde erst einmal separates Guthaben liegen. Wenn du im Blockchain Explorer auf eine Adresse schaust, siehst du nicht das Guthaben der jeweils anderen Adresse.
Sobald du deine Paper Wallet in eine Software Wallet importierst oder sweepst, gibst du einen Private Key an. Je nachdem welche der beiden Private Key Darstellungen im Wallet Import Format (WIF) du dabei angibst („nicht komprimiert“ oder „komprimiert“, links und rechts unten auf deiner Paper Wallet), sagst du der Software welche der beiden Adressen und Public Keys sie verwenden soll.
Es kann aber sein, dass die Software Wallets heutzutage einfach trotzdem beide Adresssen überprüfen, egal welchen Private Key Darstellung du angibst. Da fehlt mir die Erfahrung mit Paper Wallets. Schließlich können beide Public Keys und beide Adressen aus dem einen Private Key abgeleitet werden, egal welche Darstellung du beim Import angibst.
Ja. Nachdem du den Private Key in eine Software Wallet importiert oder gesweept hast, rechnet die Software aus der angegebene Darstellung (komprimiert oder nicht) intern sowieso auf den rohen (nicht Base58 codierten) Private Key zurück. Dieser ist eindeutig, siehe z.B. Hex-Darstellung auf deiner Paper Wallet, und kann für beide Adressen verwendet werden.
@sutterseba, nachdem sich sonst sowieso niemand hier für so etwas interessiert, nerve ich dich mal ein bisschen.
Außerdem möchte ich das hier nochmal abschließend festhalten, falls es nochmal relevant werden sollte.
Gestern bin ich wieder mal von einem Punkt überrascht worden, wo ich vorher eigentlich dachte ich habe es komplett verstanden.
Mir war klar, dass man bei 1er und 3er Adressen den Public Key je nach Wallet uncompressed oder compressed angeben kann. Dabei sind das nur verlustfreie Codierungen, ohne Informationsverlust.
Ich dachte deshalb immer, dass die Wallet natürlich auf den richtigen (uncompressed) Public Key zurückrechnet, bevor sie hashed und Base58 codiert um die Adresse zu berechnen. Damit wäre die Adresse zu einem Private Key eindeutig.
Aber tatsächlich ist es so, dass der uncompressed oder compressed Public Key gehashed wird. Man erhält also je nach Vorliebe für uncompressed oder compressed Public Keys unterschiedliche Bitcoin Adressen zu einem einzelnen Private Key.
Dabei ist es egal ob man Paper Wallets, SW Wallets oder HW Wallets verwendet. Intern muss die Wallet sich immer festlegen, mit welchem Public Key Typ sie arbeitet.
Wusstest du das? Ich verstehe ehrlich gesagt nicht warum das so gemacht wurde. Ab den Bech32 Adressen (Native Segwit) wird nach Standard immer der compressed Public Key verwendet. Ab Taproot sogar ohne Vorzeichen-Prefix.
Das müsste auch bedeuten, dass man bei Import einer Seedphrase aus einer Wallet Software in eine andere trotz gleichen Derivation Paths und BIP39-Kompatibilität unterschiedliche Legacy Adressen erhalten könnte. Vermutlich prüfen die Wallets einfach beide Typen.
Jetzt wo du mich dran erinnerst - habe ich noch grob aus Mastering Bitcoin in Erinnerung. Aber das ist halt, wie du sagst, etwas das eigentlich niemanden interessiert.
Die compressed public keys wurden ja eingeführt um Transaktionsgrößen zu reduzieren. Natürlich muss man dann die „alte Variante“ trotzdem aufrecht erhalten, da es Nutzer gibt die Bitcoin auf diesen Adressen liegen haben.
Um dieses Problem (also dass Wallets bei Import nochmal eine zusätzliche Variante abdecken müssen) abzumildern implementieren die neueren Wallets im WIF einen Hinweis nach dem Motto:
„Hey, ich bin neu und cool, uncompressed nicht absuchen“
So wird unterschieden welche Public Keys bzw. welche Adressen die richtigen sind.
Aber das weißt du wahrscheinlich auch und du hast vollkommen recht, ich frage mich auch warum man das nicht eleganter und eindeutig gelöst hat. Da wir über Profis reden wird es schon irgendeinen Grund geben…
Es kann auch gut sein dass z.B. eine BlueWallet trotzdem alles absucht, denn die sucht beim Import ja so ziemlich alles ab.
Habe gestern das Buch „Bitcoin & Blockchain - Grundlagen und Programmierung“ von Andreas Antonopoulos bekommen und bin gerade eben dabei, etwas darin zu lesen. Und witziger Weise, musste ich ebenfalls die Passagen mit den WIF bzw. WIF compressed Formaten mehrfach lesen. Das ist darin zwar genauer erklärt, wirkt aber wirklich total verworren
Super, das ist bzgl. Einstieg in die Funktionsweise von Bitcoin das beste!
Ich habe da gestern auch reingeschaut und oben das Kapitel in der Online-Version verlinkt (hier). Der Teil ist allerdings wirklich etwas knapp gehalten. Vor allem wie Wallets damit umgehen wird nicht erklärt.
Das ist genau der Punkt, den ich nicht verstehe. Man hätte ja ruhig in Transaktionen, also in der Blockchain, compressed Public Keys zulassen können um Platz zu sparen. Im Endeffekt ist das nur eine Codierung.
Trotzdem hätte man sagen können, dass alle Wallets und auch die Validierer von Signaturen immer auf den uncompressed Public Key zurückrechnen sollen. Damit wären die Adressen eindeutig gewesen.
Wo ich es gerade schreibe, könnte allerdings genau das der Grund sein. Beim Validieren der Signaturen wäre es etwas mehr Arbeit für die Nodes, wenn diese aus allen compressed Public Keys zuerst wieder auf uncompressed zurückrechnen müssen. Das sind pro Public Key ein paar Additonen und Multiplikationen (egal) und einmal Wurzel ziehen modulo p (nicht ganz egal).
Mittlerweile wird auch ein Großteil an Wallet Software den neuen Standard unterstützen - und selbst wenn man dann was älteres importiert sieht die Software das sofort am WIF der auf das alte Verfahren deutet.
Beim nachlesen in Kapitel 4 ist mir gerade noch aufgefallen dass der WIF-compressed (der eben auf compressed public keys deutet) gar nicht komprimiert sondern sogar 1 Byte länger ist!
Mich interessiert das schon, aber es interessiert insofern niemanden da es zu keinen Problemen führt, zumindest sind im Forum noch keine aufgetaucht.
Man müsste von neuer Software auf veraltete wechseln um bei leeren bzw. anderen Adressen zu landen - und das würde man ja sowieso wenn man von bech32 oder P2SH auf Legacy wechselt.
Bei Paper Wallets sollte es auch keine Probleme geben da man die ja in neuer Software, die den WIF als uncompressed erkennt, importiert.
Kann mir kurz erklären, was das ist? Dadurch ändern sich auch die PrivateKeys unten in der Tabelle die aus dem Rootkey erzeugt werden.
Kurz der Hintergrund:
Ich habe mich mit meiner Mutter und meinem Bruder geeinigt, dass wir einen kleinen Teil unseres zukünftigen Erbes in Bitcoin umwandeln. Da sie hoffentlich noch 30Jahre Leben wird, könnte aus dem Teil sicher über die Zeit ein halbes Vermögen werden. Auf jedenfall Besser als, wenn es die 30 Jahre al Euro versauert.
Aber nun zu dem Punkt. Ich habe vor, den Seed in 3 Teile zu teilen, wodurch man mit 2 dieser Teile einen kompletten Seed hat. Ein Teil bekommt meine Mutter, einer mein Bruder und ein Teil bekomme ich.
Diese würde ich in Edelstahl gemeiselt verteilen. Nun brauche ich aber auch eine Walletadresse, an welche ich die Coins schicken kann. Ist es egal, welche Einstellung ich bei derivation Pfad einstelle? Mit dem Seed habe ich ja eigentlich zugriff auf alle Walletadressen, oder? Wenn ich beispielsweise den Seed mit der Bitbox wiederherstelle, sollten doch alle „Guthaben“ verfügbar sein.
Jetzt wo ich das gerade so schreibe. ich könnte den Seed doch auch direkt mit der Bitbox erstellen und dann dort eine Walletadresse aussuchen.
Die Antwort zur obrigen Frage wäre trotzdem Interessant.
Das könntest du nicht nur, das sollst du auch so machen. Der Sinn einer Hardware Wallet ist dass dein Seed und damit deine Schlüssel niemals in Kontakt mit dem Internet kommen.
Wenn du deinen Seed mit iancoleman generierst müsstest du das offline machen und den Rechner anschließend zerstören oder niemals für irgendwas anderes verwenden. Aber selbst das ist mit mehr Risiken verbunden, einfach dadurch dass kein Laptop darauf ausgelegt ist die Funktion einer Hardware Wallet zu ersetzen.
Da du aber bereits eine BitBox02 hast ist das auf jeden Fall der beste Weg deinen Seed zu verwalten. Iancoleman kannst du zum lernen und experimentieren benutzen, aber für mehr auch nicht.
Mit dem Derivation Path musst du eigentlich überhaupt nicht arbeiten.
Die BitBox02 generiert dir standardmäßig Native SegWit Adressen. Die sehen so aus:
bc1quswmq0t5yqekmkjqskv5u07f55cs98wjczt0rs
Das ist (von Taproot mal abgesehen) aktuell das beste und „neuste“ das du kriegen kannst. Also kein Grund daran manuell etwas ändern zu wollen.
Der Ableitungspfad ist dabei quasi ein Wegweiser wie man von der Wurzel (Seed) zu einem bestimmten Ast (Adresse) in der Baumkrone kommt.
Oder noch präziser ausgedrückt: Die Adressen sind Blätter eines Astes, und ein Ast wäre ein Account.
Als Beispiel der Pfad auf dem sich die erste Adresse befindet wenn du die BB02 neu einrichtest:
M/84'/0'/0'/0/0
84: Steht für BIP84, der zugrunde liegende Standard der auch für den Adresstyp verantwortlich ist.
Die zweite Adresse die du mit deiner BitBox02 generierst würde dann diesem Pfad entsprechen:
M/84'/0'/0'/0/1
Der 26. Private Key auf dem 3. Account würde diesem Pfad entsprechen:
m/84'/0'/2'/0/25
Wie gesagt: Für dich in der Nutzung ist das völlig irrelevant. Alles was du machst ist auf Empfangen klicken und das wars auch schon. Diese technischen Details sind interessant aber nicht notwendig für die sichere Benutzung.
Auch in 100 Jahren werden deine Enkel in der Lage sein mit deiner Mnemonic auf die entsprechenden Adressen zu schließen, auch wenn es bis dahin bereits neuere Adresstypen auf anderen Ableitungspfaden gibt (oder ein grundlegend neues Konzept).
Ähnlich habe ich das auch hier schon erklärt, da ging es um die Frage der Accounts:
Auch die Informationen oben zu compressed und uncompressed public keys sind für dich vollkommen irrelevant, ich habe vorgestern auch zum ersten Mal seit längerer Zeit wieder davon gehört.
Entscheidend ist dass du das grobe Konzept einer Wallet verstehst, da du bisher nur Paper Wallets mit einem Keypair gewohnt bist!
Das kannst du auf jeden Fall so machen. Vorher vielleicht den ersten Absatz von diesem Beitrag zu „Mnemonic Split“ durchlesen:
Ich hatte vor Jahren mal eine MyceliumApp und da gab ei so eine HD-Wallet mit Seed Phrase. Da hatte ich mich das erstmal damit beschäfftigt und die Funktion prinzipiell verstanden, dass aus dem Rootschlüssel die private Keys berechnet werden. Wahrscheinlich geh ich jetzt tiefer in die Materie, als ich eventuell müsste.
auch mit den UTXO hatte ich mich beschäfftigt, dass ich bei einer Transaktion plötzlich hohe gebühren hatte, (da wollte er 3 inputs zusammenfassen). PlanB twittert manchmal, wenn der memool relativ leer ist um seine UTXOs zu dezimieren.
Aber eine Frage habe ich gleich mal zu deinem Betrag dazu:
In deinem Beispiel schickt man einen Teil eines UTXOs an einen Freund, der andere Teil, wird automatisch an eine eigene neue Wallet geschickt. (dies managed vermutlich die BitboxApp).
Aber was passiert, wenn man von einer SingleWallet (beispielsweise von einer Paperwallet mit nur einem private Key) nur einen Teilbetrag „verschickt“. Wird der Rest als neuer UTXO an die gleiche Adresse geschickt?
bei vielen Walletapps kann man Paperwallets nur leeren, aber beispielsweise bei Mycelium kann man den private Key einscannen und dann auch nur Teilbeträge davon schicken.
Das kommt auf die Software an mit der man die Paper Wallet sweepen will (bzw. in dem Fall wäre es ja kein Sweep).
Wie du schon sagst sind Paper Wallets nicht darauf ausgelegt auf diese Weise verwendet zu werden, was einer der Gründe ist warum heute dringend davon abgeraten wird.
Entweder der Change geht an die Adresse des STXO zurück oder dir wird eine neue Change Adresse generiert. Entscheidend ist dann ob du Zugriff auf diesen Change hast oder nicht. Wenn man nicht aufpasst, und das ist schon vielen passiert, landet der Change auf einer Adresse die man nicht kontrolliert.
Richtig. Deine Wallet generiert automatisch eine Change Adresse über die du volle Kontrolle hast, da sie ebenfalls aus deinem Seed abgeleitet wird. Eine Change Adresse hat im Derivation Path eine extra abzweigung:
M/84’/0’/0’/1/0
… wäre die erste Change Adresse des ersten Accounts.
M/84’/0’/2’/1/6
… wäre die 7. Change Adresse des 3. Accounts.
Du kannst mit der Sparrow Wallet deine Change Adressen auch einfach anschauen. Meistens werden die aber versteckt um den Nutzer nicht unnötig zu verwirren. Die Wallet braucht diese Unterscheidung beispielsweise um dir bei einem eingehenden Change das nicht als „neue“ Transaktion anzuzeigen.
