I am genuinely impressed with @nunchuk_io's software stack.

Let’s talk backup for your uber sophisticated bitcoin wallet. Here is the miniscript for the wallet: andor( multi(3, keyA, keyB, keyC), older(4032), andor(multi(2, keyAA, keyBB), older(32768), and_v(v:pk(keyAAA), after(1200000))) ) What does this do? 3 of 3 multisig with one month zenHODL period (anti-kidnapping forced hodl period), 2 of 2 multisig after 32768 blocks in case you lose a key (or destroy a key to make a second zenHODL period), and if you really screw up (or really want a long hodl period), it becomes a single sig at block 1.2 million. This is the corresponding wallet descriptor. It is 956 bytes. For backup, you need the following descriptor plus at least 1 seed phrase. Seed phrase is easy to backup, but descriptors are not. Maybe shoving it in an op_return makes sense. There are clever encryption compression techniques that allow any of the keys to decrypt the compressed descriptor… wsh(andor(multi(3,[704c7836/48'/0'/0'/1']tpubDEg64i5DB13mXaEDomqxzfEk6r5quMZU6Mefps8ZpMaQNRVRrYR2HhQ3QpczyFWsCfTps5RhQVBvBLa5PtAp6mbWF7C8NiEk1YgHENKC7Ty/<0;1>/*,[97139860/48'/0'/0'/1']tpubDEQXq6vm76GVqapjRSNmtGbbREbKLTuB8k5mXaApMPDCHXWWSvdMcQZAaATmVNyXrbo3qyHpLN6ZYg2PyNiMQqiTXyLwbFiTyicuR3nq58Z/<0;1>/*,[a2ac9184/48'/0'/0'/1']tpubDE3M2d5NWZ5iSaJyqHjfHcPr1yZRyHnCPVSjZghit5WRbiWtyZxXgKs7aovrRCzoArN1byCwghk9RUL4rgNG7vCXWTaEJ1d8GHy8V7Qu2Ja/<0;1>/*),older(4032),andor(multi(2,[704c7836/48'/0'/1'/2']tpubDFaHgptN2P1HRvaHbGJUzpCz71RceFs9HwH1t4RoXvHmGY5hprtRDEspD1yYUKmGEQ1dmRE5bkF7epJ4cFXpAkvmmq9Mst5MuvND7khiP6f/<0;1>/*,[97139860/48'/0'/1'/2']tpubDEf8yQwxu1uiHhNttV9DnVSeWBwAUSug9e4JVsU4x6144Z1XxZhJbs61MLByexNGXphKK7y5bnHfuoPmHauRdnbS9ANtTDAYnikd2dUd76k/<0;1>/*),older(32768),and_v(v:pk([704c7836/48'/0'/2'/1']tpubDFaBSe3nXwdt7Vs9HkNozSY5BxokLhGtneRW8xreyUUnirK1TDi1tDSKTGsUuFxeVG74HLQFa7CidepW4PracZTnUtKxc7zgJmF19CqxNot/<0;1>/*),after(1200000)))))#7en8aad5

Here’s an interesting wallet via miniscript: andor( multi(3, keyA, keyB, keyC), older(4032), andor(multi(2, keyAA, keyBB), older(32768), and_v(v:pk(keyAAA), after(1200000))) ) Give you a zenHodl period of about 1 month. Can’t spend a thing before this. Spend a Utxo to reset the counter. After the 4032 blocks, you need a 3 of 3 multisig to spend. But if you lose any one of those keys, then after 32768 blocks you can spend with a 2 of 2 multisig. For malleability reasons you don’t want these to be the exact same keys above, but that doesn’t mean they can’t come from the same seed…use a different path. And if you lose one of those two keys, then after like 6-7 years, at block 1.2 million, a single signature will suffice…

Found a small bug in @nunchuk_io Try this miniscript: andor( multi(3, key_0_0, key_1_0, key_2_0), older(4032), andor(multi(2, keyA, KeyB), older(32768), and_v(v:pk(key_revocation), older(65535))) ) If you change 65535 to 65534 it doesn’t crash. If you change it to 65536 UI reports branch is valid after 0 blocks but I’m not sure how overflow works with this timelock

I’m really stoked about new @nunchuk_io Wallet enabling core miniscript functionality. I have one important suggestion regarding UI that will go a long way to assist users with restoring from backup: wallet identifier should be visible from within the application. I can see the wallet id if I email myself a copy of the descriptor, but as best I can tell it’s not in the app. You have to assume there will be users who do a decaying or expanding multisig and all they have are the 3 seed phrases, time info, and m of n for each time segment but not the descriptor…it take surprisingly little info to restore such a wallet, far far less data than a descriptor contains…

Anyone know the Nunchuk guys? Their new mini script wallet is really good, but for backup it would be nice to show the wallet identifier…it can be made visible by emailing a descriptor file

For everyone getting emotional about data carrier size limits in Core 30: calm down…your concerns aren’t helped by emotions and there is still a needed debate to be had over illegal number storage and whether or not changing default configuration option for carrier size is of any effect or not on the social/legal layer of bitcoin (technical side is well figured out and is much more straightforward). IMHO, questions to be debated center around CSAM or other illegal numbers: is this fear porn fud or a genuine concern? Even if just fud, isn’t that enough to invite law enforcement to investigate/confiscate/arrest, etc? Even if we all knew that in the end bitcoin hash chain extenders need to be getting all transactions via decentralized censorship resistant network and need to be economically incentivized by transaction fees and the value thereof, that doesn’t necessarily mean inviting more police scrutiny now by blowing open op return is a wise decision…just because something will someday be necessary is not a valid argument for why it must be done _right now_ What am I missing?

Don’t think there is a valid use case for greater than 80 byte op returns? What about storing your multisig wallet descriptor? This really blurs the lines between spam and bitcoin related. Strictly speaking, storing such data is spam because no node needs this data to verify transactions. But such descriptors contain info that is 100% needed by your wallet to spend your coins (although descriptors are not maximally data size efficient, especially since you should have keys backed up separately anyhow). @Peter Todd

All you have to do is say enough bad things about a targeted someone and get enough people to repeat them and then eventually an unhinged individual will attempt to kill the targeted someone…murder by proxy.

I was the 413th user on bitcointalk.org…but a bunch don’t exist anymore. Like user #2 who is not satoshi (user 3) or @Sirius (4). I miss those days and those guys.