Skip to content

Instantly share code, notes, and snippets.

@harding

harding/joinpools.md

Created Jan 28, 2020
Embed
What would you like to do?
A description of joinpools elided from Optech Newsletter #48

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:

  1. 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.

  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.