@ Super Testnet
2025-02-13 04:32:11
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.
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.
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.
Coinpools improve the problem of "using it 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. They might be able to trace the payment to the coinpool, but from the blockchain's perspective, that's just 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.
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¢.
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.
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.
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.
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.
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.
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.)