Cricktor

Sowas habe ich auch als Fallback-Lösung, denn schließlich kann ein Smartphone kaputt gehen, verloren oder gestohlen werden. Ein wenig Redundanz hat noch nie geschadet! Aber langsam driften wir ins Offtopic... 😉

Ich habe diesen Post von pointbiz auf bitcointalk.org zu etwaigen Anschuldigungen gefunden, daß bitaddress.org mal kompromittiert worden sein soll. Ich habe immer noch starke Zweifel, daß bitaddress.org je unsauber war. Wahrscheinlicher sind viele andere Fehlerquellen von "betroffenen" Usern, ohne Anspruch auf Vollständigkeit: falsche Links / Bookmarks Typosquatting maligne Browser-Extensions maligne "Crypto-Browser" mit subtiler Malware infizierte Rechner Ahnungslosigkeit und/oder Dummheit von Usern unsichere digitale Speicherung von Backups der Private Keys oder Paperwallets (z.B. digitale Fotos gemacht) ...

Einverstanden, sowas mache ich auch oder nutze einen TAILS-Stick im Offline-Modus. Davon hat aber @Peer_Gynt nicht gesprochen. Daher wollte ich darauf hinweisen, daß man ein potentiell nicht sicheres System nur durch Offline-Nehmen nicht zu einer sicheren Basis für sensitive Tätigkeiten machen kann, wenn dasselbe System später wieder online geht und man kaum Kontrolle darüber hat, welche Datenspuren auf dem System verblieben oder gar exfiltriert worden sind, falls das System schon mit stiller Malware kompromittiert war oder später wird. Your keys, your opsec!

Wie kommst du auf den Vergleich mit Bankdaten im Zusammenhang von Recovery Wörtern? Mein Login-Passwort für's Online-Banking ist nicht digital gespeichert, weil das nicht nötig ist (eine analoge Sicherung ist aber auch hier vorhanden). Ein Angreifer kann auch nur wenige Versuche machen, bevor das Konto für Logins gesperrt wird. Jede geldbewegende Transaktion von meinem Bankkonto benötigt eine 2FA-Bestätigung, ebenso wie alle 90 Tage der Login selbst.

Falls du vorhaben solltest, mit GPUs direkt BTC zu minen, kann ich nur sagen: vergiss es, das funktioniert schon seit ca. 2013 nicht mehr mit GPUs, weil die erst gegen FPGAs und dann gegen ASICs lange nicht mehr konkurrenzfähig hashen können. Oder dachtest du daran, irgendeinen Shitcoin auf Nicehash gegen Bezahlung in BTC zu schürfen? Auch hier wird sich das nicht lohnen, weil du die Energie nicht für umsonst bekommst.

Wenn man sich daran hält, Mnemonic Recovery Wörter grundsätzlich und ausschließlich analog zu sichern, kann nicht viel passieren. Wer denkt schon auf Smartphones z.B. an die Tastatur-App, die zwecks Autokorrektur und anderen Gimmicks mit ziemlicher Sicherheit in die App-Hersteller-Cloud petzt. Das kann sowas von nach hinten losgehen... Fast sinnlos den PC offline zu nehmen, wenn er anschließend nicht offline bleibt oder restlos und sicher platt gemacht wird (der Datenträger natürlich). Haltet mich für paranoid, aber der Fehler fängt schon damit an, den Seed (ihr meint sicherlich damit die Mnemonic Recovery Wörter) in irgendeiner Form digital zu bearbeiten/verschlüsseln/sichern. Strikt analog kann nunmal nicht digital entfleuchen, außer man bekommt ungebetenen Hausbesuch.

Mir sind keine wirklich fundierten Code-Schwächen oder -Probleme von bitaddress.org bekannt. Mögliche Anschuldigungen oder Probleme von Usern muss man sehr differenziert betrachten, da beim Handling von Private Keys eine Menge falsch gemacht werden und schief gehen kann. Das fängt schon mit der Vertrauenswürdigkeit und Sicherheit der verwendeten Plattform an, auf der du mit nackigen Private Keys hantierst. Und es ist meist nur schwer einschätzbar, welche konkreten Fehler jemand u.U. gemacht haben kann, die zur Kompromittierung von Private Keys geführt haben. Ich habe mir den Code von bitaddress.org auch mal genauer angesehen und nach meinem Code-Verständnis keine Auffälligkeiten entdecken können. Dasselbe habe ich mit dem Code von Canton Beckers Service gemacht, der ja praktisch zu 100% den relevanten Generierungscode übernommen hat. Ich habe wenige Paperwallets mit Canton Beckers Code generiert, die heute noch safe sind (genauer: sie wurden noch nicht von Unbekannten abgeräumt). Meine Code-Analyse und Nachweis dagegen ist eindeutig, daß das verkaufte und aktuelle, nicht von Canton Becker mehr verantwortete bitcoinpaperwallet dot com keine echte vom User "generierte" Entropie verwendet, obwohl es dem User das suggeriert, sondern "zufällige" aber dem Anbieter wohl bekannte deterministische Keys ausspuckt. Was bei dieser bösartigen Site im Backend abläuft, kann ich nur mutmaßen. Meine Experimente mit der Site zeigten, daß ein Besucher gefühlt keine reproduzierbaren und sich wiederholenden Keys dort generieren kann, aber echte Entropie wird da definitiv nicht erzeugt und eingesetzt. Aus meiner Erinnerung: jeder Seitenabruf generiert individuellen ziemlich verschwurbelten JS-Code, der individuelle "Test-Keys" für, hust hust, Unit Tests enthält. Diese Test-Keys werden für die Key-Generierung verwendet, die Entropie durch Maus-Zappelei ist Fake. Wie diese Test-Keys generiert werden, ist dem bösartigen Anbieter bekannt. Eliminiert man diese Test-Keys bis auf einen, kann man sehen, daß immer dieselben Private Keys generiert werden, egal was man macht und wie oft man für die "Entropie" mit der Maus rumhampelt. Ich hatte nicht die Zeit und Lust, viele Tausend Versuche zu machen, um evtl. auftretende Wiederholung zu entdecken. Das muss auch der Anbieter vermeiden, denn ein User darf nicht plötzlich eine schon mal verwendete Adresse "generieren", das wäre fatal für alle Beteiligten. Es reicht ja z.B. wenn der bösartige Anbieter die genaue Request-Zeit und nur ein bisschen Entropie für die Key-Generierung eines Site-Besuchers einfließen lässt. Der Anbieter kann trotzdem die generierten Private Keys der Paperwallets von Usern ermitteln und beladene Paperwallets zu einem geeigneten Zeitpunkt abräumen, vielleicht abhängig davon, wieviel beladen wurde. Das Ganze funktioniert für den bösartigen Anbieter natürlich auch, wenn man die abgerufene Seite der Website speichert, den Rechner komplett offline nimmt oder die gespeicherte Seite z.B. in ein Offline-Tails transferiert. Die generierten Keys auch bei Offline-Generierung sind dem bösartigen Anbieter trotzdem deterministisch bekannt (und würden abgeräumt werden, wie schon viel zu oft passiert). Wieso dieser bösartige Anbieter immer noch online sein kann, weiterhin "Paperwallets" abräumen kann und immer in den Top-Treffern der Suchmaschinen für Paperwallets aufpoppt, ist leider ein dunkles Kapitel des Internets. Sorry, für den länglichen Post, der mit bitaddress.org zunächst mal nicht so viel zu tun zu haben scheint. Aber der bösartige Anbieter nimmt Bezug auf den Code von pointbiz und bitaddress.org, was vielleicht noch zu Canton Beckers Zeiten richtig war, heutzutage aber eine Unverschämtheit ist. Nicht dein Ernst, schonmal kontrolliert, ob du nicht so'n ChatGPT Brain Slug (siehe Futurama) irgendwo am Kopf hast? (Spaß!) Brainwallets haben sich als zu unsicher und nicht wirklich tauglich erwiesen, nahezu egal, was du als vermeintlich schlauen Input für die Brainwallet dir ausgedacht hast. Das zeigen die Listen von kompromittierten Brainwallets: https://privatekeys.pw/brainwallet/bitcoin/1 http://eli5.eu/brainwallet/

Hast du dafür Belege, Links, harte Fakten? Für bitcoinpaperwallet dot com kann ich das so, auch mit dem Zeitpunkt so ab Ende 2018 nachvollziehen, wobei Canton Becker (der ursprüngliche Seitenersteller) die Webadresse verkauft hat und der aktuelle Besitzer bis heute seinen im Seitencode nachweisbaren Betrug fortsetzt.

Schau' auf https://mempool.space nach, was aktuell gerade im Bitcoin-Netzwerk los ist (Anzahl Tx im Mempool, Füllstand, Gebühren der letzten aktuellen Blöcke und Vorhersage von benötigten Gebühren für kommende Blöcke), dann siehst du im Moment, daß der Gebühren-"Wasserstand" unangenehm hoch ist, weil im Moment rund 380.000 Transaktionen darauf warten, in Blöcke geschürft zu werden. Wessen Tx vorne in der Warteschlange "sitzen" möchte, muss Premium bezahlen. Für nicht eilige Tx kann man vielleicht etwas mehr Gebühren wählen als No-Priority und dann mit folgendem kostenlosen Accelerator vom ViaBTC-Pool versuchen, seine Tx "zu beschleunigen" (am besten vorher die Bedingungen dafür lesen!). Bezahlen sollte man für so einen Service allerdings eher nicht, was auch nicht nötig ist, da es stündlich ein Kontingent an kostenlosen Einträgen für ViaBTCs Candidate Blocks gibt. Man muss dann eigentlich nur darauf warten, daß ViaBTC mal wieder selbst einen Block schürft. Das funktioniert durchaus und nicht nur theoretisch. Vielleicht legt sich der Hype um BRC-20 in einiger Zeit wieder, vielleicht auch nicht, wer weiß das schon.

Ihr habt schon gelesen, daß die verhunzte Testüberweisung lediglich 1000sats betraf? Bei der aktuellen Mempool-Verstopfung kann man davon träumen, überhaupt mit 1000sats allein an Transfergebühren überhaupt etwas zu erreichen (aktuell komplett aussichtslos, solange einige hunderttausend Tx im Mempool schwimmen). Shice Hype mit dem BRC-20-Pump'n'Dump-Müll.

Nö, Jokin, nicht schlecht geraten, sind ja erstmal die offensichtlichen Basisbedingungen, die mindestens stimmen müssen. Bei rund 3,2kW pro Gerät, abhängig was für S19-Modelle hier am Start sind, ist das keineswegs zu vernachlässigen. @Hive ist ja ziemlich sparsam mit Details zu seinem Problem. Mir fällt da noch die Frage ein, ob denn die Miner auch ordentlich mit Schürfarbeit versorgt werden? Welche Mining-Software wird benutzt, Solo- oder Pool-Mining, welcher Pool? Sind das die einzigen Mining-Geräte oder läuft da noch mehr mit? Wieviel Mining-Knowhow und -Erfahrung hat der User? Etc. pp. etc. pp.

Du kannst auch Metamask mit deinem Ledger verbinden, diese Wrapped-BTC auf der BSC in Metamask sichtbar machen und bei Gelegenheit dann wieder zurück zu Binance schicken (dafür brauchst du BNB für den Transport über die BSC), wo du diese "Schuldschein-Token" wieder in echte Satoshis konvertieren kannst. Verloren ist Nix, nur schlau war das nicht, was du da so ohne Kenntnis der Dinge gemacht hast. Sei froh, daß du nur 1000sats so verhunzt hast. Bei der kleinen Summe lohnen vermutlich Recovery-Bemühungen nicht wirklich. Geiz ist meistens garnicht soo geil. Allerdings sind seit einigen Tagen die Transfer-Gebühren bei Bitcoin wirklich unangenehm hoch, wie du schon selbst gemerkt hast.

Meine mempool.dat ist aktuell ca. 42MiB groß und ich schätze mal, wir beide wissen nicht, was das zu bedeuten hat, zumal die eine Node von mir, bei der ich die Größe der Datei nachgesehen habe, einen Mempool von 1024MB hat (absichtlich). Wenn ich auf mempool.space nachsehe, dann hat's dort einen Pegelstand von aktuell ca. 181 MvB für etwas mehr als 400k Transaktionen in deren Mempool, die einen Speicherverbrauch der Node von ca. 1GB verursachen, so jedenfalls wird es dort ausgewiesen. Transaktionen, die wg. Platzmangel im Mempool einer Node nicht reinpassen, werden verworfen. Die jeweilige Node kennt dann die Transaktion nicht mehr. Jede Node, deren Mempool allerdings groß genug ist, wird solche Transaktionen nicht vergessen. Es gibt aber auch noch einen weiteren Parameter für die Verbleibdauer einer Transaktion im Mempool einer Node und das ist mempoolexpiry, dessen Wert per Default bei 336h (14 Tage) liegt. Lungert eine Transaktion länger als mempoolexpiry=336 Stunden im Mempool einer so konfigurierten Node herum, wird sie rausgeschmissen, falls nicht eine andere Node diese Transaktion erneut im Netzwerk kundtut und der hier betrachteten Node zuflüstert. Das ist die Ansicht und Zählung von bitcoinfees.net, jede Node hat eine eigene Zählung der ihr bekannten Transaktionen, die im Mempool der Node darauf warten, daß sie in einen Block geschürft werden. Einigkeit/Konsens besteht über die in der Blockchain geschriebenen Transaktionen. Deine Rechnung ist willkürlich, denn nicht jede Transaktion hat eine Größe von 1000. Und was nun genau in der mempool.dat steht, wissen wir beide nicht. Ich kann es dir auch nicht erklären. Meine Node mit 1024MB-Mempool habe ich z.B. heute aus anderen Gründen neu gestartet. Das ist dort der aktuelle Stand für deren Mempool: $ bitcoin-cli getmempoolinfo { "loaded": true, "size": 61156, "bytes": 23090834, "usage": 134069936, "total_fee": 6.05228533, "maxmempool": 1024000000, "mempoolminfee": 0.00001000, "minrelaytxfee": 0.00001000, "incrementalrelayfee": 0.00001000, "unbroadcastcount": 0, "fullrbf": false } Mein RaspiBlitz, den ich aber auch gestern mal neu starten musste, weil ich das Gefühl hatte, Irgendwas stimmt vielleicht nicht, zeigt folgendes Ergebnis für einen 400MB Mempool: ₿ bitcoin-cli getmempoolinfo { "loaded": true, "size": 191720, "bytes": 63493776, "usage": 372276384, "total_fee": 32.09095962, "maxmempool": 400000000, "mempoolminfee": 0.00012007, "minrelaytxfee": 0.00001000, "incrementalrelayfee": 0.00001000, "unbroadcastcount": 0, "fullrbf": false } Zur Erklärung der Werte: $ bitcoin-cli help getmempoolinfo getmempoolinfo Returns details on the active state of the TX memory pool. Result: { (json object) "loaded" : true|false, (boolean) True if the mempool is fully loaded "size" : n, (numeric) Current tx count "bytes" : n, (numeric) Sum of all virtual transaction sizes as defined in BIP 141. Differs from actual serialized size because witness data is discounted "usage" : n, (numeric) Total memory usage for the mempool "total_fee" : n, (numeric) Total fees for the mempool in BTC, ignoring modified fees through prioritisetransaction "maxmempool" : n, (numeric) Maximum memory usage for the mempool "mempoolminfee" : n, (numeric) Minimum fee rate in BTC/kvB for tx to be accepted. Is the maximum of minrelaytxfee and minimum mempool fee "minrelaytxfee" : n, (numeric) Current minimum relay fee for transactions "incrementalrelayfee" : n, (numeric) minimum fee rate increment for mempool limiting or replacement in BTC/kvB "unbroadcastcount" : n, (numeric) Current number of transactions that haven't passed initial broadcast yet "fullrbf" : true|false (boolean) True if the mempool accepts RBF without replaceability signaling inspection } Examples: > bitcoin-cli getmempoolinfo > curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getmempoolinfo", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:8332/

Das ist ja auch gut so, weil dann der Private Key immer der gleiche ist. ETH- und BSC-Transportnetzwerk sind sich auch so ähnlich, daß du mit dem gleichen Private Key auf beiden Chains dein Zeugs bewegen kannst. Wie @Tschubaka angedeutet hat, kannst du Metamask mit deinem Ledger Nono S Plus verbinden (keine neue Wallet erstellen, sondern Metamask soll die Wallet deines Ledgers ansprechen können), dann machste die SHIBINU-Token auf der BSC in Metamask sichtbar und kannst die dann wieder zurück in deinen Binance-Account schieben (du brauchst BNB als Gas für Transaktionen auf der BSC in deiner Ledger-Wallet). Ich kann mich erinnern, daß das Vorgehen in der Binance Academy deutlich genug beschrieben wird. Einfach ein wenig mehr Mühe mit dem Suchen geben, dann klappt das schon. Wenn deine Köter-Token dann wieder zurück in deinem Binance-Account sind, kannst du sie dann richtig über ETH-Netzwerk in deine Ledger-Wallet kübeln.

Verboten ist LIFO doch meines Wissens nicht, du musst dich nur *vorher* darauf festlegen, es deinem FA mitteilen und dann dabei auch bleiben, wenn es dein FA akzeptiert hat. Hin und her ist dann aber nicht mehr und war es auch meines Wissens nie.

Kann man so pauschal nicht sagen. Die Standardgröße eines Node-Mempools ist 300MB RAM, kann aber vom Node-Betreiber nahezu beliebig anders konfiguriert werden, was aber die wenigsten überhaupt machen. Ein solcher Standard-Mempool wirft aktuell Transaktionen unter ca. 18 sat/vB einfach komplett weg und leitet die dann auch nicht weiter, weil niedrigere Fees eh kaum von anderen Nodes akzeptiert bzw. weitergeleitet werden können. Daher verrotten 1 sat/vB-Transaktionen aktuell auch nicht, außer man hat einen Mempool mit aktuell mehr als 1GB Größe, sondern werden "gepurged", vergessen, gelöscht, nicht mehr beachtet... Kann die eigene Node eine empfangene Transaktionen nicht in den eigenen Mempool aufnehmen, wird diese Transaktion verworfen und auch nicht der Versuch unternommen, die Transaktion an die eigenen Node-Partner, mit denen die eigene Node kommuniziert, weiter zu geben. Nodes geben in der Regel auch kund, welche Gebührenhöhe sie für zu akzeptierende Transaktionen erwarten. Hier mal ein Snapshot einer meiner Nodes: $ bitcoin-cli getpeerinfo | grep minfeefilter "minfeefilter": 0.00017001, "minfeefilter": 0.00018702, "minfeefilter": 0.00018702, "minfeefilter": 0.00000000, "minfeefilter": 0.00017001, "minfeefilter": 0.00018702, "minfeefilter": 0.00018702, "minfeefilter": 0.00000000, "minfeefilter": 0.00000000, "minfeefilter": 0.00000000, "minfeefilter": 0.00000000, "minfeefilter": 0.00017001, "minfeefilter": 0.00015456, "minfeefilter": 0.00017001, "minfeefilter": 0.00001000, "minfeefilter": 0.00018702, "minfeefilter": 0.00018702, Die Werte sind in sat/vKB. Einige meiner Peers nehmen alles an, was nicht bei Drei auf'm Baum ist, die meisten "normalen" Nodes mit Standard-300MB-Mempool dagegen erst ab ca. 17-18 sat/vB. Die mit 0.00000000 sind entweder nur Nodes mit "connection_type": "inbound" oder "connection_type": "block-relay-only", Letztere propagieren nur ganze Blöcke, keine Transaktionen.

Inwiefern wirkt sich denn die Frage, ob ein Coin/Token ein Wirtschaftsgut ist oder nicht, auf die Besteuerung von Verkäufen als Privatveräußerunggeschäft aus?

Dein Thementitel suggeriert, du wüsstest, daß du SHIBA INU per Binance Smart Chain an eine ETH-Empfangsadresse deines Ledgers gesendet hättest. Ich bin jetzt nicht wirklich auf Binance aktiv, kann mich aber bei den Beschreibungen nicht so recht erinnern, daß so etwas von Binance gefragt wird, wenn man BSC als Transportnetzwerk nutzt bzw. gewählt hat. Transfers über die BSC sind ja in der Regel deutlich günstiger als Transfers über ETH-native Chain, da stellt sich solch eine Frage kaum. Du kannst aber sicherlich in der Transaktionshistorie auf Binance nachsehen, wie genau du nun den Transfer gemacht hast. Erst einmal sollten die harten Fakten zweifelsfrei feststehen, bevor man dir weitere Hinweise geben kann. Falls du tatsächlich die Token per BSC auf eine ETH-Empfangsadresse deines Ledgers gesendet hast, ist eine Recovery der Token normalerweise kein Problem, da du den Private Key der ETH-Empfangsadresse "besitzst", zumindest ist er sicher im Ledger NoNo S Plus eingesperrt (du solltest aber normalerweise alles haben, um an den Private Key herankommen zu können, falls das notwendig ist). Ich würde schon mal die BSC-App auf deinem Ledger installieren, denke mal, die wirst du für den weiteren Prozess benötigen. Hier im Forum, in der Binance Academy oder sehr wahrscheinlich auch in den Hilfeseiten von Ledger ist idR der Weg zum Sichtbarmachen und Wiederherstellen deiner Token durchaus beschrieben. Vielleicht musst du einfach nur ein wenig mehr suchen und lesen und verstehen lernen. Man sollte insbesondere verstehen, was es bedeuten kann, wenn man Coins oder Token mit dem "falschen" Transportnetzwerk zu einem Ziel sendet, das das genutzte Transportnetzwerk nicht unterstützt. Technisch sind die Coins/Token selten verloren, praktisch kann es sich aber als nahezu unmöglich erweisen, das Transferziel zu einer kooperativen Recovery zu überzeugen.

Ganz einfach: du lässt die Maus über dem Usernamen oder -bild schweben, bis so'n Dingens (Popup oder so) eingeblendet wird, der Knopf rechts unten in dem Dingens lautet "Benutzer ignorieren". Kurz und schmerzlos. Beiträge von ignorierten Usern werden dann nur mit einem Hinweis im Thema angedeutet à la Du hast entschieden, den Inhalt von ... zu ignorieren. Optionen Wenn andere allerdings den oder die ignorierten User zitieren, siehst du dessen zitiertes Geschreibsel halt trotzdem. Aber das ist erträglicher, weil meist deutlich weniger.

Im Moment werden Transaktionen unter 6 sat/vB aus einem Standard-Mempool gespült, bei den letzten 4 Blöcken war unter einer Gebührenhöhe von 118 sat/vB kein Platz mehr für Transaktionen im Blockbus frei und Stehplätze gab's auch keine.

OK, stimmt, war zu faul oder zuwenig Zeit und hab's jetzt nachgeholt. Gibt ja immer nur 8 mögliche Wörter, die für das 24. Mnemonic Wort passen. Das Schwierigste ist ja die SHA256-Prüfsumme zu berechnen, was man "zu Fuß" nicht wirklich machen möchte. In der Tat dürfte seedpicker.net sicher offline benutzt (siehe weiter unten) kein Gefährdungspotential haben. Es sollte klar sein, daß man diese Seite nur offline auf einem spurlos vergessendem oder zu entsorgendem System wie z.B. TAILS ohne Netzwerk oder einem Live-Linux, das nur im RAM und offline läuft und nach einem Shutdown ebenfalls keine Datenspuren hinterlässt. Wer seine 23 Mnemonic Wörter auf einer Online-Seite eingibt, hat nicht mehr alle Latten am Zaun und muss und darf sich nicht wundern, wenn früher oder später etwas Unschönes mit seiner Wallet passiert. Man kann es nicht oft genug wiederholen: steter Tropfen höhlt den Stein.

Aktuell ist LND 0.16.2 aber ich kann dir nicht sagen, ob LND 0.16.x schon einwandfrei vom RaspiBlitz unterstützt wird. Das sind doch meines Wissens SCBs, also Static Channel Backups, mit denen wird ein Kanal geschlossen, um die Funds zu recovern. Was versprichst du dir davon, ein älteres Backup einzuspielen? Die Ursache, woran dein LND Schluckauf hat (wahrscheinlich ist es der LND), ist noch nicht gefunden. Du solltest in die lnd.log schauen, mindestens. Welche LND-Version lief denn bei dir, als das Unglück seinen Lauf nahm? Bei mir läuft z.B. noch LND 0.15.5 ohne jegliche Probleme. Eigentlich müsste man auch versuchen herauszufinden, was genau passiert ist, als dein RaspiBlitz sein normales Display verloren hat und plötzlich nur noch Log-Zeilen um sich geworfen hat. Denn das könnte durchaus Auswirkungen auf andere Teile vom RaspiBlitz gehabt haben. Frag' doch mal in der RaspiBlitz-Telegram-Gruppe, ob LND 0.16.x für RaspiBlitz 1.8.0c (oder was da gerade aktuell ist) problemlos läuft, wenn ja, würde ich dann durchaus die 0.16.2 einspielen, was aber dein Problem nicht in Luft auflösen wird. Meines Erachtens ist das, was du zuletzt gemacht hast, ziemlich sinnfrei und nicht förderlich gewesen. Zuerst soltle man eine Fehleranalyse machen, was die Ursache für dein anfängliches Problem war, dann erst entsprechende Maßnahmen ergreifen. Wenn man nicht selbst weiß, wie man die Ursache herausfinden kann, dann fragt man an den potentiell richtigen Stellen um Hilfe, z.B. und sicherlich sinnvoll in RaspiBlitz-Gruppen, die im RaspiBlitz-Github auch genannt werden. Die Wahrscheinlichkeit dürfte hoch sein, daß dort auch Experten an Bord sind.

Die Offline-Nutzung garantiert noch lange nicht, daß der Seed "sauber" generiert wird. Denn auch bei Offline-Nutzung kann ein Tool den Seed bzw. dessen Ausgangs-Entropie deterministisch oder verschleiert nur mit sehr geringer Entropie und dem Anbieter bekannt erstellen, was für ca. 99% der Anwender kaum sicht- und bemerkbar wäre, bis die Wallet wie von Zauberhand geleert wird. Dann kannst du dir auch offline Mnemonic Worte generieren und deine Wallet könnte dann vom böswilligen Anbieter trotzdem abgeräumt werden. Alles schon dagewesen bzw. immer noch online durch böswillige Anbieter (z.B. bitcoinpaperwallet...; Google Suchtreffer meist Nr. 1)! Bei iancoleman.io kann ich das für mich ausschließen, da ich mir den Code gründlich angesehen habe und nach meinem Code-Verständnis alles sauber ist. Zu seedpicker.net kann und möchte ich keine Aussage treffen, nicht selbst angesehen und geprüft.

Was verwendest du für Lightning in deinem RaspiBlitz: LND oder CL? Welche Version von LND oder CL läuft jeweils? Wenn dir der Warten auf.../Waiting for... Dialog angezeigt wird, kommst du mit Strg-C auf die Kommandozeile und mit raspiblitz ins Menü, um ggf. Logs der Lightning-Node oder evtl. nötige Updates/Patches zu machen.

Ich weiß nicht, wie du darauf kommst. Vom Seed bzw. den Mnemonic Wörtern war doch garnicht die Rede. Wenn man eine Software-Wallet mit einer Hardware-Wallet verbindet, muss die Software-Wallet zumindest den Extended Public Key der Hardware-Wallet kennen. Den fragt sie beim Verbinden mit der Hardware-Wallet von dieser ab. Die Private Keys verbleiben natürlich in der Hardware-Wallet, sonst wäre das ja von der Sicherheit her sinnlos.