[bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures

[bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures

[Sridhar G]

[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 15944 bytes --]

Re: [bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures

[ZmnSCPxj]

Good morning Sridhar,

My understanding is that it is still possible to generate an m-of-n aggregated pubkey, it "just" requires an interactive setup (i.e. all n signers have to talk to each other and send data a few times to each other) and they have to keep extra data around in order to "sign for" the n - m missing signers.
`andytoshi` and `pwuille` can probably teach you the details.

Of course, if you want to trade off the interactive setup + data storage, for extra block space and a privacy loss, that seems a reasonable tradeoff to make.

My understanding is that current plan is to implement a `OP_CHECKSIGADD`, where your script would be:

   <0> <pubkey1> OP_CHECKSIGADD <pubkey2> OP_CHECKSIGADD <pubkey3> OP_CHECKSIGADD <m> OP_EQUAL

However, `OP_CHECKSIGADD` would have individual signatures from the m participating signers.
Your `OP_POOL`, as I understand it, would instead have a single m-of-m signature.

This adds another tradeoff:

* `OP_CHECKSIGADD` takes up more block space, but each signer can give their signature independently without having to enter a signing sessiong with other participating signers.
  * For example, this can reduce the number of communication rounds and the latency.
  * A participating signer can emit its own signature and then go offline and you can still use its signature when you have gotten the required m participants.
* `OP_POOL` takes less block space, but all participating signers have to be online simultaneously.

I think the fact that `OP_POOL` requires all participating signers to be online simultaneously to generate a single signature sort of defeats the purpose, as (by my naive understanding, which could be grossly wrong) in the m-of-n key setup, the extra data needed would be stored by all participants, so even if one participant loses this data any of the others can still provide it.
Interactive setup may not be so onerous if you are doing multiple interactive signing sessions later anyway.
So doing a verifiable secret sharing at interactive setup, to generate a single pubkey that is just used directly as the pubkey of the UTXO, would end up being smaller and more private anyway, and would "just" require interactive setup + storage of extra data.

I guess the question is: just how big is the extra data in the m-of-n verifiable secret sharing?

Regards,
ZmnSCPxj


> 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