@ Super Testnet
2025-02-13 04:44:45
# How Coinpools Improve Bitcoin
# Problems with bitcoin
UX problems with base layer payments include:
- Mining fees are sometimes high
- Confirmations usually take several minutes
- Using it privately requires running a coinjoin server
UX problems with lightning payments include:
- Setup fees are sometimes high
- Payments frequently fail
- Payments aren't asynchronous (the recipient has to stand there with their device open waiting to do a revoke_and_ack on their old state -- unless they use a custodian)
- Payments that *do* succeed occasionally take more than 30 seconds (due to stuck payments, automatic retries, and no ability to say "stop retrying" in any existing wallets that I'm aware of)
- Using it privately requires manual channel management
# Solutions
A lot of my recent work focuses on non-interactive coinpools. I figured out a way to do them on bitcoin if we had CTV + CSFS, and then, with a bit more thought, I figured out that my model didn't actually require those things, so I am now working on an implementation. But my model does benefit a lot from CTV (less sure about CSFS at this point) so let me outline how non-interactive coinpools fix the above problems and along the way I will share how CTV specifically improves coinpools.
## "Mining fees are sometimes high"
Coinpools improve the problem of "mining fees are sometimes high" by letting you bypass them in more cases. If you're in a coinpool and pay someone else in the same coinpool, your payment does not show up on the base layer, it just involves modifying some unilateral withdrawal transactions such that the sender can withdraw less and the recipient can withdraw more. The transactions are off-chain, like LN transactions, so you can do that without paying a base layer fee.
## "Confirmations usually take several minutes"
Coinpools improve the problem of "confirmations usually take several minutes" in a similar manner. Payments *inside* a coinpool (i.e. to another pool user) merely involve modifying off-chain data (and revoking an old state), so they can be as fast as lightning. In most cases I expect them to be a bit faster because there's less need for pathfinding or negotiating with a variety of routing nodes. If the sender and the recipient are in the same pool, they only need to talk to each other and, in my model, a coordinator.
## "Using the base layer privately requires running a coinjoin server"
Coinpools improve the problem of "using the base layer privately requires running a coinjoin server" in two ways: first, if you're in a coinpool and you send money to a bitcoin address, the blockchain doesn't know which coinpool user sent that payment. Analysts might be able to trace the payment to the coinpool, but from the blockchain's perspective, that's just a multisig; the actual person *inside* the multisig who sent the money is not revealed. However, my model uses a coordinator, and the coordinator probably knows which user sent the payment. Still, only 1 person knowing is better than having everyone on the blockchain know.
Second, if you send money to someone *inside* the coinpool, in my model, the only people who know about your payment are the sender, the recipient, and the coordinator, and the recipient does not know who the sender is. Moreover, my model allows users to act as bridges from LN to other pool users, so even the coordinator doesn't know if the person who *looks* like the sender was the *real* sender or just a bridge node, with the *real* sender being someone on lightning.
## "Setup fees on lightning are sometimes high"
Coinpools improve the problem of "setup fees are sometimes high" by having multiple users share the setup cost. My model allows a single bitcoin transaction to fund a coinpool with a number of members between 1 and probably about 100. (The max I've actually successfully tested is 11.) If the users share the cost of that transaction, then even in a high fee scenario, where bitcoin transactions cost $50, each user only has to pay a fraction of that, where the fraction is determined by how many users are joining the pool. If 10 people are joining, each user would pay $5 instead of $50. If 50 people are joining, each user would pay $1. If 100 people are joining, each user would pay 50¢.
## Sidebar: how CTV improves my coinpool model
The setup is also where CTV greatly improves my model. For my model to work, the users have to coordinate to create the pool in something I call a "signing ceremony," which is very similar to a coinjoin. The signing ceremony has to be scheduled and each user has to show up for it or they won't get into the pool. With CTV, you could fix this: instead of a signing ceremony, an exchange could autosend your money into a coinpool on e.g. a monthly basis and email you the data you need to perform your unilateral exit. All they need from you is a pubkey, and they can do everything else.
## "Lightning payments frequently fail"
Coinpools improve the problem of "payments frequently fail" by reducing the need for pathfinding, which is a typical cause of failure on lightning. If you are paying someone in the same pool as you, you always know an exact path: it will be you -> coordinator -> recipient. These short paths also reduce the likelihood of routing nodes having insufficient capacity to forward the payment. You've only got one "routing node" to worry about -- the coordinator.
## "Lightning payments aren't asynchronous"
Coinpools *in general* don't improve the problem of "payments aren't asynchronous" but my model in particular *does* improve that problem because I am combining it with my hedgehog protocol from last year, which *does* allow for asynchronous lightning-like payments. Relatedly, my coinpool model technically has a network model, it's just a hub-and-spoke network: the coordinator is connected to every user of the pool and can forward asynchronous hedgehog payments to them. This means you can send money to someone when they are offline; they'll get it whenever they *do* get online, even if *you* went offline in the meantime.
## "Lightning payments sometimes take too long"
Coinpools improve the problem of "stuck" lightning payments by reducing the number of hops along the route. As above, a payment inside the pool (per my model) is always just sender -> coordinator -> recipient. Due to only having 1 hop, there are fewer opportunities for a node to have a network issue and cause a delay.
## "Channel management is a pain"
Coinpools have multiple ways of improving the problem of manual channel management. In particular, not all coinpool models *have* channels, so channel management is not always needed in a coinpool. My model, however, does have channels, so channel management is still a thing.
Nonetheless, my model improves channel management in two ways: first, the setup costs are lower for the reasons given above. Second, payment asynchronicity helps for the following reason:
The worst pain point in channel management *today* occurs when someone sends you a payment but it fails because you didn't have enough inbound capacity. That doesn't happen in my coinpool model because payments are asynchronous. If you don't have enough inbound capacity, the payment doesn't fail, it just remains pending. So all you have to do is open a new channel (i.e. enter a new pool) and *then* finalize the payment.
## Zap me
I hope this essay clarifies why coinpools improve the problems I outlined and why CTV improves coinpools. I also hope this gets you a bit excited for my latest coinpool invention, which I hope to release soon :D (It really is very close to demo-ready.) If you liked this essay, consider zapping me: supertestnet@coinos.io