harding/joinpools.md

## joinpools.md

      
    Raw
  

              joinpools.md
            
          
    Bitcoin Optech Newsletter #48 described Jeremy Rubin's
OP_CHECKOUTPUTSHASHVERY (COSHV) soft fork proposal.  Originally, that
content included descriptions of several advanced uses of COSHV, but
that material was removed shortly due to publication because of concerns
that it was not adequately reviewed and so may have contained errors.
Optech initially planned to obtain more reviews and publish the extra
content the following week but, by then, the COSHV proposal was
withdrawn in favor of a modified proposal with a new name, so the extra
content went into limbo.  The following section comes from that lost
content; it has not been updated since the original COSHV proposal
(which has matured into the OP_CHECKTEMPLATEVERIFY (CTV) proposal) and
it has not received the additional review the Optech publishers thought
it should receive before publication.
Rolling coinjoin ("joinpool")

Gregory Maxwell discussed some of his first
impressions of the COSHV proposal to the logged IRC channel #bitcoin-wizards.
Among them was a description of how the above multi-transaction tree
could be used as part of a coinjoin construction to manage
balances offline.
The coinjoin would start with a set of users creating a setup
transaction.  This would be similar to the examples above but it would
require interaction because, before each participant could sign the
setup transaction, they'd need to verify that the outputs tree paid them
the correct amounts.  After the setup transaction was broadcast, they
could then individually withdraw their balances the same as before, with
the same possible advantages of reduced fees if they were patient.
However, a more powerful feature would be to use Taproot key-path spends
to use the pool of funds to create transactions that
look like they were created by a single ordinary user.  This is possible
because a key-path spend using signature aggregation allows all members
of the pool, when they are in agreement, to spend their money however
they'd like.  For example:


If Bob wanted to spend part of his money to someone else (either
someone in the pool or anyone outside of it), every member of the
pool could sign that spend and return the change to the same basic
output tree they already had, but with Bob's balance decreased
accordingly.


If Fran wanted to join the pool by contributing some funds, Fran and
every current member of the pool could sign a transaction spending
their current UTXO along with Fran's UTXO or UTXOs to a new output tree
that included Fran's withdrawal address and balance.  This same
method could be used if any member of the pool wanted to pay into the
pool in order to increase their balance there.


In this way, many transactions made by the pool would be key-path spends
that look identical to single-user, single-sig transactions and so would
not directly reveal that they belonged to the pool.  Even if it was
known that a joinpool controlled those funds, third parties would not
know who within the group had spent or received money.  Exit
transactions might reveal that someone was leaving a joinpool but, if
the group was involved in enough spending and receiving, it could be
very difficult for a third party to use the transaction history graph to
determine which member of the pool was exiting.