Hi everyone,

N-of-n multisig transaction using Schnorr aggregate signature is trivial and is similar to the current P2PKH. I would like to propose a model for m-of-n multisig transactions using Schnorr aggregate signatures and use this to enable CoinPools for off-chain scalability.

1. Creating the pool

A transaction is made on the bitcoin network with an output having the following script:

<pub_key_1> <pub_key_2> <pub_key_3> .. <pub_key_N> N M OP_POOL

Bitcoin network will create a ‘pool’ with all the ‘N’ public keys and note down the threshold M for this pool. This UTXO would be referred as <POOL_ID>

2. Depositing money to pool

Deposits can be made to a pool with <POOL_ID> with the following script

<POOL_ID> OP_LOAD_POOL_AGG_PUB_KEY OP_CHECKSIG

3. Redeeming money from pool

Redeem script would contain the aggregated signature from all signers and the bitmap of signers.

<AGG_SIG> <SIGNERS_BITMAP> <POOL_ID>  OP_LOAD_POOL_AGG_PUB_KEY  OP_CHECKSIG

With <AGG_SIG> <SIGNERS_BITMAP> provided by the person that redeems money from a pool, where

<AGG_SIG> - is the aggregated signature

<SIGNERS_BITMAP> - Is a bitmap representing whether the member of the pool at position 'i' of bitmap has signed or not(1 = signed, 0 - has not signed)

So we will be introducing two new opcodes:

1. OP_POOL - this will be used to create a new coin pool.

2. OP_LOAD_POOL_AGG_PUB_KEY - This opcode does three things

1. loads the pool (POOL_ID)

2. checks if there are atleast 'm' signers (based on SIGNERS_BITMAP)

3. aggregates the public key of the signers. (based on SIGNERS_BITMAP)

      The opcode uses the top two elements from the stack- the first element from the stack specifies the POOL_ID to load, which will load the public keys from the pool. This opcode also checks if there are ‘M’ signers(as specified at the time of creation of the pool) and aggregates the public keys that have signed based on SIGNERS_BITMAP using Schnorr aggregate signature scheme and puts back this aggregated public key onto the stack.

SIGNERS_BITMAP is a 32 byte value, and represents a bitmap of which public keys from the pool have signed the transaction.

Having this scheme would enable-

1. Scalability of m-of-n multisig transactions - People can deposit money to a pool(with 32 byte SIGNERS_BITMAP, we can allow for 256 possible signers).

2. Trust minimized off-chain scalability solutions due to the use of a sufficiently large pool of signers. Most existing pools might allow for only a few signers as having many signers would mean higher transaction cost.

Downsides:

1. We need to have the public keys of the members of the pool exposed.

Despite the downsides of exposing public keys, do you think this would be a viable scheme for enabling CoinPool for the Bitcoin network? Or, any scheme that may expose public keys is a no-go in the Bitcoin network?

Thanks! Looking for your feedback and thoughts on this.

-Sridhar