Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3EE5DC07FF for ; Mon, 16 Nov 2020 01:32:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 2D7F386004 for ; Mon, 16 Nov 2020 01:32:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqk6gBE9Rqkl for ; Mon, 16 Nov 2020 01:32:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by fraxinus.osuosl.org (Postfix) with ESMTPS id E949E85FFC for ; Mon, 16 Nov 2020 01:32:17 +0000 (UTC) Date: Mon, 16 Nov 2020 01:32:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1605490334; bh=w3RXJdKAMZB3NFXI51VI3JeocWKb8dQ1kGRmIgKgwnI=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=fQN1Y7075SiscL0l32hxt20PNDhSgNYmgZi9ds++7t9nlTxDerh8WE4WccpHnL7vO jg0LJvNWjAOuVcL4gLWpQ3UtE+j4NtiOJjCbu9O4KnSI6AKuUJUIIe90YDkhOjNL8D oJ6tTtQ8AKJ218aNgab7zFVltCcUI/+z/bELUhaI= To: Sridhar G , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <1XMBkdX-KiAjYBAfntpqYxiBPaiJ-S-n11NNwroEMLBp6G7jV1EPAhF0aFaz_pz-PZ-7gxcMfCwg04ofcMqKzYe5rz826mHSJ2eZXsBxXYw=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 01:32:20 -0000 Good morning Sridhar, My understanding is that it is still possible to generate an m-of-n aggrega= ted pubkey, it "just" requires an interactive setup (i.e. all n signers hav= e to talk to each other and send data a few times to each other) and they h= ave to keep extra data around in order to "sign for" the n - m missing sign= ers. `andytoshi` and `pwuille` can probably teach you the details. Of course, if you want to trade off the interactive setup + data storage, f= or extra block space and a privacy loss, that seems a reasonable tradeoff t= o make. My understanding is that current plan is to implement a `OP_CHECKSIGADD`, w= here your script would be: <0> OP_CHECKSIGADD OP_CHECKSIGADD OP_CHECK= SIGADD OP_EQUAL However, `OP_CHECKSIGADD` would have individual signatures from the m parti= cipating signers. Your `OP_POOL`, as I understand it, would instead have a single m-of-m sign= ature. This adds another tradeoff: * `OP_CHECKSIGADD` takes up more block space, but each signer can give thei= r signature independently without having to enter a signing sessiong with o= ther 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 a= nd you can still use its signature when you have gotten the required m part= icipants. * `OP_POOL` takes less block space, but all participating signers have to b= e online simultaneously. I think the fact that `OP_POOL` requires all participating signers to be on= line simultaneously to generate a single signature sort of defeats the purp= ose, 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 prov= ide it. Interactive setup may not be so onerous if you are doing multiple interacti= ve signing sessions later anyway. So doing a verifiable secret sharing at interactive setup, to generate a si= ngle 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 interac= tive setup + storage of extra data. I guess the question is: just how big is the extra data in the m-of-n verif= iable 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 fo= llowing script: > > .. N M OP_POOL > > Bitcoin network will create a =E2=80=98pool=E2=80=99 with all the = =E2=80=98N=E2=80=99 public keys and note down the threshold M for this pool= . This UTXO would be referred as > > 2. Depositing money to pool > > Deposits can be made to a pool with with the following script > > 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. > > =C2=A0 OP_LOAD_POOL_AGG_PUB_KEY OP_CH= ECKSIG > > With provided by the person that redeems money= from a pool, where > > - is the aggregated signature > > - Is a bitmap representing whether the member of the poo= l at position 'i' of bitmap has signed or not(1 =3D signed, 0 - has not sig= ned) > > 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 fr= om the stack specifies the POOL_ID to load, which will load the public keys= from the pool. This opcode also checks if there are =E2=80=98M=E2=80=99 si= gners(as specified at the time of creation of the pool) and aggregates the = public keys that have signed based on SIGNERS_BITMAP using Schnorr aggregat= e 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 publi= c keys from the pool have signed the transaction. > > Having this scheme would enable- > > 1. Scalability of m-of-n multisig transactions - People can deposit mone= y to a pool(with 32 byte SIGNERS_BITMAP, we can allow for 256 possible sign= ers). > > 2. Trust minimized off-chain scalability solutions due to the use of a s= ufficiently 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 sch= eme that may expose public keys is a no-go in the Bitcoin network? > > Thanks! Looking for your feedback and thoughts on this. > > -Sridhar