I think it might be useful distinguish between multiple use cases and threat models for Bitcoin as a medium-of-exchange and acknowledge that these are being served by different architectures.

1. C-2-C payments

2. B-2-B payments

3. B-2-C payments

It seems to me 1. requires trust-minimization and high privacy. This use case is currently being served by LSP based self-custody Lightning wallets. And also by Cashu/Fedimint though these do leverage local trust and social incentives to share UTXOs.

For 2. and also in partially for 3. I think federations like Liquid leverage trust between businesses. So not on a local/private level but on a corporate level. Trust relationships in business can also be viewed as a type of social inventive structure to scale UTXOs but these are more abstract. So it makes sense that these federations have more members and I hope we will see more than one competing with each other.

I’m still wrapping my head around Liquid, so I need to give this more thought. But it seems useful to reason about it that way.

I am in video. And, to do it right, is a tall order.

I’ve been working on something in my spare time. It will make use of blossom and nostr for the distribution of content and discover ability, but that’s really where nostr’s reach ends.

Video needs to be adaptive to best ensure it can be watched. A lot of people will throw mp4s up and call it a day, but the content really needs to be segmented with sane, adaptive variants.

To aid/incentivize creators, as well as for security reasons, a kind of drm where they can maintain some ownership and/or proof of origin needs to exist. I’ve implemented (from scratch) all of the big DRM protocols, and they are all so close be Ming a great *open* platform - they just need to make use of a creator-owned key pair for identification purposes. What gets harder is trying to tie that with someone who pays for content, and having the option of that content being encrypted specifically for that viewer - this is resource intensive.

Finally, an open license server is needed to manage the collection of streams in a place the creator can control. I am working on this, too. I believe a creator should have the option to take down their content or move it to a different identity if they want. They can’t influence others ability to duplicate it (unless encrypted) nor block those who’ve paid for it from keeping their own local copy.

That’s just for serving the content.

You need a player, which is non-trivial. I think HLS (vs DASH) is more universal (and a shit ton simpler), and is supported by every mobile platform, TVs, and most major browsers (given a JS implementation). So I think a universal format can be achieved.

Then there’s the encoding. To have mass compatibility, you really need to narrow the options to a known “ladder” of quality variants everyone can then follow. If you’re new to video, this is non-trivial. But, existing streaming providers have already settled on a good subset (which we could reduce further - need to optimize for storage!).

It’s a thing. It’s being worked on, silently and anonymously. Security and proof of origin are, I believe, paramount to help reduce distrust.

For me, I’m looking way beyond TikTok clones. I want disrupt the fucking *media* the way websites did to newspapers. And it needs to be open and permissionless. And it needs to be *10x better* than the incumbents (YouTube, media corps). I think it’s not only possible, but likely to organically converge to a medium like nostr. It’s a race to the bottom, cost-wise, right now. We can out-perform all of these companies. But careful thought and planning is needed.

the algorithms are getting to the point where they are sending the same content to everyone. almost every platform. copy of a copy of a copy only to maximize ad impressions.

straight programming, just like the programming of radio, tv, and cable.

i want to be able to create, choose, and share my own algorithms. only way out of the bubbles being created. 🫧

Batching makes sense for pleb nodes. I am mostly interested in mobile, yes. I’m trying to keep an open mind re self-custody mobile Lightning. Though I suspect mobile wallets will start adopting more federated subnets like Liquid and Fedimint. The trust trade-off makes a lot of sense to lower liquidity needs and fees for end user payments.

Batching to open self-custody channels?

Yeah, good reply from Jeremy Rubin to that tweet

But you need coordination

What payment volume per month is required for a user to be profitable? Or what’s the minimum required ratio of active spenders vs hodlers? Especially considering unpredictable onchain fees for splicing out inactive users to regain unused inbound liquidity. How would an LSP mitigate that risk?

Bitcoin payments will always have a custodial component until someone comes up with a completely unpredictable revolutionary new idea that changes the whole game.

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!