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.
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.
Out of curiosity, if the key path spend in the construction above is run by a federation (FROST or MuSig2) and we can totally order the requests to update participants balances, then can we do away with the need for covenants in Script?
I am exploring the possibility of using a simple Joinpool like construction to manage miner payouts in a decentralised mining pool.