I, too, am doing conference-presentation-driven development!
taskset -c FTW: binding to a single CPU helps me reproduce these things sometimes.
Almost finished my xpay series: its had a series of epic side quests! In particular, yesterday, adding the idea of "biases" to layers, so you can favor/disfavor particular channels for routing. This is easy: the hard part is deciding how to scale it for real use.
I ended up deciding on a scale from -100 (avoid) to +100 (awesome) with useful values generally being 1 to 10. This is actually an exponential factor underneath, with +/-100 making the score 30x better or worse, which is more than enough to override everything else.
Last step is layer persistence: you want to keep that information you learned across restarts.
In addition, I'm release captain for this release, *and* I have to clean up my Script Restoration code for my OP_NEXT presentation next weekend (and write my talk).
I anticipate the 24.11 CLN release may be delayed :(
Suckage. This is finally getting fixed with package relay and anchor channels.
The engineering gods thank you for your sacrifice, though.
Stable channels were promoted as things for those who couldn't afford downward volatility.
And it's absolutely not like "buy the dip", that doesn't make any sense.
My problem with "stable channels" is not technical, but entirely around incentives.
"A banker is someone who lends you an umbrella when it's sunny and asks for it back when it starts raining".
People want downside protection. But you cannot keep enough reserves to give it to them in Bitcoin, you need some other asset like USD, which is much harder to audit.
So in practice you offer some limit on downside protection, hopefully well-documented! But no limit on upside protection. Of course if you hit the downside limit your (broke) customers leave, so your business model is likely "hope Bitcoin goes up".
This can be extremely profitable, of course. But high-risk ventures with this kind of "heads I win tails you lose" property rarely attract the most ethical of players :(
9 hours is a long plane ride? TIL!
Great report on channeld using 100% CPU and getting laggy on giant nodes. Random backtrace via `gdb -ex` showed memmove in the to-gossipd queue.
Ok, it's a bad implementation for big queues, which is easy to fix, but I also added a backtrace first time we surpassed 100k entries.
This hit *gossipd* first: and, because it was the queue to the main daemon and I'm an idiot (writing the backtrace before setting the "done-once" flag) it recursed infinitely.
But the root of *this* was a known issue, that we spam the logs when we get lots of gossip. So a log level below "debug" was added a while ago, "trace".
But we had explicit logic to suppress debug messages from making the queue too long, which *wasn't* extended for trace! One line fix.
Now, I went to look at the original issue: connectd flooding gossipd and slowing down. This is definitely possible, if we get a lot of gossip at startup: gossipd may have its hands full keeping up. But actually, I'm pretty sure what was happening was gossipd running slow *because* of the slow performance of its own queue to lightningd!
So there's a trivial commit at the end of the series which raises the queue size before reporting an issue to 250k and explains why the other commits (which didn't touch channeld) actually fixed the issue!
FIFO Sydney for cheatcode.co.uk panel: really disappointed I couldn't do the whole thing.
Hope this gave people a taste of Bitcoin developer thinking, at least!
Yep, came back after rereading to correct my mis-assumption.
Nonce could be implied or explicit here. You could use URL itself (or its hash) but good luck with canonicalizationissues :(
Not entirely sure *payer* proof is required here, but it's good practice.
This is for refunds? I think that's a different case, and should be baked into offers explicitly. Payer proofs are generally for blame and bragging...
Finally designing payer proofs, thanks for prompt nostr:nprofile1qqsr6tj32zrfn7v0pu4aheaytdnnc6rluepq73ndc2tdjzus34gat9qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhswulwwv! This proves that the invoice was requested by you, and paid, in a nice standard format. Fields which aren't needed are omitted, but you can still verify the signature.
Was a design aim for BOLT12, but now time to bring it into the world...
We produce the signed invoice (proving the node gave the invoice), and the pre image (proving it was paid). It also contains the (made up) key of the person who requested the invoice. We now need to sign something transient with that key to show we own it. I think it needs to be a simple string, because there are many cases:
1. I might want to link it to my nostr/Twitter handle or wherever I'm publishing my proof.
2. I might want to link it to my real name.
3. I might want to link it to a block hash to prove it was after some time? Then I can time-stamp pincer with opentimestamps to prove a time range of creation.
4. I may just want to attach a random snarky comment.
Finally designing payer proofs, thanks for prompt nostr:nprofile1qqsr6tj32zrfn7v0pu4aheaytdnnc6rluepq73ndc2tdjzus34gat9qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhswulwwv! This proves that the invoice was requested by you, and paid, in a nice standard format. Fields which aren't needed are omitted, but you can still verify the signature.
Was a design aim for BOLT12, but now time to bring it into the world...
Well, everyone wants it, but there is a fear of incentive problems based on what people may build. I feel we are going to be able to assess the reality of that fear in the next few years, though.
Did it have conclusions? Except that the conversation was so refreshingly thoughtful and open that it gives me faith that Lightning is in good hands.
Nothing can last forever. Our grandchildren will have their own battles, and it may be that abandoning Bitcoin will be the Right Thing.
Saddling people with religious baggage is unlikely to help: not only may you choose the wrong priorities for their future, they will inevitably get warped over time.
Always had been?