You could've simply recommended to follow above link, because the explanation there is better presented and also augmented with come helpful pictures. I'm not really convinced that your words are easier to understand and you're not even mentioning the far more important reason for Segwit...

Oh no, the Knotsi sockpuppet again. Out of curiosity, how much do you get paid to spread your lies or misleading facts about Knots?

Not that I'm interested in your answer, but how is Knots safer than Core when it's basically maintained by a single developer moron?

While Knots might not relay transactions that you K-fools deem worthy to be censored, Knots has to accept and relay blocks that still contain all what you K-fools don't want.

I don't care if you answer or not because I have you already on my ignore list, I was just curious what crap you're trying to spread here. It's a waste of time to discuss with you because as far as I've seen in other topics that you spammed with your Knots-ass-kissing you only want to chew your K-cud and nothing else.

While your question is off-topic to this thread, I would give you this answer.

If Core would support to create a wallet based on BIP39 recovery words and derivation paths, it would limit such a wallet to only support the keys that such a wallet could derive. You shouldn't be able to add more private keys to such a wallet because that would mean, you couldn't restore your wallet completely by the mnemonic recovery words alone.

I guess Core devs or whoever steers the development don't want such a limitation. And frankly I'm fine with that. I wouldn't want Core to be limited by above described scenario.

Btw, it's perfectly possible to create a descriptor wallet in Core that completely matches a BIP39 derived wallet. You do this by importing the appropriate descriptors for receiving and change addresses derivation paths of the xpriv master key derived from BIP39 recovery words and appropriate derivation path for the desired address type.

You could even have a descriptor wallet that matches a BIP39 wallet but recognizes all public address types at once which is rarely seen with other BiP39 compatible wallets.

You can't do all the steps with Core alone, you need to do the BIP39 derivation to the appropriate xpriv master key outside of Core.

Core is older than HD wallets and BIP39 wallets aren't the best, last and only solution to those.

How can you ask to store your mnemonic recovery words in your email account, it doesn't really matter in what folder you store it there, when this was one of the first things mentioned by multiple posters here to avoid digital storage.

Who controls your email account, who controls cloud storage? This is other people's computers and servers! Who do you think controls those? Hint: it's not you!

What if Google decides to create some fancy AI, to scrape all users mailboxes to do something (btw, they do this already to bombard you with more targeted ads or provide you with more "intelligent" services). Do you really think it is hard to program something that could recognize words coming from a well known list of 2048 words (BIP39 word list). Piece of cake...

It's good that you asked, because you were about to make big mistakes. Once your recovery words are out in the digital realm, you loose control who might get their hands on them. Do you want such an uncertainty? I doubt that. Come to senses!

Why do you post a useless Twitter post with basically zero information, despite a date and how that thing is likely to be called. If you want discussion about what this act is about, you should've posted something more substantial.

Is this what it's about? H.R.3633 - Digital Asset Market Clarity Act of 2025
(not really sure if this is actually what we're looking for, but we'll figure it out..., I'm not used to American Legislation)

Holy shit, this is dry stuff to read and comprehend, I'm probably not patient enough for this today, a whole bunch of references to some ancient acts and so on and so forth. This is painful legislative poison to digest.

Lots of yadda, yadda about whatnot studies should be made and reported to Senate and whoelse. Funny. OK, I give up for today, it's hard (for me) to figure out what this is ALL about, to be frank.

Hand auf's Herz, liegt es daran, da� du ein komisches Gef�hl beim Plattmachen und Wiederherstellen hattest, weil du das vorher nicht getestet hast oder warum bzw. woher die "Verunsicherung"?

Wenn ich mir nicht sicher w�re, ob die Wiederherstellung funktioniert, w�re auch mir sicherlich ein wenig mulmig zumute. Aber eigentlich sollte man die Wiederherstellung ja anfangs vorher testen, bevor man der Wallet irgendwelche Coins "anvertraut". Wenn man sich vorher schon versichert hat, man kann die Wallet einwandfrei wiederherstellen, gibt's im Grunde genommen keinen Grund, Hosenflattern zu haben.

Oder sehe ich etwas falsch?

Keine Sorge, ich musste aus fr�heren Fehlern lernen und habe in der Vergangenheit auch nicht immer alles richtig� gemacht.

Das habe ich auch gemacht, vorallem um zu sehen, welche Sicherungsma�nahmen sie ergreifen, um das Sakrileg der Extraktion von Geheimmaterial aus dem Secure Element abzusichern.

Ich finde aktuell die Doku nicht, die Ledger zum Recovery Service ver�ffentlicht hat. Ist auch schon etwas l�nger her und egal wie, es hat besiegelt, da� ich mit Ledger nichts mehr zu tun haben m�chte. Egal ob der Recovery Service sicher ist und sicher bleibt. Den Beweis dazu bleibt Ledger schuldig.

Ich meine mich zu erinnern, da� die Shards verschl�sselt werden, mit Irgendetwas, das an die Ledger Hardwarewallet gebunden ist. Ein Abfangen der Shards auf ihrem Transit bringt daher aus meiner Verst�ndnis heraus nicht viel. Ledger Live Software sollte auch eine verschl�sselte Verbindung zu Ledger und den anderen beteiligten Firmen nutzen. Es gab aber irgendeinen halbwegs schlauen Weg, die Bindung an die urspr�ngliche Hardwarewallet zu umgehen, wenn man musste. W�re ja auch bl�d, wenn die Wiederherstellung nicht ginge, wenn z.B. die urspr�ngliche Hardwarewallet kaputt gegangen ist oder verloren wurde.

Ich sehe das schw�chste Glied hier tats�chlich in der Softwarekomponente von Ledger Live selbst. Das ist ein hackbares St�ck Software, das von Malware angegriffen, gepatcht und ausgenutzt werden kann.

Ich kann mich zwar nicht genau erinnern, meine aber, da� zu keiner Zeit die wesentlichen Geheimnisse je unverschl�sselt au�erhalb der Ledger Hardwarewallet auftauchen, denn das w�re ja zu einfach und schlicht grenzenlos dumm. W�re das der Fall, tauschte man die Sicherheit einer Hardwarewallet gegen die Sicherheit eines St�cks Software auf einem Nutzerger�t aus. Das macht ja nun �berhaupt keinen Sinn und so dumm ist selbst Ledger nicht.

Wer ruft da nach mir? Oopsi, ich hatte diesen Gespr�chsfaden schon mal gesehen, aber irgendwie vergessen, ihn auf meine Watchlist zu setzen. Und gestern war'n Scheisstag, sowieso.

Ich bin ja nicht so der Chartanalyse-Typ, werde aber dies hier bei Gelegenheit und in aller Ruhe mal durchkauen. Ob mir dann noch etwas N�tzliches dazu einf�llt, wird sich zeigen. Eine funktionierende Kristallkugel haben wir ja alle nicht.

Danke f�r die Erw�hnung und da� ich es dann �ber bitlist.co/search (Notifications) schnell gefunden habe. Gleich auch mal ein paar Merits hier f�r virginorange da gelassen, weiter so!

I didn't want to say that you were speaking of or having a resistance towards descriptors. I meant that other users are reluctant and have some resistance to get in touch and deal with descriptors. Yes, it may have a bit of a learning curve but it's doable.

There's not much heavy lifting involved as there are some good brief usage examples here in the forum or elsewhere.

At first I wasn't amused when deprecation of importprivkey or dumpprivkey and similar RPCs were announced (for legacy wallets). But once I learned to use descriptors, it wasn't really a problem anymore.

I don't have to do a lot with private keys outside my software and hardware wallets. It's just that I want to know and be able to use proper tools if I had to.

I don't get the resistance to use importdescriptors as you describe it with modern descriptor wallet versions of Core. It's actually not very hard and if you use e.g. the combo(WIF) descriptor your wallet "understands" all major standard public address types, except Tapscript to my knowledge, that a single private key can derive (P2PK, P2PKH, P2WPKH and P2SH-P2WPKH). "Understands" meaning your wallet would recognize coins sent to any of the four redeem script types.

There's really no need to use ancient Bitcoin Core versions just to import single private keys. It's a piece of cake with modern descriptor wallets once you get the hang of it as nc50lc described.

I admit it took me some time to get "the hang of it", too. There are some good posts in this forum about descriptors and how to use them and then it's a matter of doing it and getting confident with 'em.

Needless to repeat: do your stuff with "open" private keys always in a safe environment (e.g. disposable live Linux running only in RAM; no persistent storage that could be exploited). Play with Testnet to avoid costly mistakes.