#Bitcoin #dev #GSR
At https://btcplusplus.dev/ in Austin I presented my work on restoring Bitcoin Script. Script had an emergency amputation in 2010 as there were no limits on resource consumption; restoring it means solving this problem.
My proposal is a runtime limit, similar to Taproot's runtime sigops limit, called "varops". How much you get depends on your transaction size (ie how much you paid), similar to sigops.
But how much should operations cost? I had a cost model based on "worst-case bytes touched" for each operation. I've spent the last few weeks doing increasingly precise micro-benchmarks on my laptop, my build machine, and various Raspberry Pi.
There's bad news, and good news....
I couldn't find anything on the OpenSats site about how long LTS grants are? A year, three, five, ten? Paid monthly, annually, time-locked?
Python: it just works, they said!
We've generally had less problem with Rust, though that's still optional. Though OMG is it slow...
For us, it's often how slow the CI is. cpuset can be used to reproduce this...
Yeah, we need to handle (non-trivial) blinded paths in offers. I've assigned this to me for next release.
We try hard not to do that! Backwards compatibility should always be the default
#dev #CLN
One of the fun things after a release is that I sweep the code and remove things which are now past the end of their deprecation cycle, and then update to the latest BOLT specs. The former is usually trivial (this time there were only two things to remove, and nobody will care). The latter can be more interesting, and was.
Our code contains quotes from the BOLT they are implementing, so when we update the version it reports what has changed. Sometimes it's merely a typo fix, but since last release we actually made a pile of old features ASSUMED. This includes "option_static_remotekey" which we supported in CLN since January 2019 release, meaning you will only see channels without this if they were opened more than 5 years ago. We still support these existing channels, but all support was removed for opening new ones.
The other option is "option_anchor_outputs": we were the only ones to ever deploy this, and then only in experimental mode, because zero-fee anchors quickly replaced it.
Unfortunate to I don't know how many (if any!) such channels there are!
So what do we do about existing channels? I can enable the currently-experimental code to migrate such channels, which works if both ends are CLN. But it's not clear how much further I should go: my spec proposal for upgrade has been in limbo for years, and at some point it's far cheaper to pay a handful of people to reopen their channels than it is to do the engineering required for migration.
It's a few versions away yet, but at some point we will have to refuse to upgrade if the user has such a channel, in the hope they will contact us if it happens.
You can definitely learn what "common opinion" is. And yes, a stopped clock is right twice a day, so you might learn something.
It's not an efficient use of my time though...
Great podcast: I gain thoughtful insight from an expert in a field I'm not an expert on.
Good podcast: I gain minor insight into how to discuss a field of my expertise.
Bad podcast: Someone who knows no more than me about the subject.
It's ok to not know something! But I wouldn't go on a podcast and discuss AI. Or business cases for Bitcoin, nuclear power, economic incentives, politics, nostr...
I fixed all the compat issues I know of in the (very fresh!) latest CLN release: are there more?
There is definitely more work to do, especially on privacy: blinded incoming paths for offers especially.
Sneak peeking at new bolt12.org re-wrought by nostr:npub1spralxq6jlw5rdy0249vqr5sh43rfrlx2wzv3rhjjqedw559w9psrs8s72 (especially Stephen DeLorme, Brandon Lucas and the Bitcoin Design Community incl nostr:npub14vnjvqrdxa3q2353gm0lla3hsxl354nmxhzkmkj8tarns0m8psxq0ss0ny). So.... pretty....
It seems to be supported by gossip, but it doesn't actually work.
This is nothing to do with Taproot or Segwit. You are very confused.
No segwit, no lightning.
You really don't understand Bitcoin, so I'm going to balance your opinion appropriately.
How did this "spam" affect you, if you're not complaining about fees?
Right, so no lightning at all for you then?
At least that's consistent. No zaps for you then!
BTW "It is not possible to delegate the work without delegating the key (supposedly)" is wrong: you can definitely do this! Various vanity address generators did this back in the day, for Bitcoin.
"Bitcoin is feature complete."
You keep repeating this mantra. When did this happen? Before or after we did a soft-fork to enable lightning? It seems you are unaware of this?
Because there are things like vaults which do require additional features. Similarly multi-party lightning.
Your absolutist position seems quite hard to justify, though I'm trying to give you an much credit as I can, lest this become Twitter.
"Segwit and Taproot helped produce the spam that's currently attacking the network."
This is simply wrong. Segwit increased block size, so you could pack 4MB instead of 1MB into blocks. This worst-case was well understood. And indeed, most nodes didn't notice (block relay is not the majority bandwidth for default nodes).
Without segwit, the spam would have driven up fees much more: they were clearly prepared to spend the money!