Mark on Nostr: Summary of how Bitcoin devs are thinking about the future ...

Summary of how Bitcoin devs are thinking about the future

quoting nevent1q…rpy8

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!