Good morning Antoine and Gleb,

I have not studied the proposal in close detail yet, but anyway, my main 
takeaway roughly is:

* The core of CoinPool is some kind of multiparticipant (N > 2) offchain update 
mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).
  * The output at each state of the update mechanism is some kind of splitting 
construction (which I have not studied in detail).
  * At each update of the state, all participants must sign off on the new 

It seems to me that it would be possible to use a [WabiSabi 
 during negotiation of a new state.

Now, WabiSabi is a client-server protocol.
As all participants in the CoinPool are needed in order to ratify each new 
state anyway, they can simply elect one of their number by drawing lots, to act 
as server for a particular state update.

Then the participants can operate as WabiSabi clients.
Each participant registers the outputs they currently own in the current state, 
getting credentials that sum up to the correct value.
Then, during the WabiSabi run, they can exchange credentials among the 
participants in order to perform value transfers inside the WabiSabi 
Then, at output registration, they register new outputs to put in the next 
state of the CoinPool.

In order to hide transfers from the elected WabiSabi server, participants can 
maintain two coins in every state, and move coins randomly across the two coins 
they own at each state update, in order to hide "real" transfers from the 
elected server.

Then, after output registration, the participants ratify the new state by 
signing off on the new state and revoking the previous state, using the update 

Of course, we should note that one desired feature for CoinPool in the original 
proposal is that a participant can exit, and the CoinPool would still remain 
valid, but only for the remaining participants.

This is arguably a mild privacy leak: every other participant now knows how 
much that particular participant took out from the CoinPool.
Indeed, from what I can understand, in order to properly set up the splitting 
transactions in the first place, at each state every participant needs to know 
how much each other participant actually owns in the CoinPool at that point in 

To hide how much each participant owns in the CoinPool from other participants, 
we would have to make unilateral closes expose all the current outputs, without 
trying to identify *which* participant exited the CoinPool, and thus preventing 
anyone else from figuring out exactly how much each *other* participant 
actually owns in the CoinPool on exit.
That way, output addresses can be to fresh pseudonyms of the participant, 
removing all linkages of participant to amount they own, and each participant 
can maintain multiple outputs per state for their own purposes and to mildly 
obscure exactly how much they own in total.

If we drop that feature (of being able to exit a participant without closing 
the *entire* CoinPool), of course, we need to mildly disincentivize a 
participant closing unilaterally for trivial reasons.
We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a 
unilateral close of the CoinPool to pay the onchain fees involved, so that it 
would have to be a good reason indeed to perform a unilateral close.

bitcoin-dev mailing list

Reply via email to