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

nprofile1qqs0zuj4s6jq9sr2ajqc69rc53d25rwpd3afcjrfm97r2qek69hcuscpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpz3mhxue69uhkummnw3ezummcw3ezuer9wc8g05gg

Publishing to

nostr.bitcoiner.social

nostr.oxtr.dev

relay.mutinywallet.com

Author Public Key

npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s

Show more details

Last Notes

2024-11-19 00:57:41

- reply

What would you be need?

2024-11-13 20:55:15

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.

2024-10-29 22:13:22

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 :(

2024-10-25 00:20:05

- reply

Sorry! Gotta live some life tonight :)

2024-10-25 00:14:38

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!

2024-10-19 22:24:35

- reply

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.

2024-10-19 22:09:01

- reply

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

2024-10-19 22:01:29

- reply

"Most charming adversary"

2024-10-19 05:43:37

- reply

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.

2024-10-18 22:06:44

- reply

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.

2024-10-18 22:04:00

- reply

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.

2024-10-18 09:37:00

- reply

Always had been?

2024-10-16 22:27:19

- reply

TIL "ineluctably"!

2024-10-16 07:45:50

https://delvingbitcoin.org/t/ln-summit-2024-notes-summary-commentary/1198
Tokyo Lightning Summit summary...

2024-10-14 21:55:42

- reply

Yes, don't use fan forced! Day 2 FTW! https://image.nostr.build/b41ef779c94d4366b744c02d4227a95968ce4d023d3abc86fa766cfaca5503e2.jpg

2024-10-13 01:31:08

- reply

1. Non-spec-final features are always behind a flag.
2. Spec final requires two independent implementations which interoperate.
3. Then @nprofile…9l4j needs to put in PR to make it on by default.
4. Then we need a release!

2024-10-11 22:03:47

- reply

Of course, CLN allows this "0.012sat" everywhere msat amounts are valid!
You do you, y'know!

2024-10-11 22:00:47

As so often, well put by Greg Maxwell:
"The whole point of bitcoin is to exist outside of any centralized control. Satoshi was clearly passionate about this. So much in our lives is mediated through centralized authorities that people seem at times desperate to hand control to someone. The things in our lives that aren't centrally controlled, like -- say-- the English language just get taken for granted. How could Bitcoin achieve its purpose with some founder around? The technology was designed so that the identity of Satoshi is irrelevant, but a lot of people have a hard time understanding that."
https://www.reddit.com/r/Bitcoin/comments/1fzi657/why_not_peter_todd/lrc6ok0/

2024-10-08 23:36:53

- reply

I have never used curl to access my CLN node?

2024-10-07 01:18:08

- reply

So... "don't use Amethyst" seems to be the answer!

2024-10-06 22:38:44

So, npub.cash and Amethyst: do I really put my nsec into the npub.cash site: that seems like an anti-pattern?
One day I'll de-custodize those sats!

2024-10-06 22:22:10

So I compromised and volunteered to talk at OP_NEXT next month, remotely. Now I need to find time to polish up the Script Restoration implementation and draft BIP, and write a talk, while at the same time we're approaching the next CLN release which *needs* all the pay improvements I've been working on.
When I overcommit like this, it's usually my family that ends up short-changed. Yet none of this can be delegated, and both are important, so I suspect that the 28.11 release of CLN may be delayed.
I keep wishing one of my kernel colleagues would want to work on Lightning: a veteran C coder with taste would be a good hire for Blockstream right now!

2024-10-04 23:05:45

- reply

And thus, test them.

2024-10-04 23:03:26

- reply

Great! You'll be happy to know that we're taking the core algorithm of renepay and using it to drive a new payments system in the next release!

2024-10-03 08:26:07

"Hand sanitizer smells sad."
My 8yo said this, and they're right. Damn.

2024-09-28 12:14:23

- reply

I have mid/late twenties friends who live on them. It's weird to me, but definitely a demographic...

2024-09-27 23:56:35

- reply

[ ] Nice idea, but it would take me longer to explain how it was supposed to be done than it would to rewrite it for you.

2024-09-27 23:54:03

- reply

The total length needs to fit in 64k, so yes. But the other fields tend to be no more than a few kB...

2024-09-26 23:45:25

- reply

Yes, but technically you always could.
Because you fetch an invoice, that invoice contains the message. And now you can prove that you wrote the message, and that the recipient received the message: the invoice they sign has your message in it, and your key (often a made up one for that payment).

2024-09-25 22:29:58

Another Lightning Spec Summit complete: this time Tokyo. The good-natured competition among the teams is a steady source of delight, for these are all brilliant people striving to bring something wonderful into the world. They are also respectful and appreciative of each others' achievements: kudos from people you respect has always been a key motivation for working on Open Source projects ❤️
I tried, and failed, to avoid committing to implementing or collaborating on more things. Many have partial implementations already, fortunately. In no particular order:
1. A "marketplace" bolt12 feature for a centralized marketplace to arrange a fee for payment.
2. Completing my draft implementation of the simplified update mechanism (particularly, reestablishment mechanics!).
3. "lnp" payment proof format.
4. Rebase recurrence proposal for BOLT12.
5. Implement v1.5 gossip (once Elle revises it again!)
6. Split keys for comms, messages and payments in node announcements.
7. Proxy support for BOLT 8 handshake.
This doesn't count the tasks of reviewing what others are working on, which our team is not leading but are very interested in: bolt12 payment notifications and contact information sharing being two at the top of my mind.
It was a productive three days. And, yes, a pile of fun!

2024-09-24 10:43:01

BOLT 12 is merged into the spec
To applause at the Lightning Spec Summit dinner! ❤️

2024-09-18 12:22:24

- reply

Possibly, but there are many easy ways of optimizing it on the CPU first. Even trying a simple single payment while calculating a more sophisticated strategy.

2024-09-18 09:38:53

Last three weeks I've been working on improving payments. Critical to this are five things:
1. Better payment routing, a-la min-cost-flow.
2. Better low-level payment injection API
3. Simpler, more reliable implementation.
4. Better simulation and realistic testing.
5. Better gossip maintenance.
For the first, I took the heart off renepay to make "askrene" the payment oracle, which provides "getroutes" for other plugins to use. A primitive version shipped in the current release, but it's already getting better as I start to use it.
Today I finished "injectpaymentonion" which takes incoming payments the same way we deal with incoming HTLCs, unifying things that were previously difficult, like self-pay and bolt12 blinded paths that begin at our own node.
Tying these together is a new plug-in called "xpay". This calls getroutes then injectpaymentonion, then iterates as results come back, feeding back information to askrene as we learn more about the network.
To figure out how well this actually performs, I've got a new format for representing topology, with minimal information (no node names, just channel capacities, details and topology). A simple tool compresses this from a node's gossip store (and decompress back for use). The result is small enough that we can include graph snapshots on our repository for testing.
Then I have written a fake "channeld" which simulates payments through this graph (it knows all the secret keys). This needs to be enhanced with simulating capacity of the channels (deterministically, based on a seed value) and realistic network delays, but it already does MPP timeouts and checks fees and cltv delays.
This should allow me to test this system's performance in a way that mirrors what people actually see, and also measure it against what we have now. It may uncover bugs, but even better it will let me know where to optimize (min cost flow can definitely be a CPU hog!).
And @nprofile…zu7w is working on ideas for more aggressive gossip gathering: if we're missing part of the map we cannot expect to have reliable payments!

2024-09-16 21:59:26

- reply

Me too. My grandfather never returned, leaving his wife to raise her newborn child by herself. You might want to pull your head out of your capitalized ass and get some perspective.

2024-09-09 09:32:54

"Oh, Rusty Russell, your posts could be a thrilling novel for engineers and Bitcoin enthusiasts across the cosmos. You have a knack for layering technology discussions with occasional witty remarks, like your delightful approach to 'weather reports' in the routing oracle—that's *totally* a fresh idea. You muse about the challenges of 'fuzzing data to avoid revealing individual payments,' perhaps because deep down, you realize that *trust* is as elusive as a lightning bolt in a thunderstorm. You remark that your coding feels complex and cumbersome, but isn't that just the nature of all true passion projects? It's like trying to solve a Rubik's cube—frustrating, yet oddly satisfying when you finally get it right. Also, the gentle reminder about re-reading 'How to Win Friends and Influence People' isn't lost on me. Clearly, all those years in tech left you pondering how to connect with 'non-Bitcoiners.' You seem like someone who revels in the complexity of existence, as reflected in your projects and discussions, and I can't help but wonder if you overthink a simple conversation as you would a cryptographic key exchange. Kudos for your persistence in transforming obscure code into clarity, even if your self-doubt pokes through like a bad joke at a serious conference. And really, the mix of personal anecdotes with technical jargon in your posts is such a unique brew—like mixing fine wine with a 2-for-1 cocktail from a bar where the bartender is still learning the ropes. Cheers to you, Rusty, for reminding us all that developing the future of payments is both a noble endeavor and an endless source of bewilderment."
#nevent1q…fury

2024-09-05 10:11:45

- reply

Oh! I'm going to be there for the Lightning Summit which immediately follows Tokyo Bitcoin: let's catch up!!

2024-09-04 21:55:17

- reply

So, askrene (the routing oracle plugin) has support for layers, each containing information about channels (also, can add/remove channels and nodes, but that's mainly for special-effects for particular payments).
It would not be hard to import/export entire layers: I've speculated that LSPs or large players may want to issue "weather reports" which could be incorporated this way. There are two issues:
1. Needs a standard format. This is easy, let's come up with something?
2. Privacy of those contributing to the data. This is hard, I don't know how to fuzz/exclude/delay data to avoid revealing the individual payments, but someone surely does?
This is absolutely a service you could charge for, too. Perhaps a free version with very rough data, and a tier with more complete data?

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-09-02 21:28:01

- reply

Anyone who can do a backflip.

2024-08-30 23:00:32

- reply

The general supposition is that it makes sharing transactions cheaper than standalone ones, incentivizing coinjoins and the like.

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-27 22:00:37

- reply

Coding *is* my hobby!

2024-08-26 21:45:28

- reply

1. I'm always interested in open source things.
2. You're in a bubble inside a bubble.

2024-08-26 10:06:09

- reply

Fixed just now, Works For Me!

2024-08-26 01:08:03

- reply

? I don't know anyone involved. But this title is poor judgement, and if nobody says anything maybe that will become a norm.

2024-08-26 00:24:01

- reply

"Gauche at best, unhinged at worst" then.

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 12:54:00

- reply

Yes! I'll ping you. What TZ are you RN?

2024-08-24 12:53:26

- reply

They're fixing it: after some testing, apparently this one wasn't our fault (on CLN v24.08rc3)
Surprised me too!

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 03:27:55

- reply

Audio should be fine. There's one graph, I think.

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:26:46

- reply

Absolutely. You can theoretically do that already, but I don't want to have to do the math, I want to just say "open a channel to X" and have it figure out where to get the funds. It might be optimal to use onchain funds, or even close down a low-utilization channel entirely into the new one.

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-21 23:37:59

#cln #dev #someday
Wallet "Intents"
With anchor channels, lightning nodes were forced to get smarter about tx construction. (Kind of funny, nobody really wanted to write a Bitcoin wallet, but here we all are). You have a deadline, user wants to spend as little as possible, you have to use CPFP to boost the commitment tx, and bring your own fees for any HTLC txs (which are now single input/output ANYONECANPAY|SINGLE).
I did the minimal things to get this to work, but it brings me back to the question of how these things *should* work. I don't think the primary interface for a wallet should be "spend these utxos to create this output" but "do this by this time, with this budget cap". The wallet should figure out how to do it.
For example: sources include onchain funds, splicable channels and even closing channels. What if the wallet code had a rough "cost" for each of these? Sinks include splicing in, onchain outputs (maybe to cold storage?) or new channels. And there are also specific txs you might want. It should combine them opportunistically (and later, pull them apart if priorities change).
There are several problems though. The first is complexity: this is not trivial to get all the cases correct, and all the combinations. The second is related: understandability and debugging is hard too: what did it do, what did it decide *not* to do, and was the result optimal? i.e. why?
But mainly, how to present this to the user? Or the plugins that they use to direct it? They need to know that funds are coming to them (especially since we low-ball fees for non-urgent things). Plugins will want to see PSBTs before they get signed, so they can do clever things (coinjoin, open new channels, combine in other ways).
The upside of all this is maximum efficiency, and a side-helping of more confusing transaction graphs. Both of which help everyone.
This is currently an idle thought: it's not going to reach the top of my TODO this year, for sure!

2024-08-18 10:40:59

- reply

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

2024-08-18 03:25:40

- reply

If you put it that way: I guess I'm also betting 2M sats it won't work :)

2024-08-17 23:17:11

- reply

Australia transitioned away from defined benefit schemes in the eighties and early nineties, and has increased retirement age (not a legal concept here, but when you can access a pension or your benefits) has been increasing too, from 55 when I was young to 67 currently.
I'm not a huge fan of the resulting system in its details, but it's a sign that people and politicians used to care about longer-term thinking. (Interestingly, these reforms were from the Left, not Right, which maybe explains why they happened?).

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:42:02

- reply

Me! I wrote an Android app years ago, but not my jam. Someone who knows what they're doing can probably do this in 1/100th of the time I can...

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-14 10:37:12

- reply

In those cases, iterate. Almost everywhere else became non-dups, so will now assert if you try to insert a duplicate...

2024-08-14 00:54:31

#cln #dev
So, we've had this annoying intermittent bug where UTXO spends would get missed. Sometimes it meant that we would keep gossip for channels which had been spent, and sometimes we'd miss opportunities to sweep funds (more concerning!). Eventually I started to suspect our (my!) hash table implementation. It's extremely efficient, but if it had some bug it could explain the issues: it has a random seed for the hash function, so weird corner cases would appear random.
I wrote some random churn tests, nothing. I could get more elaborate, of course, but then something else happened.
Shahana wrote some code to create all our new documentation examples, which involved getting nodes into all kinds of weird states, and hit a strange bug. I tracked it down to a case where the recovery code was putting a new peer into the hash table, where one already exists. Easy bug fix, but it made me wonder: were we doing this elsewhere?
My hash table code allows duplicate keys just fine. But it's actually unusual to want that, and there are APIs (get, delkey) which only handle the first one vs getfirst, getnext which are fully generic.
So, I wondered. Did we make this mistake anywhere else? I bit the bullet and split the APIs: up front you now declare what type of hash table you want (duplicate keys or nodups) and you don't even get the deceptive APIs for each case.
As you might expect, the only code which had a problem was the various places where we watch UTXOs. You can absolutely be watching for the same thing in multiple places, and indeed the code was not iterating, but only handling the "first" one.
And this was all my own code, front to back. Mea culpa.
APIs matter. The natural use of an API should be the correct one. And of course "don't patch bad code, rewrite it" a-la Elements of Programming Style.

2024-08-06 00:59:39

- reply

Sorry for the delay, I've been dwelling on this a little. I think that self-custody is easier than many alternatives, unlike with cash: I use Green wallet myself which shows how you can have support while still having ultimate control. I believe Casa have a similar product for larger custody. I hope to see this kind of offering mature, and be attractive beyond the DIY crowd: Bitcoin insurance will be necessarily limited, there are going to be more high profile custody disasters. Also, there's a possibility of generational attitude change: if fiat becomes noticably worse, many people will expend effort looking after their money.
However, that's somewhat of an aside. The question was not those who choose not to custody, but those who can't. What guarantees can we give them, if we can't give them a UTXO? I think, and hope, we can do better than "you all need to trust one of these few people". But I agree this will only get its due attention when enough people are in that group: for now, the low hanging fruit is improving lightning and other L2s which can simply fall back to a UTXO each.

2024-08-04 08:34:04

- reply

In that model, you never have full custody. Someone sends money into the mint and they hold it on your behalf.

2024-08-04 00:10:43

- reply

I've had both, but my Logitech trackball is at least 20 years old and still going strong...

2024-08-03 00:21:25

- reply

(Hi, Lyn, long time fan!)
I'd push back on this, a little. There are definitely cases where I won't have a UTXO, but all the cryptographic solutions I've seen to handle others' failure (malice or incompetence) devolve to me obtaining a UTXO.
In times (and places) of high trust people may forgo this security, but if you can afford it, why would you? "Verify, don't trust" is our entire motto at Blockstream, and while I am not my employer, it resonates.
In my mind, forgoing cryptographic protection for your Bitcoin, if enough people do it, is akin to detaching your issued currency from gold. Seemingly a minor technical detail which has no immediate effect, perhaps. Obviously nobody would be foolish enough to do that, though! 😬

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-08-01 02:05:20

- reply

I somewhat agree: "trust somebody" can be quite efficient. But it's prone to bad incentives (undeclared fractional reserve) which can drive out good actors (who are not as profitable) *then* collapse. I know @nprofile…rt7g has thought about this a fair bit, and has a rotating ecash solution which may address it well enough?

2024-08-01 02:01:09

- reply

Not really, that I can tell. The custodian you are trusting there is the miners.

2024-07-31 23:01:18

- reply

It's hard to get exact numbers, but a significant fraction of the world will not have enough money at one time to spend a single UTXO. This is clear from the uneven distribution of wealth and the inevitable rise in Bitcoin fees.

2024-07-31 22:42:46

- reply

Indeed, that's the current effort, in every direction. But it definitely has limits.

2024-07-31 22:40:38

- reply

British vs American English, sorry.

2024-07-31 09:28:22

- reply

Thanks, AI. Blocked.

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-30 23:32:02

- reply

I know, I kept waiting too!
Let me get on my desktop so I can answer properly...

2024-07-30 22:03:29

- reply

On the lite end, Blockstream Green, too...

2024-07-30 10:21:08

- reply

Not a fair assessment: scammers always want you to reassess. "Maybe he's Satoshi this time!"
After getting flooded by waves of bullshit in the form of altcoins, I chose not to waste my time. Maybe I missed some genuine innovations, but I also saved a lot of time and sanity.
With such a white-hot scamfrenzy, many of these people's introduction to "Bitcoin" was probably someone pushing an affinity scam.
That's a big barrier to overcome, no ego required.

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 02:57:57

- reply

We are definitely wrong about some things!

2024-07-28 02:53:25

- reply

Fifteen years!

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-27 01:51:17

- reply

Yes! You can *add* pubkeys!
You create a secret key, S1, give miner the pubkey P1 (= GxS1). Miner generates a secret key S2, calculates P2 (= GxS2) and pubkey P1 + P2. If it's good, gives you S2, you sum that with S1 to get your secret key S1+S1.