Anybody really knowledgeable about miniscript? I think this wallet script does most everything anyone could want, modulo minor tweaks. The fact it took me like 15 minutes to write makes me feel like I’m making some major mistake: andor(multi(3,keyA,keyB,keyC),older(4032),andor(multi(2,keyAA,keyBB),older(32768),and_v(v:pk(keyAAA),after(1200000)))) This fields a wallet that has 1) a 4 week zenHODL anti-kidnapping period where funds can not be spent, 2) a 3 of 3 multisig for blocks 4032-32768 (like 6 months or so), a 2 of 2 multisig after that until 3) block 1,200,000 where it degrades to a single sig wallet. What am I missing?

Don’t forget to tell others about bitcoin. They’ll hold you accountable either way in the future anyhow.

The whole op return thing is all about having one or more transaction relay networks. If you don’t want to relay some transactions but do want to know meta data about them for accurate fee estimation, go ahead and connect to a libre node and drop any tx you don’t want to relay after noting its size and fee rate. Libre nodes will relay enough shunned transactions to save bitcoin mining centralization from slipstream type OoB payment pressure. I think I’ll run a libre node on this principle. It shouldn’t take too many to bypass nodes participating in transaction shunning… @Peter Todd has a good head about these things.

Mining centralization is a negative consequence of not blowing open the bitcoin transaction relay op return data carrier did. But is this the only way to ensure miners choose to take transactions from the mempool instead of out of band? I’m thinking something like proof of propagation, which I don’t think can work, or disconnecting from peers that send you a nonstandard transaction…at least this way you’d have two bitcoin transaction relay networks: the standard network and various libre relay networks. The main point is to give all miners access to the same transactions without creating a reason for out of band payments.

Nobody is “good” at _making_ money. Certified financial planners, MBA’s, stock analysts, economists, central bankers, etc are not qualified to make money…they’re only specialized in increasing personal/corporate capital or provoking/avoiding financial system collapse. But they don’t create money. Even satoshi only made money once.

What would happen if someone created a transaction valid on some bitcoin nodes and invalid on others…as I understand it, if one chose not to include an OP_DROP after OP_NOP2 (OP_CLTV) in the locking script, new nodes would still find the transaction to be valid while pre OP_CLTV nodes would find the transaction invalid…what am I missing? @Peter Todd I think thought this through over a decade ago.

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