-
@ Super Testnet
2025-02-14 08:54:16
Phase 0. Waiting. Someone requests that the admin do a signing ceremony, such that each pool member will receive X sats of inbound capacity, where X is picked by the person who made the request ("the Requester") and must be below whatever amount the admin has in on-chain bitcoin. The admin's software automatically sets a 30 minute timer and gives the Requester a sharable link for people to join the ceremony. The Requester goes about finding additional people to join the ceremony, and gets to see how many people clicked the link and are waiting. At any point before the 30 minutes are up, the Requester may prompt the admin's software to start the ceremony, and the admin's software will do so as long as the number of people in the room is above a minimum established in their configuration file. If the 30 minutes expire without the Requester starting the ceremony, it aborts.
Phase 1. Admission fee. The admin's software identifies the number of people from phase 0 and calculates an admission fee, based on taking the amount of money to be provided to each as inbound capacity, plus a mining fee divided by however many users there are, and makes a bunch of lightning invoices for the resulting amount. The admin shows this to each person in the signing ceremony. They each have 1 minute to pay. If anyone does not pay, the remaining people are still in there ceremony. If, when the 1 minute is up, the number of people who paid is below a minimum threshold determined in the admin's configuration file, it aborts.
Phase 2. Signing. The admin tells everyone what utxo he will use to fund a multisig composed of every user's pubkey in an n-of-n. Each user independently constructs the funding transaction and all the transactions needed for each user to have a unilateral withdrawal into a channel. The number of signatures which each user must produce is (n**2) + n. Since the number of signatures required is variable, I don't have a static timer; instead, I require each user to send in a batch of data every 10 seconds, and right now I simply require that the number of signatures they've signed so far increases by at least 1. (I should probably raise that to something like 1000.) If anyone fails to send in valid signatures, they are ejected; the admin keeps their money; and he resends the signal to start signing, but only includes the pubkeys who did everything right. So everyone recreates the n-of-n multisig with the new set of pubkeys and starts resigning the funding tx and the unilateral withdrawal transactions. Repeat til everything is signed.
Phase 3. Broadcast. The admin broadcasts the funding transaction, funding the multisig. All of the money is in a state where any user, at any time, can unilaterally withdraw their share into a channel, i.e. a 2 of 2 multisig where the user has a key and the admin has a key. This channel has an initial state whereby all the money is on the admin's side of the channel, thus giving the user maximum inbound capacity. So, if anyone unilaterally withdraws at this stage, the admin will not lose any money; it's all on his side of every channel. The admin also sends every user the set of sigs they need to unilaterally withdraw, and each user validates these signatures before using the channel. Since they know the multisig script, and they validate all the signatures, there is no danger of them being tricked into not having a unilateral exit. But the admin *could* just not send them anything and keep their admission fee, which would constitute theft. So he has to be trusted not to do that, though I imagine admission fees will tend to be small, because that's the point.
Phase 4. Confirmation. Once the funding transaction confirms, it is safe for every user who has validated their withdrawal signatures to use their channel. Although it is not broadcasted yet, each user, as well as the admin, has the signatures necessary to put it on chain at any time. Consequently, they can treat the channel as if it is *already* on-chain. Meaning the user can use it to send and receive lightning payments as well as hedgehog payments, which are asynchronous. I have the admin charge 0 fees to route payments within the pool, which is easy because he has direct channels to each user. I also have him charge 0 fees to route payments to members of any *other* pool that he is the admin for. For payments to other (non-pooled) people, users can use lightning. For on-chain payments, they can use Boltz and competing submarine swap servers. (I will probably eventually have each admin run a submarine swap server too.)