Raspiblitz Seed in Sparrow übertragen

Guten Abend,

ich wollte heute Abend die 24 Wörter in die Wallet Wiederherstellung von Sparrow eintragen. Ziel: Ich möchte die Wallet vom Raspiblitz auch auf dem Sparrow Wallet sehen.

Mit Blue Wallet hab ich jetzt meine Wallet immer dabei, hier hat es alles geklappt. Bei der Eingabe der 24 Wörter in Sparrow bekomme ich immer „invalid checksum“.
Wieso kann Sparrow damit nicht umgehen?

Im Netz habe ich folgendes gefunden:
" With the 24 word list given you by LND on wallet creation you can recover your private key. You should write it down and store it at a save place. Bear in mind that this 24 word mnemonic seed is not based on the BIP 39 and therefore cannot be recovered using a Bitcoin wallet"

Was kann ich tun, ich dachte man kann immer die 24 Wörter in jeder Wallet wieder herstellen`?

Vielen Dank
Bushmaster

Falsch gedacht. Du kannst sie in jeder KOMPATIBLEN Wallet wiederherstellen.
Wie du bereits zitiert hast, basieren LND Wallets aber nicht auf BIP39 (sondern einem anderen Standard namens Aezeed). Von daher kannst du die auch nur in Wallets importieren die mit LND/Aezeed umgehen können (wie z.B. Bluewallet).

Siehe auch: lnd/docs/safety.md at master · lightningnetwork/lnd · GitHub

2 „Gefällt mir“

Vielen Dank für deine Antwort, okay verstehe die Raspiblitz Wallet ist also eine spezielle Wallet mit LND Funktion, was die 24 Wörter nicht mehr zu einem Standard Seed macht, die ich so problemlos „einfach“ so woanders eintragen kann. Aber interessant das Blue Wallet das kann, aber Sparrow nicht trotz vielfacher Paper Wallets etc. damit können sie alle umgehen. Vielleicht kommt das ja nochmal als Update, denkst du das auch? Danke!!

Weil Bluewallet eben auch „Lightning“ Funktionalität hat, während Sparrow eine Bitcoin Wallet ist.

Grob gesagt gibt es einfach einen Unterschied zwischen Lightning-Wallets und reinen Bitcoin Wallets, wenn du so willst ^^

2 „Gefällt mir“

Mehr Informationen findest du hier:

1 „Gefällt mir“

Wie bereits erwähnt, verwendet LND einen Aezeed Mnemonic, der nicht BIP-39 kompatibel ist. In der weiteren Ableitung LND-intern sieht es für mich allerdings so aus, als ob es BIP-32-kompatibel weitergeht. Die „Aezeed-Ableitung“ liefert also zunächst einen nicht BIP-39-kompatiblen BIP32 Root Key, um im Iancoleman-Slang zu bleiben, danach geht es aber anscheinend mit üblicher BIP-32-Ableitung weiter.

Diese Annahme von mir basiert auf den Output von lncli wallet accounts list, bei meiner wenig genutzten Lightning-Node z.B.:

{
    "accounts": [
        {
            "name": "default",
            "address_type": "HYBRID_NESTED_WITNESS_PUBKEY_HASH",
            "extended_public_key": "ypub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/49'/0'/0'",
            "external_key_count": 0,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "default",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "zpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/84'/0'/0'",
            "external_key_count": 5,
            "internal_key_count": 6,
            "watch_only": false
        },
        {
            "name": "default",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/0'",
            "external_key_count": 6,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:1",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/1'",
            "external_key_count": 6,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:2",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/2'",
            "external_key_count": 6,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:3",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/3'",
            "external_key_count": 6,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:4",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/4'",
            "external_key_count": 6,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:5",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/5'",
            "external_key_count": 7,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:6",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/6'",
            "external_key_count": 0,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:7",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/7'",
            "external_key_count": 0,
            "internal_key_count": 0,
            "watch_only": false
        },
        {
            "name": "act:8",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/8'",
            "external_key_count": 0,
            "internal_key_count": 0,
            "watch_only": false
        },
        ...,
        {
            "name": "act:255",
            "address_type": "WITNESS_PUBKEY_HASH",
            "extended_public_key": "xpub...redacted...",
            "master_key_fingerprint": null,
            "derivation_path": "m/1017'/0'/255'",
            "external_key_count": 0,
            "internal_key_count": 0,
            "watch_only": false
        }
    ]
}

Was die ganzen Accounts 1…255 mit Purpose 1017’, also mit Derivation Path m/1017'/0'/1'...255' darstellen sollen, habe ich noch nicht herausgefunden.

Aus der Hüfte geschossen, aber noch nicht experimentell belegt, würde ich mich doch dazu versteigen, daß es mit dem Account Extended Public Key, im JSON-Output die Keys "extended_public_key", möglich sein könnte, die LND-Wallet zumindest watch-only in eine normale BIP-39-kompatible Bitcoin-Wallet zu importieren. Weitere Verifizierung noch nötig, ob meine These auch hält.

Vielen Dank für all die Ausführungen. Nur wie und in welcher Wallet kann ich denn nun eine Aezeed Seed Frase wieder herstellen? Mein Ziel ist es die Funds auf eine andere Wallet zu übertragen.

Der vermutlich einfachste Weg wäre eine RaspiBlitz- oder Umbrel-Node aufzusetzen und die LND-Wallet mit den vorhandenen Aezeed Recovery Wörtern wiederherzustellen.

Eine Google-Suche mit Suchbegriffen „restore Aezeed wallet“ gibt Hinweise, daß es möglicherweise auch mit der Bluewallet oder Blixt gehen kann. Ich habe aber nicht besonders viel bei den Treffern gelesen. Das wäre auch die Aufgabe von @Bedumbl

Danke für deine Antwort @Cricktor. Nur leider ist es nicht einfach für mich eine Umbrel oder RaspiBlitz aufzusetzen, da ich hier wo ich lebe wie beschrieben extrem schwierig an Hardware komme und der Raspi, den ich hatte, nach nicht mal einem Jahr sehr unzuverlässig funktioniert hat. Zunächst habe ich über das Display nichts mehr gesehen, da die Kontakte einen Wackelkontakt aufwiesen, dann, als ich das Display nach einiger Mühe „zurechtgewackelt“ hatte, musste ich feststellen, dass ich im Display keine IP Adresse zu Gesicht bekomme. Direkt dort externe Tastatur anschließen und versuchen die Logfiles irgendwie zu ziehen? Wie bekomme ich die jedoch von dort herunter, sodass ich sie am Desktop inspizieren kann? Das ist alles sehr provisorisch leider. Das Betriebssystem hatte ich mehrfach neu geflasht, geholfen hat es nichts…
Wenn ich mal mehr Zeit habe, werde ich dort wohl weiter probieren. Ein Raspi wird es allerdings wohl so schnell nicht mehr werden bei mir. Danke trotzem nochmal für deinen Rat.

Die Chantools wären auch eine Möglichkeit…

Bitte sorgfältig lesen, was man tun kann und was man besser nicht oder niemals tun sollte.

Unzuverlässigkeit beim Raspi, häufigste Ursachen:

  • kein Original-Raspi-Netzteil
  • verwendete SSD (optimal ist die Sandisk SSD Plus) zieht zuviel Strom (mehr als 6W liefert der Raspi kaum für alle seine USB-Ports gemeinsam!) → powered USB-Adapter verwenden, ausreichend powered USB-Hub verwenden
  • miese microSD-Karten
  • schlechte Kühlung