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

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.