I love BIP 93, with its ability to store any secrets with super-high redundancy and natively handle multiple shares by hand.
But I also love BIP 39 for the simplicity of 12 words, and the universality of the standard.
I want a word scheme for BIP 93. It would be 20-23 words(depending on what scheme is used), but highly redundant. You could recover with 3 or 4 unknown words.
Ideally the word list would avoid near-miss words, and be distinct from BIP-39 enough that it would likely be distinguishable, rather than relying on the strange number of words.
Should this exist?
Rusty Russell
rusty@rusty.ozlabs.org
npub179e9...lz4s
Lead Core Lightning, Standards Wrangler, Bitcoin Script Restoration ponderer, coder. Full time employed on Free and Open Source Software since 1998. Joyous hacking with others for over 25 years.
$ xpay ₿rusty@rustcorp.com.au 100sat
Took me longer to get DNSSEC working than to implement!
Finalizing the #CLN 25.09 rc1 now, and I'm particularly delighted by the new BIP353 plugin! I'm going to try to sneak in xpay support if I can distract the Release Captain for a moment...
BIP 353 is one of the two features I really wanted this release to help push the ecosystem onwards: @Matt Corallo also has a feature in his node that supports BIP353 resolution by onion messages which I would like to spec up and support as well.
Next release...
Not that anyone probably cares, but the debate on Bitcoin Treasury companies is an interesting one. It seems clear to me that the hype that pushes MNAV significantly over the value of the regulatory arbitrage is the same force that can push it dramatically below one in the case of a market panic. It's interesting to think about what happens in this scenario.
And that's where the parallel to 1929 comes in. In theory, it's an opportunity to pick up cheap coins and some steep discount with mnav < 1, and some do, but then decline continues and now they're out of money. It won't help that in the hype, corporate structures have gotten intertwined and complicated and layered and there's a healthy dose of fraud. Panic continues...
JFK committed suicide
First post from #damdroid
I'm just going over here, doing anything but listening to this.I remember a more whimsical Internet.
So, you might not have noticed, but I still haven't published my BIPs. That's mainly because I've been having too much fun with Julian who has been hacking on the benchmark code as we refine the BIP.
In particular, OP_ROLL. BIP-143 already notes this opcode can be slow, and indeed, moving every stack element by one is bad enough when you can have 1000 of them. If we want to increase that to 32k, which we'd like to do so you can push every output onto the stack, for example, we can no longer ignore this problem.
This is the only case where stack manipulation itself causes a significant overhead. For every other opcode we can treat it as the cost of interpreting opcode and it is not addressed by varops. Annoying!
So we have benchmarks which show how much we should charge for it to limit the damage it can cause. But everything else is derived from a "bytes manipulated" model, and so I would like to extend the model a little to take into account this case. Not just for bitcoind as it is today, but for any reasonable implementation in the future.
@Blockstream Jade Plus as bling at morning coffee.


@Blockstream Jade crafternoon results. Now it's lanyard-worthy! 💚 

npub.cash dead? I never did figure out how to get my sats from there. I guess I should figure out how to receive zaps to my lightning node.
That seems terribly complex. I can't just put a bolt12 in nostr somewhere?
OK, hot off the keyboard! Here are my first pass series of 4 BIPS:
1. Varops Budget For Script Runtime Constraint
2. Restoration of disabled script functionality (Tapscript v2)
3. OP_TX
4. New Opcodes for Taproot v2
I took this week off to work on these, so I can post them to the ML and we can start proper discussion. But I figured I might as well share early drafts here! Especially since I am sometimes so "in the weeds" that I forget what questions normal developers might have, looking at all these words...
GitHub
Comparing bitcoin:master...rustyrussell:guilt/varops · bitcoin/bips
Bitcoin Improvement Proposals. Contribute to bitcoin/bips development by creating an account on GitHub.
First day of my "week off". Caught up with a friend for the morning, started serious BIP writing in the afternoon.
I'm trying to get something I can finally post to the mailing list, since that's been a source of complaints on GSR. Might not happen this week, but I'm hopeful!
Also trying to do something relaxing each morning: in theory this slows things down, but in practice it's useful reflection time.