Rusty Russell

https://rusty.ozlabs.org

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.

Public Key

npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s

NIP-05 Address

rusty@rusty.ozlabs.org

NIP-57 Address

npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s@npub.cash

Profile Code

nprofile1qqs0zuj4s6jq9sr2ajqc69rc53d25rwpd3afcjrfm97r2qek69hcuscpz4mhxue69uhkummnw3ezummcw3ezuer9wchszyrhwden5te0vyhxummn9ekx7mp028t7pt

Publishing to

nostr.oxtr.dev

a.nos.lol

Author Public Key

npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s

Show more details

Last Notes

2024-09-04 09:18:27

I'm working on a new pay plugin called xpay (working title). It's designed to use the new (very WIP) askrene plugin, which provides routes. Actually, most of the work is there, fixing and enhancing that. Especially diagnosis: *why* did it give a weird/no route? Common issues are: there's a good channel but it's offline, or doesn't have capacity, or you don't have enough capacity at all, or the recipient doesn't. We've had issues where gossip is missing, too: detecting when that happens is an open research question, but we'll start probing more aggressively.
There have been many complaints about pay in the wild, and the code has grown quite complex. I've heard good things about Boltz's mpay, which is far simpler, so I'm inspired to go in that direction. Moving the routing (which *is* complex!) out is the first step.
To be honest, I should have taken a direct interest in this earlier. I considered pay a simple problem, or at least not one I needed to concern myself with. But better late than never!

2024-08-29 22:06:50

Started working my way though the classic "How to Win Friends and Influence People" with my 10-yo. I should have re-read this years ago!
It's a classic for a reason. All self-help books have to spend 50% of their time convincing you it's worth reading, and the remainder is the actual content. This is why the title is so off-putting to many, BUT the book itself is a gentle admonition on the requirements for nuanced empathy in human interaction, with a very reasoned approach.

2024-08-26 10:06:09

- reply

Fixed just now, Works For Me!

2024-08-25 23:39:25

- reply

Your title is offensive, the question is, is Jeff ok with it? If he is, perhaps it's edgy and clever. If he isn't, it's gauche at best, unhinged at worst.

2024-08-24 11:16:35

I tried (and somewhat succeeded) in taking a week off work.
Unfortunately, I did rework the nostrdb cursor code, because it annoyed my sensibilities of how iteration across protocols should be written.
I'm still not happy with the results, but I did find some bugs!
And reading code by changing stuff and reading the compiler errors has another problem: I still don't know exactly what this code is trying to *do*!

2024-08-23 02:20:07

#gsr
I had a quick call with Brink engineers, on my Script work. Now I just need to polish things a bit more and actually release a prototype that people can sink their brains into...
https://brink.dev/blog/2024/08/22/eng-call-great-script-restoration/

2024-08-22 02:27:38

- reply

And of course, since it's making a tx already it might be a good time to cross-splice funds from once channel to another...

2024-08-22 02:22:38

- reply

Then it depends entirely on who will watch? Neither Schiff's regular audience nor Bitcoiners are going to be persuaded.

2024-08-21 23:38:49

- reply

Are you going to change anyone's mind?

2024-08-18 10:40:59

- reply

Yeah I've been reading your parsing code. We have to talk 🤣

2024-08-17 22:36:51

- reply

@nprofile…6h5g put his hand up first, hes taking a look. I think the coding might be the easy part though: getting the PR merged is another thing altogether...

2024-08-17 06:27:15

- reply

Simple rework PR up. I also want to update your BOLT11 parser to the latest (it's buggy).
I need to think harder about your cursor API: my instinct is to split it into two types, one for reading, one for writing. But you do a lot of lookahead in your parsing, so the classic "mark cursor invalid if we hit an error" pattern doesn't fit. Hmm....

2024-08-17 03:43:23

- reply

Let's see what I can do after lunch then. Fun!

2024-08-17 03:21:48

Any Android devs out there? I will pay 2 million sats for someone to implement the option to customize Signal notifications for *reactions* separately from new messages.
Conditions:
1. Ping me first! It's not a race, you gotta get public agreement from me to enter.
2. Gotta get it merged and shipped so I can install it on my Android phone.
3. You have to have fun!
References:
https://community.signalusers.org/t/mute-custom-reaction-notifications/14931/20

2024-08-17 03:04:00

- reply

Yeah, it's a well-kept secret unfortunately.
Rough skimming code review:
1. bool is your friend, int is for old people :(
2. You should use ccan/ directly not in pieces: easier to update.
3. Your cursor API makes me cry, can I rewrite it? It's going to hurt somebody.
4. Do you want neatening pull requests?

2024-08-17 01:31:12

- reply

Reviewing. You should have used tdb, of course, but as Tridge said, you don't need an excuse to rewrite something!

2024-08-17 01:26:19

- reply

What format/how do I create "queries"?

2024-08-17 01:20:33

- reply

Otoh, I can't see your replies in gossip. So...
Otherwise I'd be posting my adventures in trying to install notedeck here...
(Cargo gets egui-winit, which wants a newer rustc (!!) than the Ubuntu install, so now I'm trying to use rustup. Which doesn't do anything until you read the docs...)

2024-08-17 01:11:45

- reply

Wow.
I take it back. gossip is not clunky!

2024-08-17 00:49:43

Linux desktop nostr apps? I'm using gossip, but it feels clunky.
Prefer desktop for writing detailed posts: mobile is optimized for consumption, not production :(

2024-08-16 12:05:36

It's 50 years since the greatest book on programming was published! Elements of Programming Style.
A few years back, when I couldn't find mine, I swept up a half dozen copies and Niftynei mailed them to me.
https://wikipedia.org/wiki/The_Elements_of_Programming_Style

2024-08-02 09:09:08

- reply

So far I've got the RPI3, RPI5, my Intel laptop and my AMD build machine. Neither of the last two are recent, but I'm not really interested in speed records.
There's some variance: the RPI5 wins at SHA256 for example. The RPI3 loses at everything:) There's real variance in the "fast" ops between RPi and x86. I'll post more when I'm at my desktop.
Importantly, I'm benchmarking the actual opcodes, run through the script interpreter. I really want to benchmark the complete set to make sure there are no surprises...

2024-08-02 07:39:18

Jeremy Rubin asked on Twitter what was happening with #GSR. Good q!
After far too much fiddling with benchmarks I now have preliminary numbers. Budget is 5200 varops per weight. Fast ops (compare, zero fill, copy) cost 1 varop per stack byte. SHA256 costs 10 per byte. Everything else costs 2 per byte.
I need to clean up my benchmarks so everyone can run them, and get "on your machine the worst case validation would be <X> seconds, doing OP_<Y>". That's concrete and gives us a chance to find any wild machines which are unexpectedly slow, and gives a tangible worst case, which should allow fruitful discussion
I also need to write code to answer "what input size (if any) would cause <this script> to exhaust it's varops budget?". This again enables us to think concretely about my thesis (yet to be proven to my satisfaction!) that it's possible to have a budget which allows any reasonable scripts not to worry about it.

2024-07-31 09:26:18

- reply

Yes. If you're going to use a custodian, ecash is a win.

2024-07-31 09:24:55

- reply

Liquid is a "trust someone" solution. There are precautions to avoid targeting particular users (confidential amounts and assets) similar to ecash, but it's still a custodian.
We can certainly argue it's a "good enough" custodian, given the number, reputation and legal consequences of failure, but it's still a custodian.

2024-07-31 00:44:12

- reply

First up, I want to recognize that this is an uncomfortable topic! Bitcoin is inevitably changing towards user-pays, and that's not all positive. But facts we don't like are still facts: can't engineer a solution if we can't think about the problems.
There are three kinds of bitcoiners.
A. Those who can afford any fee.
B. Those who can afford a UTXO, but not often.
C. Those who can't afford a UTXO.
Nobody worries about the A group (and in the early days, that was everyone). Obviously Lightning (my area!) caters to the B group, and we want it to be as large as possible. To do this we can (1) make lightning as resiliant as we can so onchain spends are rare, (2) make bitcoin as efficient as possible so we can cram as much as we can into what we have.
(1) Making lightning more resilient and reliable is engineering. Lots of people working on this, even before we get soft-forks which could help further.
(2) More efficiency has two benefits: obviously if your own onchain spends are 20% smaller, that's 20% cheaper. But if *everyone's* onchain spends are 20% smaller, that means fees are lower *for everyone* too (and it's non-linear). So we really care about all Bitcoin usage! Some things are obvious wins: Taproot so you can avoid even putting the script onchain in many cases, FROST so you can cram your 2 of 3 or other scheme into a single key and signature. We know we want to get more aggressive with sharing one signature across multiple inputs (Cross Input Signature Aggregation), but that needs a lot more research, and a soft-fork.
But even with all these, the math is clear: some people, even if you somehow gave them their wealth in a UTXO, it couldn't afford its own fees to spend. The C group is real. Spoiler alert: we don't have an answer for this! But let's look at some approaches people have tried.
Firstly, there are attempts to move these people into the B group: give them long enough that maybe fees will reach a point they can afford. This seems unlikely to me:
1. As fees increase everyone will start doing the work to take advantage of low fee times, and that itself means that low-fee times won't be so low.
2. These schemes tend to increase onchain footprints, so they need fees to drop a lot to overcome that (typical is 2x the transaction size, so you need fees to halve to gain anything).
3. If you really can't afford the fee, you probably also can't afford to wait.
4. You still haven't actually dealt with those who really, really can't afford the fees. Ever.
Another suggestion is that someone (e.g. a lightning service provider) will lock up funds which would cover fees, in case something goes wrong. This doesn't work economically, because nobody is paying $100 for a $5 user (not at scale), but it doesn't even work mathematically: the reason some people will have small UTXOs is because there are not enough sats for 10 billion people with any realistic distribution.
There are two basic approaches left:
1. Group people, so they fall into the B category (i.e. onchain tx is possible, but expensive).
2. Trust someone, but rely on incentives.
1. Grouping people is possible, but they need to work together if somenthing goes wrong. So grouping inside a community is probably better than grouping with randos.
For example, there are various tree-of-transaction schemes where you go onchain only if the coordinator fails/goes rogue, and how much it costs you depends on whether anyone near you in the tree pays to get themselves out. These are basically free if nothing goes wrong (one UTXO required for thousands of users!). But this is subject to ghettoization, where the coordinator makes sure all the C people are grouped together, knowing none of them can afford the transactions they need to get their funds back. It's particularly bad because the coordinator can insert its own fake "whales" to make it look like it's not ghettoized.
You can play with incentives here, too: more research needed. The details matter!
2. Relying on incentives.
As a simple example, lightning-connected e-cash mints. They can't rug individuals very easily, they have to rug everyone together (or go fractional and rug the last ones to exit). Maybe with enough anonymity and reputation, these would be Good Enough.
More ambitious would be a single UTXO held for multiple people by a coordinator. Can we make it so that if a coordinator is dishonest, you can force them to burn your funds? Maybe burn more than your funds (ie. a bond)? Won't get your money, but it aligns incentives so they're not motivated to rug you. The details here really matter!
There's a cute scheme which has been proposed where the coordinator pays a temporary bond, and asserts that they actually have everyone's signature to transfer the funds. If nobody challenges within a week, they get the bond back and the funds move. If someone challenges, all the signatures are put onchain, and if they're not all valid, the bond gets half-burned and half-given to the (successful) challenger. This is hard to make work, though. Someone needs to get the money to challenge (hard if you don't have the money in the first place, plus it's hard to prove to someone you *didn't* sign something!), and then make sure nobody gets the challenge bond before them (in particular, a dishonest coordinator, seeing the game is up, completes the successful challenge *themselves* and gets half their bond back), and make sure someone can't grief and delay the settlement indefinitely or bankrupt the coordinator.
More research needed, here, too.
Summary
A longer post than I had expected to write. And it's buried in the middle of a thread nobody will read. (I do this sometimes. I suck at marketing I guess!)
Sub-fee bitcoin amounts will have tradeoffs, involving trusting someone who has more money than you (at least, in someone's competence, even if their *financial* incentives can be made to match yours). This is difficult to build well, and not a very exciting thing to build today, so it hasn't really happened (custodial things are much, much easier!).
This is also a key reason I believe we need to make Bitcoin more expressive: if we can do *more* with our own UTXOs, we can build better solutions. And by "we" I mean "someone smarter than me" of course!
Feedback welcome!

2024-07-29 22:05:39

I'm disappointed that @nprofile…kr48 never got an answer to his question about what Bitcoin looks like to those who can't afford a UTXO.
This is an important question, maybe *the* important question. But it also underscores how much he diverged from his "pleb everyman" origins: this is very much not a newcomer question!
Guess I won't be on WBD to answer it, either!*
*Spoiler: I don't know the answer, but I can describe the possibilities and issues people can (and are!) exploring...

2024-07-29 07:46:17

- reply

Your willingness to enforce your supreme knowledge of right and wrong is WHAT MAKES BITCOIN GREAT

2024-07-28 21:43:23

- reply

🤣
Bitcoin: it's all about telling other people how to use their genitals!

2024-07-28 00:41:34

I am sometimes haunted by the phrase I heard log ago from Eben Moglen:
It's wrong to be right too soon.

2024-07-27 01:55:26

- reply

Lol, everyone is female except for birth defects :)
"There's a lot at stake". I disagree: there are a lot of people very upset at others' choices. It's a moral panic.
I've heard all this before, too. Gotta go pray the gay away...

2024-07-26 03:25:40

- reply

Ignoring, for the moment, that real biology is more complex than that:
Messing with people's societal expectations has always been a part of the hacker ethos. Coming from a conservative background myself, I used to find this shocking, too!

2024-07-19 01:06:42

https://bitcoinmagazine.com/culture/reflections-on-bitcoin-culture
BUT BITCOIN WAS SUPPOSED TO DEFEND MY IMPLIED PRONOUNS!!!!

2024-07-17 23:35:18

- reply

I would have answered very differently in my youth. Diplomacy, empathy, social situations, relationships: these improve with practice!

2024-07-13 01:44:29

- reply

"non-binary" is a gender term, surely...

2024-07-13 01:20:50

As I've aged, I have come to terms with people not asking my permission or seeking my approval.
Surprisingly often, my disapproval was just glass shards I was feeding myself. So I stopped.

2024-07-13 00:54:35

- reply

Gender, as in "which box do I put you in" has always had exceptions. This is new to many. But I am old and sheltered enough to remember wrestling with homosexuality's existence, too.

2024-07-12 14:26:24

- reply

Good point: where are the hot gay Bitcoiners at?

2024-07-12 10:16:31

Most of my friends are non-Bitcoiners. A significant fraction are non-binary, an even larger number are neurodiverse, and many are half my age: a great variety of fascinatingly different humans!
It's OK to be weird, and it makes our world more interesting. If that makes me outside someone's "ethos of Bitcoin" I think they misunderstand what Bitcoin is for.

2024-07-11 22:31:48

#cln #dev
Finally catching up with the latest BOLT12 spec, and damn, Phoenix just announced BIP 353 support. Gotta code faster!

2024-07-05 11:48:05

- reply

You don't need to *ask* a public node to route for you, they can't really tell you're using them this way.
The web->LN issue is real: no certs, no web for you!
Getting an invoice without waking the node seems to require PTLCs.

2024-07-04 10:07:39

- reply

Lunduke should always be taken with a large pinch of salt...

2024-07-03 03:57:00

#dev #CLN
I've spent the last few workdays completely reworking our onion message code. This was scattered in various places and I wanted to unify it, and also written several years ago and I'd forgotten how the protocol actually works!
onion messages are *double* encrypted; this is the main source of confusion! At the high layer, they're a series of nested encrypted calls ("onionmsg_tlv" in the BOLT 4 spec), so each recipient decrypts and hands it on: this is exactly the same as we use for payment information. But inside that is *another* encrypted blob (onionmsg_tlv.encrypted_recipient_data), which requires a tweak which was handed to you alongside the onion, for you to decrypt (into an "encrypted_data_tlv"). Inside that is all the information about where to send next, any restrictions, and allows you to calculate the *next* tweak to hand on (it can also override the next tweak).
The double encryption is necessary because there are *three* actors here: Alice wants Bob to send her a message, without revealing her identity. So she gives Bob a "blinded path" which goes via Charlie: this path contains Charlie's pubkey (where to start the path), a blinding tweak, and two encrypted blobs for Alice to put into each layer of the onion message. The first an encrypted blob which Charlie can read, which contains her pubkey so he knows where to send it next. The second is her own, and contains a secret specific to the purpose of this message, so Bob can't play games trying to use this blinded path for anything else ("hey, are you the same node as this previous payment?") or use a different blinded path for this purpose. She can also add dummy hops (we don't yet), which she will simply absorb, to obscure the path length from Bob. You can add padding to make the hops indistinguishable (we don't yet).
Bob puts the actual stuff he wants to send Alice into the final onion call (often including his own blinded reply path!), along with the encrypted blob.
Importantly, even if Bob were sending a message *not through a blinded path* he would use the same double-encrypted format: that's so Charlie can't tell whether a blinded path is being used or not, even though it's slightly less efficient. Crypto is cheap these days, too.
Now, if Alice gives Bob a blinded path to Charlie and Charlie is Bob's peer, he can simply send the onion and the first blinding tweak to Charlie. But if Alice needs to send the message via Dave to Charlie, she needs to prepend a step. That's not quite possible, naively, because blinding tweaks are generated *forwards*, and she needs Charlie to get the right blinding tweak from Dave, and Alice has no way of making that happen. So inside Dave's encrypted blob, she uses next_blinding_override to tell Dave to hand that blinding override to Charlie instead of the normal one. I just implemented this for Core Lightning (previously we would simply connect to the first node, which is privacy-compromising and should only be done as a last resort).
These blinded paths have some nice properties: you can't use part of them (you don't know the blinding factor except for the first one, so you can't start in the middle, and you can't replace any data), you need to use all of them. They can contain timelimits to avoid easy probing, too: a classic measure would be to see if the path fails when a given node is down, but that takes time. The spec insists all errors within the blinded path are the same, and originate from the entry: this loses some analytical power on failure, but makes probing harder. The entry point is supposed to add a random delay (we don't yet!). There may still be implementation differences, but they're hard for Bob to probe (and Alice doesn't need to, as she set up the path).

2024-06-12 00:01:25

Sneak peeking at new bolt12.org re-wrought by @npub1spr…8s72 (especially Stephen DeLorme, Brandon Lucas and the Bitcoin Design Community incl @npub14vn…s0ny). So.... pretty....

2024-06-11 09:42:31

- reply

No segwit, no lightning.
You really don't understand Bitcoin, so I'm going to balance your opinion appropriately.

2024-06-11 09:17:44

- reply

How did this "spam" affect you, if you're not complaining about fees?

2024-06-11 09:16:54

- reply

Right, so no lightning at all for you then?
At least that's consistent. No zaps for you then!

2024-06-11 02:47:29

- reply

"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.

2024-06-11 02:35:12

- reply

"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!

2024-06-10 22:20:47

@npub1tea…gq5u Verifying My Public Key: "rusty_twit"

2024-06-10 00:08:26

There are always many things you can do with your time, but implementing silent payments (https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) for Core Lightning is rising in my to-do list.
Unfortunately, we are all PSBT internally, so we need support so we can receive, which the authors argue (sensibly) should be the first priority for wallets. There's a delving post on this, so I did my bit by annoying Ava Chow into looking at it. We can probably hack in some experimental thing if we need for now, but proper support on libwally would smooth the path for Blockstream Green in future, which frankly is a much bigger win than CLN support.
Looking forward to the day when they're not "silent payment addresses" but simply "Bitcoin addresses".

2024-06-09 06:28:51

One day I will reach the pinnacle of nostr technical capabilities, and be able to access my npub.cash funds. Right, @npub12rv…85vg?

2024-06-09 03:01:55

- reply

For better it worse, the sophistication of scripting doesn't seem to matter: if you give $1M to the first non-coinbase tx in a block, eventually miners will write systems to take that money :(
If you write any protocol where you let miners choose the winner, you get this problem if the effect of winning is economically significant. Of course you shouldn't create protocols that stupid, but when there's a race to collect money from gullible people, engineering very much takes a back seat.
The real defence seems to be that economically useful actions on Bitcoin can outspend stupidity over the long term. I certainly hope this continues, and I suspect (though cannot prove!) enabling more people to use Bitcoin economically will further tip the balance in its favor.

2024-06-09 02:39:34

- reply

What changed, then? You would not have enabled lightning?
There is a change we want to make lightning simpler and more efficient as well as multi-party. It's not a complex change: in fact there are several ways we could do this. But I assure you that the reduced Script we have today does not allow " everything else... built on layers" :(

2024-06-08 14:13:55

- reply

Indeed! But if I try to argue the analogy, I might say "Satoshi glued the ailerons into a fixed position as an emergency stabilization procedure and we've been flying like that ever since". But there's no evidence that any conclusions we you might draw from that are actually useful in real life!

2024-06-08 03:11:58

I listened to the What Bitcoin Did Saylor podcast, and I really want to respond, though that may be unwise. But I want thoughtful, fearless content in my feed, so I should start making some, right?
Firstly, while analogies can provide useful guide rails for understanding, listening to people *arguing* using analogies makes you stupider. Debate the thing itself, not the words about the thing: it hurts my head to even think about doing this, so I won't.
Let's set my priors first: I assume we're talking about technically solid, well-vetted, backward compatible protocol changes: this is the minimum bar.
I don't wholesale agree with Saylor's "don't threaten anyone's investment" hard limit. This has happened multiple times in the past, from the dust limit breaking SatoshiDice, enabling Lightning threatening miner fees (real or not), and segwit breaking stealth ASICBoost. These interests can, and will, stand up for themselves and will compete against other benefits of changes.
To be explicit: I consider any protocol change which makes block space usage more efficient to be a win!
Obviously Saylor is invested in Bitcoin the asset, and can afford to do all his business onchain in any conceivable scenario. His projection of a Bitcoin world in which there are 100,000 companies and governments who use Bitcoin as the base layer is interesting:
1. This does not need "smart contracts", just signatures. By this model, Bitcoin Script was a mistake.
2. It can work if Bitcoin does not scale and is incredibly expensive to spend and hold. By this model, the consumer hardware wallet industry is a dead-end and needs to pivot to something else (nostr keys, ecash?)
3. You could do this with gold, today? Bitcoin here is simply an incremental, not fundamental, improvement. I think this is suggestive, though: that such a network would not be long-term stable, and very much subject to capture.
4. In this view, Saylor is simply a gold bug with first mover advantage, shilling his bags. That's fine, but it's important to understand people's motivations.
5. This vision does not excite me. I wouldn't have left Linux development to work on making B2B commerce more efficient. I wouldn't get up at 5:30am for spec calls, and I sure as hell wouldn't be working this cheap.
I believe we can make people's UTXOs more powerful, and thus feel a moral responsibility to do so. This gives them more control over their own money, and allows more people to share that control. I assume that more people will do good things than stupid things, because assuming the other way implies that someone should be able to stop them, and that's usually worse.
I believe the result will be a more stable, thus useful, Bitcoin network. I am aware that this will certainly benefit people with very different motivations than me (Saylor).
Thanks for reading, and sorry for the length!

2024-06-01 23:05:17

- reply

But there's a well-known business model where you only allow one-way trade for your tokens. It's very lucrative if you have volume, as people over buy and then can't trade out easily. Think parking meter minutes, in-game currency, mobile phone credits, gift cards, airline miles....

2024-06-01 04:17:32

- reply

I don't see any evidence in your post, just hope?

2024-05-31 23:23:09

- reply

I don't usually comment, but since I'm trying to do nostr-only content...
Ecash can be helpful or a hindrance. Basically, if the norm becomes closed non-fungible systems, where you cannot get out (think gift cards, arcade tokens) that's a clear lose. Unfortunately running a system like that is great for the person running it.
On the other hand, if the expectation is fungibility: that you can seamlessly lightning out 24x7, and mints which don't do this are widely eschewed, then the promise is great.
I hope for the latter, but fear the former. If the pioneers set the social norms correctly, it might just work though.

2024-05-30 23:56:30

#dev #cln
Yesterday I brunched with a friend, that turned into lunch. I try to catch up with a friend every week or so, to keep my work hours contained.
Nonetheless, I continued my work on connectd: it now limits the rate it will stream gossip (1MB per second should be enough for anyone!) but this doesn't apply to responses to gossip queries, which get handed off to gossipd to answer. Connectd has the gossip store open to stream it: if it simply switches to our gossmap library it can answer these queries itself, and rate limit the processing correctly.
It also means that it will be able to look up node announcements for connections itself, rather than having them fed from lightningd as now. This simplifies things, and even more once I have connectd automatically reconnect to important peers, rather than waiting for lightningd to tell it to reconnect.

2024-05-27 09:45:14

#dev #cln
More work on askrene today. The infrastructure basically done, now I'm stealing Eduardo's min cost flow code.
But even that isn't trivial to drive. You get the min cost flow but the resulting path might be too expensive, or too unlikely, or too slow, and you need to tweak parameters (fees vs probability vs delay) then ask again. The current code does a binary search for this over a mu value from 0 to 127, so 7 times. I need to play with this, as I suspect we can shortcut this if we're "good enough".
Once you've got that, you look at htlc_max and htlc_min that had been published on the channels: you might have violated that too! If you hit the min, you remove that route and block the channel from future attempts. If you hit the max,, you reduce the amount you send down that route. Then you have some sats you still need to send, so you ask the min cost flow solver for the solution for just that part. This is actually unusual though: most channels route most payments.
The question is, how much goes inside the pay oracle, and how much can we punt to the caller? I think the caller can only specify the max fee and max delay, and the oracle needs to give the highest probability routes within those constraints.
I hope to have something tomorrow, but it's going to need a lot of tests! Fortunately this should be easier to test than a complete pay plugin.

2024-05-23 23:56:59

With remote interviews the norm these days and I've taken to using a "runaway" mode where I talk long-form rather than let the interviewer drive.
Maybe I should slow down, and try to answer each question with two different takes to let the interviewer choose the path?
#nevent1q…38w3

2024-05-22 07:20:41

Today, I got back to working on "askrene" for Core Lighting. The idea is to extract the core logic of the experimental "renepay" plug-in into an Oracle you can ask for routes (and provide feedback on what happened). This is much more composable: anyone can write a plugin which uses this information, *or* an alternate pathfinding plugin to replace it.
It's built around the idea of "layers" which are where information lives: you tell it what layers to use when you ask for a set of routes. This has many uses: you might have route hints or blinded paths you want (or have to!) use. You might want to constrain a payment to a particular channel for rebalancing, etc.
In theory, these layers can be exported and imported: you can share information about the state of the network between nodes. I'm sure there's a pile of obfuscation needed to preserve privacy in this case, but it's an interesting idea...

2024-05-21 23:56:47

- reply

Except, Amethyst on Android. No NIP-7, no NIP-46. I guess most people use a web extension? Hmmm, trying nkcli, wish me luck!

2024-05-21 10:39:59

- reply

I gotta write some code for that! Hard to do on mobile...

2024-05-21 10:27:07

Since returning from Bitcoin++ in Austin, I've been trying to alternate between working on Lightning one week, and Bitcoin hacking on the other.
Mainly, I've been finishing my Script interpreter cpp modification so I can make more comprehensive benchmarks. I've also given in and ordered a raspberry pi 3, 4 and 5 to benchmark.
I hope to answer the key questions on what a realistic budget for large stack objects should be. In particular, there are four reasonable limits on their size (I'm not considering changing the 1000 stack element limit, since that seems roomy!)
1. 520 bytes. We are here now, but as Script gets better that will be very limiting.
2. 520,000 bytes: simply limit the total stack size, not individual entries.
3. 4,000,000 bytes. This allows you to put the largest possible transaction on the stack. But you need a total limit of at least twice this, so you can make a copy: you can't do much in script without doing this!
4. 400,000 bytes. If number 3 is too much of a reach, this means you can put any standard tx on the stack. Again, you want a total limit of at least twice this.
My laptop, with something stupid like 26MB of level 3 cache, and my build machine with 32MB, can handle this fine. But what about the Pi?
I'll find out next week...