Cricktor

Hehe, wieso leider? Bisher fand ich den Nutzen von ChatGPT-Zitaten oder -Inhalten hier im Forum äußerst überschaubar, um es mal höflich zu formulieren.

Du schreibst ja nicht immer BS, zwinker, zwinker. Fehlt dir 'was oder warum die Nachfrage?

Single Point of Failure! Stürbest du plötzlich, käme Niemand mehr an deine Coins. Das Verschlüsselungspasswort ist ein weiteres Element, das man nicht nur in seinem Gedächtnis behalten sollte. Falls doch: weiterer Single Point of Failure und Rezept für Desaster. Finde ich problematisch. Hoffentlich! Man kann auch eine Watch-only Wallet einrichten, die man täglich, wöchentlich oder welches Intervall einem Peace of Mind gibt, kontrollieren kann. Die einzige Gefahr, die von so einer Watch-only Wallet ausgeht, ist, daß sie in fremde Hände fallen kann. Das kann man aber leicht verhindern, z.B. mit einem verschlüsselten TAILS mit persistenten Datenbereich. Verliert man hier das Passwort vom TAILS-Bootstick, verliert man nur die Watch-only Wallet, die man einfach mit dem Extended Public Key der Wallet wiederherstellen kann. Easy-peasy Überwachung, kostenlos und privacy-freundlich dank Tor.

Nur so als Zwischenruf: der initiale Blockchain-Sync lässt sich beschleunigen, wenn man während des Syncs den dbcache-Parameter in der bitcoin.conf je nach RAM-Ausbau möglichst hoch setzt (meines Wissens ist der Default-Wert 450 (MB)). # Set database cache size in megabytes; machines sync faster with a larger cache. Recommend setting as high as possible based upon machine's available RAM. dbcache=1000 RaspiBlitz setzt z.B. ab 4GB RAM einen dbcache=2560, für einen 8GB RAM Raspi würde ich dbcache=4096 oder 6072 ansetzen. Bei der aktuellen Umbrel-Version kann man den Wert für den DBCache auch über die Web-Oberfläche ändern: Bitcoin Node App öffnen und die drei Punkte rechts oben anklicken unter "Advanced Settings" kann man dann beim Punkt "Cache Size (MB)" den Wert hochsetzen Nicht vergessen den dbcache-Wert wieder zu reduzieren bzw. auszukommentieren, wenn der Sync fertig ist.

Folgende Fragen hätte ich an den TE: Hast du eine halbwegs umfassende Risikoanalyse gemacht? Zumindest die wahrscheinlichsten Risiken, die zu einem Verlust deiner Bitcoins führen können. Daraus leiten sich dann geeignete Sicherungsmaßnahmen ab, die alle wesentlichen Risiken kompensieren. Tamper Evidence Bags sind schonmal nicht schlecht. Hilft insbesondere, wenn du alle deine Sicherungsorte kontrollieren kannst (einer wird ja wohl dein Zuhause sein). Kannst du es in einem halbwegs vernünftigen Zeitintervall, z.B. viertel-, halbjährlich, jährlich? Wer weiß alles von deinen zwei Sicherungsorten? Deine optionale Mnemonic Passphrase ist hoffentlich gut dokumentiert und ebenfalls redundant abgesichert, aber keinesfalls in der Nähe deiner Mnemonic Recovery Wörter!? Ist für deine Hinterbliebenen alles narrensicher dokumentiert und zwar so, daß diese Dokumentation kein Single Point of Failure wird? Ist sichergestellt, daß deine Hinterbliebenen zuverlässig diese Dokumentation bzw. Anleitung zur Recovery deiner Bitcoins auch erhalten und verstehen werden? Sind deine Hinterbliebenen bzw. Erben auch in der Lage, mit den Bitcoins "umzugehen"? Zu komplizierte und verschachtelte Sicherungen sind häufig ein Rezept für späteres Desaster, insbesondere wenn die erforderliche Dokumentation nicht gut und sicher genug mit berücksichtigt und/oder nicht up-to-date gehalten wird. Wieviele Menschen wissen, daß du u.U. signifikante Mengen an Bitcoins besitzt? Je weniger davon wissen und es auch nicht herumposaunen, desdo unwahrscheinlicher ist ein 72er-Maulschlüsselangriff auf dich oder die Mitwisser. Eine Art Opfer-Wallet ist meines Erachtens nur sinnvoll, wenn die Wahrscheinlichkeit relevant ist, daß einer der Sicherungsorte der Recovery Wörter tatsächlich kompromittiert werden kann. Dann ist aber vielleicht einer der Sicherungsorte suboptimal. Plausible Deniability ist nur nötig, wenn man zuvor "Fehler" gemacht hat und ein Zwitschervogel ist. Weitere Anregungen zur sicheren Verwahrung deiner Coins kannst du dir vielleicht hier holen: https://www.smartcustody.com/ Meines Erachtens unnötig und du gibst Wissen über deine Wallet in fremde Hände, was selten gut ist.

Es kann davon abhängen, um welchen Unterhalt es geht. Dazu schreibst du keine Details. Im Falle von Kindesunterhalt kommt es auf die individuelle Situation an, zu deren Einschätzung du auch nicht genug schreibst, wobei ich natürlich auch keine Rechtsberatung geben kann. Du kannst im Falle von Kindesunterhalt ja z.B. mal hier schauen, da hat man einige Anregungen, in welche Richtung die Sache so geht: Kindesunterhalt/Elternvermögen/Leistungsfähigkeit (dauert übrigens nur Sekunden bei Mutter Google mit Suchbegriffen a la "Anrechnung Vermögen Unterhalt" o. Ä. mehr als genug Treffer zu generieren, die halbwegs in die richtige Richtung gehen; das sollte eigentlich Jede/r selbst hinbekommen). Generell und mit der Düsseldorfer Tabelle werden die eigenen Einkünfte betrachtet. Allerdings ist man mit Vermögen und z.B. Einkünften am oder unter dem Minimum nicht raus aus der Nummer, insbesondere wenn man seinen Lebensstil teilweise oder größtenteils aus der eigenen Vermögenssubstanz finanziert. Dann scheinen nämlich Gerichte in Streifällen den tatsächlichen Vermögensverbrauch im Jahr für die Unterhaltsleistungsfähigkeit heranzuziehen. Wäre ja auch sonst etwas seltsam und gefühlt "ungerecht". Es gibt auch kein Gesetz, das die Verwertung von vorhandenem Vermögen für die Leistungsfähigkeit des Unterhaltsverpflichteten verbieten würde, soweit ich weiß. Spätestens, wenn das Sozial- oder Jugendamt Ersatzleistungen für Unterhaltsverweigerer oder bei Minderleistungsfähigkeit zahlen muss, kommen die Ämter schnell auf den Plan, holen sich ggf. 'nen Titel (oder der/die Unterhaltsbedürftige) und dann wird eigenes Vermögen des Unterhaltsverpflichteten ganz schnell angerechnet. Kommt nur darauf an, wie schnell oder langsam die Mühlen mahlen.

Speichern bedeutet meist, daß die Recovery Wörter auf einem Online-Device abgelegt werden, wo für deren sichere Verwahrung keine Garantie besteht, daher am besten nicht speichern, sondern aufschreiben ggf. in Metall stempeln, ausschließlich offline ablegen! In den seltensten Fällen muss man bei einer üblichen HD-Wallet Private Keys überhaupt anfassen oder sich anzeigen lassen, schon garnicht speichern. Also lässt man die Kasperei mit Private Keys bei einer HD-Wallet auch am besten sein. Wenn doch, dann nur auf einem Offline-Gerät, wo jegliche digitalen Spuren anschließend sicher entsorgt oder vergessen werden. THIS! Eine Wallet, die das nicht erzwingt, kann und sollte man nicht ernst nehmen. Diese Convenience-Scheiße führt bei Usern, die die Wichtigkeit der Recovery Wörter nicht verstehen, nur dazu, daß die Offline-Ablage der Recovery Wörter auf den Sankt Nimmerleins-Tag verschoben wird. Ein Rezept für späteres Desaster, wie man hier anschaulich sehen kann.

Hat der USB3-NVMe-Adapter eine eigene Stromversorgung? Wenn nicht, zieht diese NVMe-SSD sicherlich sporadisch zuviel Strom bzw. bekommt den nicht vom Raspi und hängt sich auf. Der Raspi kann für alle USB-Schnittstellen in Summe max. ~1,2A Strombudget geben und deine Gen4 NVMe wird in Spitze stromhungriger sein. Ich bin mir recht sicher, daß das die Ursache für deine Abstürze ist. Die von dir zitierte Fehlermeldung deutet auch in diese Richtung, daß der Datenträger bzw. sein Interface zickt. Testen kannst du es, indem du einen IO-Last-Benchmark machst, also möglichst die SSD ordentlich unter Dampf nehmen. Sollte dann zügiger und reproduzierbar abstürzen... Abhilfe: einen Adapter mit eigener Stromversorgung verwenden oder einen powered USB3-Hub dazwischen schalten, der genug Saft liefern kann, so daß die SSD glücklich ist. Kannst auch in den Specs der SSD nachsehen, wie deren Strombedarf ist. Ich bin mir recht sicher, daß sich das mit dem Raspi beisst.

Etablierte Software-Wallets verwenden, am besten auch in Kombination mit einer Hardware-Wallet, die die zentralen kryptografischen Wallet-Geheimnisse sicher vor Malware schützt. Über Jahre gereifte Wallet-Software wird sehr wahrscheinlich anfängliche Implementierungsschwächen abgelegt haben. Open Source Wallets erlauben die Kontrolle, ob kritische Krypto-Bereiche sicher implementiert sind. (Open Source ist keine Garantie für Fehlerfreiheit, aber wenigstens kann man Fehler finden, wenn man dazu in der Lage ist. Bei Closed Source ist es weitgehend eine Black Box.) Als normaler User muss man beim Ausgeben kein Address Reuse betreiben, da dies auch schon aus Privacy-Gründen nicht empfohlen wird.

Red Flags, wo man nur hinschaut. @Johnny_BTC, wo hast du das denn aufgetan?

Interessantes Paper. Danke dafür! Das Geblubber von Fefe lasse ich mal außen vor. Also bekannt ist ja schon länger, daß Nonce-Reuse bei Signaturen mit demselben Private Key, diesen praktisch trivial ermittelbar macht. Deshalb ist Nonce-Reuse ein No-Go. Deshalb ist Address-Reuse mit einem gewissen Risiko behaftet, wenn eine Nonce-Kollision nicht ausgeschlossen werden kann (funktioniert im Grunde genommen nur zuverlässig, wenn die Nonce wirklich zufällig wäre; wirklich zufällig und Computer beißen sich aber). So tief bin ich noch nicht in ECDSA hineingestiegen, aber jetzt interessiert mich doch, wie groß und wie genau die Nonce für ECDSA-Signaturen generiert wird. Spannendes Thema! So wie ich es bisher verstehe, nutzt der Angriff Designschwächen bzw. eine gewisse Korrelation zwischen den verschiedenen Nonces bei multiplen Signaturen mit demselben Private Key. Korrelationen können z.B. bei Verwendung schlechter PRNGs mit zu kleiner Periode o.ä. Schwächen für die Nonce-Generierung auftreten. Nicht so leicht verdaulicher Stoff in dem Paper...

Nur damit das für dich klar ist: du musst auf keinen Fall deine (Wallet) Recovery Wörter in MetaMask eingeben. Du darfst deine Recovery Wörter nicht auf einem potentiell unsicheren digitalen Gerät, das möglicherweise online gehen kann, eingeben/verarbeiten, schon garnicht auf einer Online-Webseite. Geh' behutsam vor und versuche vorher erst die durchzuführenden Schritte zu verstehen!

Achso, OK also als BEP20 Token über die BSC an den Ledger Nano, wo der Token aber nur als ERC20 angezeigt werden kann. Hast du ein Binance-Konto? So aus dem Stegreif und unausgearbeitet: du verbindest MetaMask mit deinem Ledger Nano X. Soll heißen: du erstellst keine neue Wallet, sondern MetaMask soll die Wallet nutzen, die auf dem Nano X schon drauf ist. Dein Nano X hat den Private Key für die Empfangsadresse. MetaMask kannst du jetzt so einrichten, daß MetaMask den Token als BEP20 "sehen" kann. Dann solltest du die LABS@BEP20 z.B. auf dein Binance-Konto schicken können. Von dort kannst du sie dann als ERC20-Token über die ETH-Chain an deinen Nano X senden. Details, wie du die LABS-Token als BEP20, also auf der Binance Smart Chain, in MetaMask sichtbar machst, muss ich dir schuldig bleiben. Aber dazu gibt es auch einige Themen hier im Forum. Dieses Thema Coins/Token auf dem falschen Transportnetzwerk zu versenden, ist ja nicht neu und schon öfter hier behandelt worden. In der Binance Academy gibt es auch Anleitungen dazu, insbesondere wie man mit MetaMask das hinbiegt, woweit ich mich erinnere. Suchfunktion hier benutzen und auch die Sachen in der Binance Academy versuchen zu verstehen. Wenn dir etwas unklar ist, dann einfach konkret und vernünftig hier fragen.

Um welchen Token geht es? Wird der Token (auf ERC20) auch auf dem Ledger Nano unterstützt? Den Token auf BEP20 siehst du in deiner Ledger Nano Wallet? Ist übrigens vielleicht nicht die beste Strategie, sich in die Anfänger-Hängematte zu legen und zu hoffen, daß schon alles gut gehen wird, wenn man nicht wirklich versteht, was man da tut. Sicher, Fehler machen alle mal, aber gerade als Anfänger sollte man doch extra vorsichtig sein und doppelt und dreifach prüfen, ggf. auch vorher fragen, wenn einem etwas nicht klar ist. Oh, vorher selbst recherchieren und sich aufschlauen, ist ein noch viel besserer Plan und befriedigender obendrein, macht aber auch ein wenig Mühe.

Es soll sogar zwei Apps geben, eine für Neo Legacy und eine für Neo N3. Ledger Live ist die aktuellste Version? Firmware auf den Nano X ist auch die aktuellste Version? Das wird ja in dem von dir verlinkten Artikel als Voraussetzung angeführt. (Ist ja Standard-Blabla bei Ledger...)

Du schreibst nicht, auf welcher Plattform du Ledger Live benutzt. Irgendwo las ich auch schon davon, daß irgendwelche übereifrigen Virenscanner die Kommunikation von Ledger Live mit einem Nano gestört haben, bin mir aber nicht besonders sicher, ob das wirklich so war. Andere USB-Ports probiert? Am besten keine USB-Hub verwenden. Andere hochwertige USB-Kabel probiert? Original Ledger-USB-Kabel verwendet? Details über Details, Fragen über Fragen...

Ist die Frage ernst gemeint oder wie stellst du dir das bei einer Closed-Source Wallet vor? Coinomi hat zwar ein Github-Repo, aber da ist von der Wallet weit und breit keine Spur, sondern nur geforkte BIP-39 Tools, soweit ich das überblicke. Auch die Coinomi-Webseite versucht mit allen möglichen Features zu punkten, nur nicht damit, daß man in die Quellen blicken könnte. See the source, Luke! (Frei nach einem ältlichen Jedi-Meister...) Eine Closed-Source Wallet würde ich nur für unwichtige Shitcoins und geringe Werte im Notfall in Betracht ziehen, am besten auch nur in Verbindung mit einer anbindbaren Hardware-Wallet, damit man wenigstens noch ein Minimum an Kontrolle behält und keiner Black-Box die Private Keys überlassen muss.

Die ACH, die du über die ETH Blockchain versendet hast, sind vermutlich "universeller" nutzbar, aber der Transport ist teurer. Falls du die z.B. wieder zurück zu Coinbase schicken möchtest, bleibt dir nur der Transfer über Ethereum, da Coinbase die Binance Smart Chain nicht unterstützt. Binance wiederum, als Betreiber der Binance Smart Chain (BSC), erlaubt dir auch den günstigeren Transfer über die BSC, wofür die BNB als Gas brauchst. Wenn du ACH über die BSC auf deinen Ledger transferierst, was du ja erfolgreich getestet hast, solltest du beachten, daß du diese ACH dann wahrscheinlich nur wieder zurück zu Binance schieben kannst, da nur wenige andere Transferziele die BSC unterstützen. Beachtest du das nicht oder vergisst es, kann es dir passieren, daß du ACH (oder andere Coins/Token) über die BSC quasi ins Nirvana verschiebst, prominentes Beispiel wäre Coinbase. Technisch sind die Coins/Token auf der BSC nicht verloren, aber z.B. Coinbase wird keinen Finger rühren, solche Coins/Token wiederherzustellen. Das schreiben die ganz offen in ihren Bedingungen, andere Börsen tun dasselbe. Es wäre nett von dir, wenn du mal mit Punkt und Komma schreiben könntest. Das erleichtert das Lesen und das Verstehen. Du fragst nach Antworten, da ist es nicht zuviel verlangt, wenn du es den Antwortenden ein wenig einfacher machen könntest, dir sprachlich zu folgen. BNB ist keine Börse, sondern der native Coin der Binance Smart Chain. Analog wie ETH der native Coin der Ethereum Blockchain ist. Die BSC wird im Wesentlichen von Binance kontrolliert und wenn Binance hops geht, ist die BSC sehr wahrscheinlich Geschichte. Ja, Transfers auf der BSC sind in der Regel wesentlich günstiger als über Ethereum. Es ist allerdings nur dann sinnvoll, wenn deine Transferziele/Börsen auch sicher die BSC unterstützen. Schiebst du deine Coins ausschließlich von Binance --> deinem Ledger, später wieder --> Binance, könntest du auf der BSC bleiben und von den günstigeren Transferkosten profitieren. Du darfst allerdings niemals den Fehler machen, solche Coins/Token_auf_BSC z.B. zu Coinbase oder anderen Börsen zu schicken, die keine BSC unterstützen und dies wahrscheinlich auch in absehbarer Zeit nicht tun werden. Ach ja, nicht zu vergessen ist auch, daß deine BSC-Coins/Token auch am Schicksal von Binance gebunden sind. Ist dir das zu heikel: bleib' auf der ETH-Chain.

Eine Bitcoin HD-Wallet, die auch dein Ledger Nano verwendet, hat normalerweise viele Empfangsadressen. Normal ist, daß dir stets eine neue Empfangsadresse generiert wird, wenn du eine für einen Empfang anforderst. Ziel ist, Privacy zu maximieren, indem eine Adresse nur für genau zwei Vorgänge verwendet wird: 1. den Empfang eines Coins und 2. das Versenden des Coins; danach wird normalerweise diese Adresse nicht mehr verwendet. Hinzu kommt, daß aufgrund des UTXO-Transaktionsmodells von Bitcoin, Wechselgeld-Adressen in einer Wallet benötigt werden. Nämlich immer dann, wenn bei einem Bezahlvorgang der exakt benötigte Coin-Betrag nicht zur Verfügung steht. Ist so ähnlich wie mit normalem Geld. Du zahlst mit einer bestimmten Stückelung an Münzen und/oder Scheinen und erwartest natürlich, das Wechselgeld zurückzubekommen, wenn man für den Zahlbetrag keine genau passenden Münzen und Scheine hat. Wenn du lernen möchtest, wie Bitcoin funktioniert, dann: https://learnmeabitcoin.com Kannst hier natürlich auch konkrete Fragen stellen, die schon Jemand beantworten wird. Wenn du deinen Extended Public Key (xpub..., ypub... oder zpub...) deiner Ledger Nano Wallet z.B. in https://bitcoinexplorer.org eingibst, bekommst du auch den vollständigen Bestand deiner Wallet zu sehen (ein paar Feinheiten sind da aber zu beachten). Aber du solltest dir im Klaren sein, daß du mit Preisgabe deines Extended Public Keys deiner Wallet auch die Hosen runterlässt. Aus so einem Extended Public Key lassen sich nämlich sämtliche Adressen (auch zukünftige) deiner Wallet ableiten. Ledger Live ist manchmal eine ziemliche Schrott-Software, vorallem wenn die Synchronisation aus welchen Gründen auch immer scheitert. Aber Ledger-Nutzer akzeptieren diesen Zustand irgendwie. Als Blockexplorer für Bitcoin würde ich mich auf bitcoinexplorer.org oder mempool.space beschränken, auch wenn blockchair.com für bestimmte Dinge durchaus seine Vorzüge hat, früher aber ein deutlich besseres UI hatte. Heute scheinen die ausschließlich für Smartphones gemacht zu sein, nervig.

War dann wohl zuerst mind. 10000sat, da sonst kein autom. Kanal geöffnet wird. Die Empfangskapazität kannst du dir in der Phoenix Kanal-Liste einsehen. Der größere Betrag hat sehr wahrscheinlich die Liquidität deines ersten Kanals überschritten, so daß die Phoenix Wallet selbst entschieden hat, einen zweiten Kanal zu öffnen. Dein anfänglicher Vorsichtstest war nachvollziehbar, aber für die Arbeitsweise der Phoenix-Wallet nicht zielführend, außer daß du getestet hast, daß dein Transfer nicht im Nirvana landet. Fast schon logisch, da du ja mindestens zwei Kanäle offen hast und die vorhandene Empfangsliquidität für den dritten Kleinbetrag locker ausgereicht hat. Nein, die Kanalkapazität ist etwas höher. Ich kann dir aber nicht sagen, wovon die genau abhängt (algorithmisch festgelegt oder abhängig von vorhandenen UTXOs bei ACINQ). Ich habe mir heute auch die Phoenix Wallet installiert, weil ich @Amsis Gewinnspiel-Invoice bezahlen wollte. Die Bezahlung über meine RaspiBlitz-LN-Node hat nicht funktioniert, über zwei andere Lightning Wallets ebenfalls nicht. Dann habe ich mir zum Testen die Phoenix Wallet installiert und konnte von einer der davor verwendeten Lightning-Wallets problemlos auf meine eigene Phoenix Wallet einzahlen, anfangs knapp 61k Sats, die ich auf coinos.io noch hatte. Dadurch kamen auf meinem ersten Kanal der Phoenix Wallet 57700 Sats Endbetrag an mit einer Kapazität von ~83,5k Sats. Dann habe ich noch Sats von meiner RaspiBlitz-LN-Node nachgeschoben, um 61k Sats in der Phoenix zu haben, was auch einwandfrei geklappt hat. @Amsis Invoice konnnte ich dann aber immer noch nicht aus meiner Phoenix Wallet bezahlen, was dann etwas nervig war. Das zu debuggen, gehört dann aber nicht hier rein. Das kläre ich mit Amsi per PN. Phoenix ist einfach und erfordert recht wenig technisches Knowhow vom Anwender, aber ich seh' schon die Uninformierten über die 3k Kanalgebühr meckern, weil sie den Mechanismus nicht verstehen, wieso die ggf. wiederholt anfallen (können). Gut finde ich, daß es non-custodial ist, das war es dann aber auch schon, zumindest aus meiner Sicht. Die Kanalautomatik ist bei Phoenix standardmäßig aktiv, kann aber in den Optionen abgeschaltet werden. Allerdings sollte man dann auch wissen, welche Folgen das hat. Eingehende Zahlungen bedienen maximal die vorhandene Kanal-Liquidität, alles darüber lässt die Zahlung scheitern. P.S. Eine neue Invoice von @Amsi konnte ich aus meiner Phoenix Wallet dann erfolgreich bezahlen. Warum auch immer die erste Invoice wiederholt mit mehreren verschiedenen Lightning-Wallets scheiterte, bleibt dann wohl ein Geheimnis von Phoenix.

Da kann man nur raten, da die von dir gegebenen Informationen keine fundierte Aussage zulassen. Normalerweise wird empfohlen, auf einer Eingangsadresse nur einen UTXO (Unspend Transaction Output, quasi einen Coin) zu haben. Aber man kann beliebig viele UTXOs an eine Empfangsadresse senden, wenn man das so möchte. Was verstehst du unter "5 gebündelten Empfangsadressen"? Was genau ist da gebündelt? Wichtiger noch: an welcher Stelle hat es 25 Minuten gedauert? Zum Bestätigen der Transaktion in einem Block, nachdem du diese ins Bitcoin-Netzwerk veröffentlicht hast? Je nach Transfer Fee Rate und aktuellem Zustand des Mempools zum Zeitpunkt der Transaktion finde ich das weder lang noch kurz. Oder hat das Signieren der Transaktion mit dem Ledger Nano S etwa 25 Minuten gedauert? Andererseits ohne zu wissen, wieviele Transaktions-Inputs beteiligt waren, kann diese Zeit überhaupt nicht eingeordnet werden. Zu anderen gebräuchlichen Hardware-Wallets kann man sich z.B. hier informieren: https://blog.thebitcoinhole.com/best-hardware-wallets-31141ed1aa05 (Feature-Vergleich von 26 Hardware-Wallets) Trezor Modell One (ziemlich günstig, aber auch relativ spartanisch) und T (empfinde ich überteuert) haben keine Secure Chips drin, was aber für normale Nutzer kaum Relevanz hat. Muss man definitiv nicht überbewerten. Die BitBox02 App unterstützt keine Legacy Adressen, was ich persönlich nicht schlimm finde, da man Legacy Adressen (1...) nicht mehr wirklich verwenden muss. Das kann aber zum Problem werden, wenn man z.B. von Ledger auf BitBox02 migrieren möchte, weil der Ledger Nano den Geist aufgegeben hat und man in der Leger Nano Wallet ein oder mehrere Legacy Adressen Konten verwendet hat. Was ich persönlich noch nicht ausprobiert habe: kann man eine Legacy Adressen Wallet z.B. mit Electrum und Sparrow, die beide auch Legacy Adressen unterstützen, trotzdem mit der BitBox02 verbunden nutzen? Vielleicht haben andere BitBox02-User hierzu einen Hinweis? Eine Hardware-Wallet ist im Grunde genommen hauptsächlich ein sicheres Signier-Gerät. Die meisten Features bildet die Software-Wallet ab, die sich mit der Hardware-Wallet verbindet, sei sie vom Hersteller der Hardware-Wallet oder eine bekannte und etablierte Software-Wallet (ich würde Open Source bevorzugen) wie Electrum oder Sparrow (ich bin weitgehend Bitcoin-only unterwegs). Beim Migrieren und Sichern einer Wallet mit Recovery Wörtern aus einer Hardware-Wallet bitte immer beachten: die Recovery Wörter dürfen unter keinen Umständen Kontakt mit einem digitalen Gerät bekommen, das mit dem Internet verbunden wird und dessen Sicherheitszustand man nicht zu wirklich 100% sicher einschätzen kann. Beim Migrieren von Recovery Wörtern diese am besten ausschließlich auf der neuen Hardware-Wallet eingeben. Hardware-Wallets ohne eigenes Display sollte man niemals in Betracht ziehen, da es diese unmöglich machen, in einer sicheren Umgebung zu signierende Transaktionen frei vom Einfluß von Malware zu kontrollieren und nur nach ausführlicher Kontrolle auch signieren zu lassen.

Da der Ledger Nano S ja bei der in der Größe anwachsenden Firmware und Ledger Apps arg knapp mit dem Speicher geworden ist, solltest du keine Transaktion mit vermutlich 349 Inputs bauen und zu signieren versuchen. Könnte gut sein, daß es deswegen scheitert. Ein anderer Gedanke war, den ich hatte, daß du mit einem lahmen Electrum-Server verbunden bist. Hab' diese Idee allerdings verworfen, da der grüne Punkt bei dir andeutet, daß deine mit dem Ledger verbundene Wallet in Electrum trotzdem vollständig synchronisiert ist. Da habe ich mehr Vertrauen zu Electrum, als zu diesem Ledger Live Software-Müll. Auswege aus deiner Misere wären m.E. kleinere Transaktionen, d.h. weniger Coins in die Transaktions-Inputs werfen. Ggf. mit Coin Control arbeiten, weil du da vollständige Kontrolle über die verwendeten Inputs/Coins hast. Das geht alles ganz wunderbar mit Electrum, man muss nur wissen wie. (Ist auf den Electrum Hilfe-Seiten auch beschrieben bzw. es gibt sicherlich zig Videos dazu). Ggf. auch in den Einstellungen > Transaktionen die erweiterte Vorschau aktivieren (da mein Electrum auf English gestellt ist, heisst es bei mir Preferences > Transactions: Advanced preview muss angehakt sein. Wenn du die 24 Mnemonic Recovery Wörter deiner Ledger Nano S Wallet hast, sind deine Coins auf jeden Fall nicht verloren. Da man die Wallet zur Not auf einer anderen sicheren Wallet wiederherstellen kein, die nicht so ein Ledger (Nano S) Müll ist. Sorry, wenn ich meiner Aversion gegen Ledger hier freien Lauf lasse. Ich mag Ledger als Firma und deren Social Media Moderatoren nicht sonderlich, weil die sich gefühlt wie arrogante Idioten aufführen. (Ist vielleicht nur meine bewusst schiefe Wahrnehmung.)

Wie kann man eigentlich eine vermutlich fünfstellige Summe auf eine Art versenden, von der man sich nicht vorher überzeugt hat, daß die Ziel-Wallet (bei Bitpanda) diese auch unterstützt? Dieser Transfergebühren-Geiz ist geil-Ansatz war mal so richtig teuer. Sorry, wenn ich das hier nochmal in aller Deutlichkeit hervorhebe. Vielleicht lesen ja doch einige Ahnungslose solche Warnungen zur Abwechslung mal *vorher*. Die Ziel-Wallet gehört ja Bitpanda und die haben natürlich die Private Keys für ihre Empfangsadressen. Wenn die Transfer-Netzwerke, unterstützte bei Bitpanda und das offiziell nicht-unterstützte verwendete Netzwerk einigermaßen kompatibel zueinander sind, kann man in der Regel mit dem Private Key der Empfangsadresse, die Coins/Token auf der nicht-unterstützten Chain meistens trotzdem bewegen. Dazu muss man natürlich die bisher nicht unterstützte Blockchain/das nicht unterstützte Transfer-Netzwerk zur Verfügung haben. Das kann in einen gewissen Aufwand ausarten, der natürlich Zeit und Kosten verursacht, u.U. sogar nicht unerhebliche. Das sollte man im Hinterkopf behalten. Technisch sind meistens die Coins/Token nicht wirklich verloren. Aber es kann auf den Einzelfall ankommen. Eine generelle Behauptung der Exchange, die Coins/Token wären (technisch!) verloren, ist häufig nicht richtig. Die haben entweder keinen Prozess für die Wiederherstellung, kein Knowhow (schwer vorstellbar für eine Exchange) oder schlicht keine Lust für solche Sonderlocken. Das Problem ist, daß das ein Wiederherstellungs-Prozess ist, der vollkommen außerhalb der normalen Prozessabläufe der Exchange ist. Da müssen vertrauenswürdige Spezies dran, da diese mit Private Keys der Exchange hantieren müssen. Das wird keine Exchange freiwillig und kostenlos anbieten! Egal wie: man muss immer vorher prüfen, ob ein gewünschtes oder bevorzugtes Transferverfahren von der Ziel-Wallet auch vollständig unterstützt wird. Ohne Wenn und Aber...

TIPPABGABE KOMMT PER PM Amsi: X 39000,- $ / Invoice geschickt - Invoice bezahlt

Man kann davon ausgehen, daß die Korrelation Private Key --> Public Key eindeutig ist, d.h. zu jedem Private Key gibt es auch einen eindeutigen Public Key. Der Umfang beider Schlüsselräume ist im Prinzip gleich groß (Zuordnungskollisionen sind nicht wirklich zu erwarten, aber das kann ich nicht beweisen). Bei der Transformation Public Key --> Public Address kommt die Einweg-Hashfunktion RIPMD160 am Ende zum Einsatz, die ein 160 Bit langes Ergebnis liefert. Das bedeutet aber, daß 2⁹⁶ Public Keys, somit auch 2⁹⁶ Private Keys, dieselbe Public Address ergeben. Das ist aber immer noch kein Problem, da es extrem ... extrem schwierig/aufwendig/unwahrscheinlich ist, passende Kollisionen zu finden. Darüber hinaus gibt es in der Bitcoin-Blockchain selbst keinerlei Public Addresses: die werden nicht in der Blockchain gespeichert. Eine Public Address ist nur so etwas wie ein Rezept, eine Anweisung, wie eine Wallet das Locking-Script für einen UTXO konstruieren muss, das festlegt, was also wie präsentiert werden muss, damit man einen UTXO ausgeben, also bewegen, darf. Meines Wissens nein, das hat nichts mit Prüfsumme usw. zu tun. Das hier ist der Grund (im Link ausführlicher dargestellt, als ich es ausgeführt habe) für die reduzierte Anzahl an Adressen: https://learnmeabitcoin.com/technical/public-key-hash