Current state of my coinpool software based on hedgehog -- which now supports asynchronous payments *even when* routed over a network!
Discussion
A coinpool is a type of bitcoin L2 that allows multiple users to deposit funds into a multisig, in such a way that they can withdraw their deposit without needing any additional trust assumptions beyond bitcoin's standard ones (e.g. that miners won't do a 51% attack)
While a user's funds are in the pool, the user can *also* spend "partial" amounts of their deposit, in such a way that it’s not possible to tell from the blockchain which pool user spent the funds
My implementation has a few extra features: (1) every pool member can send and receive money via lightning (2) and/or via hedgehog (3) inside the pool, all transactions are free (4) thanks to hedgehog's support for asynchronous payments, you can send someone money even if they are offline, and if *you* go offline, they can still take the money you sent them
This is awesome
How are fees managed at the chain level?
Does there still need to be a budget for transaction fees to be covered? Especially for force withdrawals.
Who pays the fees:
1. When the first person withdraws on chain.
2. When the funds are all dispersed on chain.
Other scenarios?
There is no fee budget for the coinpool. Instead, I use the new v3 transaction standard so that the following holds:
When the first person withdraws on chain, they pay for their exit transaction via child-pays-for-parent. The same applies for every subsequent user who wishes to exit.
There is no situation where the funds are all dispersed on chain at once. Instead, only one user may do a force ejection at a time. If two try to force eject themselves at the same time, it's a race condition, and the loser may have to pay an extra tx fee.
Also, force ejections are a lot like force closures on LN: users are not expected to use them. Outside of accidental usage, you'd only realistically use one if the pool manager disappeared and you couldn't get out via the "happy path" -- which is just sending all your money out via a lightning transaction (or hedgehog).
Is there a mermaid diagram for how this works? I'd love to learn more about this.
not yet but let me tell you my plan:
I am done with all the hard parts so work is moving a lot quicker now. The next thing I plan to do is switch the backend so that it stops using NWC and starts using Electrum, that way I can run it on testnet.
Then I plan to make a testnet demo site with a pretend shop connected to hedgehog. You'll be able to deposit some bitcoins to a self-custodial coinpool wallet where the shop is the manager, buy fake items using hedgehog, and withdraw your money cooperatively via lightning OR unilaterally via a force closure.
Then I plan to make a proper video explaining how this works as well as start on the educational material I plan to present at bitcoin++ Floripa: https://btcplusplus.dev/conf/floripa
Exciting, been waiting to see something with hedgehog
Damn I forgot about hedgehog
For the sad path - does each participant have to do 4 txs or is it 4 txs per pool?
Is there a way to make the malicious pool manager pay for the exit txs, e.g. by initially having some bond?
> does each participant have to do 4 txs or is it 4 txs per pool?
It's per user. Each user creates 2 transactions to force eject themselves from the pool, which puts their channel on chain. Then they do another 2 transactions to force close their channel, because if the admin disappeared from the pool, he probably disappeared as a routing node too. (If he didn't stop routing transactions to LN, the users wouldn't need to force eject; they could just exit via LN.) So it's 4 transactions to exit altogether if the admin becomes malicious.
> Is there a way to make the malicious pool manager pay for the exit txs, e.g. by initially having some bond?
Hmm...I wonder how you can determine whether he's malicious or not. Maybe there could be a utxo that he timelocks, such that if he disappears, the timelock will run out, and at that point, users can do one thing with that utxo: pay for their exits. But I suppose if he is honest he will want that money back, so then to get it back I suppose he'd have to prove each user exited. I'm not sure how to do that, I'll have to think about it.