Agreed. SIGHASH_NOINPUT has a clear use case, but got mired in the fact that it opens covenants.
None of these proposals offer compelling use cases (ie beyond, basically, refining lightning) because they are all incremental. They cater to users who *don't want to* use a UTXO, not those who *can't afford to*. And that's likely to be a narrow band of users, in the long term.
The only protocol I can conceive of which *does* give something to sub-UTXO users is a group structure where all the funds can be burned if any user proves the coordinator misbehaved (Christian Decker named this a "Nero protocol", which I like). But proving every kind of misbehavior, including failure to respond, is a very big, maybe impossible, ask. TBH, I haven't tried...
For lightning it's far less than we hoped, though not useless: there's a lightly-reviewed proposal to use it to avoid a latency hit for Taproot channels. I haven't examined carefully whether it's the ideal solution, though.
My thoughts here are definitely unrefined, but I am sceptical of the "onchain rush solved by covenants" argument.
1. You're assuming fee volatility. I expect this to reduce over time, as regular Bitcoin usages adapt their behaviour and smooth fees
2. You're assuming wallet infrastructure which is pre-built to handle this case.
3. You're changing the deal, so the *recipient* now pays fees. If you shape things as payment trees, the tradeoff gets worse (approaching twice the weight of just paying normally, requiring that much fee volatility to make sense), and you introduce games between the recipients to figure out who pays fees.
4. You have created a novel financial instrument on fee futures, not something I accept as a "payment", as I have not received it, and you've offloaded an unknown level of costs to me to "collect" it.
5. In real bankruptcy, this is *not what you want*. You don't want your funds stuck on chain. Many might want theirs transferred in one tx to Coinbase. Others will want payment over lightning, or fiat.
6. You can do this badly, today. You can publish a zero-fee tx which pays everyone, or even a tree. That at least proves you have the funds, and can be seen by existing wallets. This, of course, requires the mempool changes which James complains about.
In summary, I don't see congestion trees actually being used: certainly not for this bank-run-in-high-fee scenario.
I'm confused. If you want to know "does this have muted words in it?" that's one bit? If you want to support dynamically changing mute words then you probably do a pair of generation numbers (one for words added to mute list, one for words removed) and then recalc on the fly if it could be a false negative / positive.
The performance difference between a 50% full hash table and a 100% full is minimal in practice. And if you don't use the bitstuffing tricks of ccan/htable you will get a second cache hit to actually validate the miss.
Yeah, you don't need minimal. It's overkill: you'll never get those cycles back in savings. But ccan/htable will keep the damage to a single cache line for the common case (a miss) which is what you want.
It is the absence of God which makes me reckon with good and evil.
What would you be need?
To recycle an old joke: "Bitcoiners' self-worth reaches 90k."
The price is like the weather. People can discuss it endlessly, but unless you're going out into it, it's trivia.
Don't be the price. It's boring.
After a long day going through all 44 issues and pull requests for the milestone, and lots of hard work, I've got it down to 49.
This could take a while...
44 tasks on the milestone to go,
44 tasks on the milestone,
If I spend all day rewriting your code,
There'll still be 44 tasks on the milestone.
Feeling grumpy. Looks like release will be late. Grrr....
I can see this upsets you, and I share some of your concerns about the price distraction.
But my response has always been to continue to do engineering the best I can. I'm my experience, it's the only way I can move the needle (and even then, no guarantees!)
Programmable money was meant to allow you to specify arbitrary things on your funds in a way that was binding.
I'm struggling to find Satoshi's statement on systems which can't be interfered with "no matter how good the intentions", but it applies here. I suggest you take some solace in the trade-off: that while you can't stop people from doing bad things, bad people can't stop you from doing good things, either!
1. We had them before. Sure, we have to do them properly (not just call out to openssl) but none are particularly complex.
2. People can do undesirable things with their own UTXOs. This is a difficult truth, but fundamentally what Bitcoin was created for.
I forgot the 50% managing my team and 50% with lightning spec work!
Here are the very draft interpreter and BIPs for Script Restoration. I'm seeking comments (looking at nostr:nprofile1qqsdnpcgf3yrjz3fpawj5drq8tny74gn0kd54l7wmrqw4cpsav3z5fgpz4mhxue69uhk2er9dchxummnw3ezumrpdejqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvl3x2lg and nostr:nprofile1qqs2nep2pjnwfvfqszytdzj06eq8fqd3yps0j9dqlm95ezr524lrwjgpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdunyshzy here!) on all aspects, including format and what opcodes make sense to combine into a single proposal.
There are definitely some tweaks we could make to costing (it bugs me that the formula for OP_MUL is not symmetric, for example!), but that part is pretty solid.
Once we have a single proposal that we think is well-specified, reasonable and useful, it'll be time to get coauthors (I have a day job, and it's not this!) and formally propose it for broader scrutiny.
https://github.com/rustyrussell/bips/pull/1/
And interpreter (not other parts, so not actually usable except bench and test!):
Really nice, thoughtful panel at OP_NEXT with nostr:nprofile1qqsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nqpzpmhxue69uhkummnw3ezumt0d5hseeluvq and Jay Beddict. Good questions from Pete Rizzo, felt like we could have gone much, much, longer...
Woke at 6am thinking about Bitcoin.
Couldn't get back to sleep, so I finished first pass of my budget estimation util. You give it a script, if gives you a maximum budget it could use, or a maximum input element size it could handle.
It's approximate (doesn't actually evaluate properly), but it's an upper bound. I need to come up with some good examples though...