diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-11-16 01:32:11 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-11-16 01:32:20 +0000 |
| commit | 908e9567d5166e69b3e7a295a0e6e3bef90359dd (patch) | |
| tree | 26f94c89dcc9c1e03233a72140956e6416a7df4f | |
| parent | 2d10fcc5e62d4b2f75017c7a9ad184a227f2ce1b (diff) | |
| download | pi-bitcoindev-908e9567d5166e69b3e7a295a0e6e3bef90359dd.tar.gz pi-bitcoindev-908e9567d5166e69b3e7a295a0e6e3bef90359dd.zip | |
Re: [bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures
| -rw-r--r-- | 43/7d67ec8dc9ed5b608e6347276c32665ab12aaf | 202 |
1 files changed, 202 insertions, 0 deletions
diff --git a/43/7d67ec8dc9ed5b608e6347276c32665ab12aaf b/43/7d67ec8dc9ed5b608e6347276c32665ab12aaf new file mode 100644 index 000000000..3301309aa --- /dev/null +++ b/43/7d67ec8dc9ed5b608e6347276c32665ab12aaf @@ -0,0 +1,202 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 3EE5DC07FF + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <sridhar87@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <1XMBkdX-KiAjYBAfntpqYxiBPaiJ-S-n11NNwroEMLBp6G7jV1EPAhF0aFaz_pz-PZ-7gxcMfCwg04ofcMqKzYe5rz826mHSJ2eZXsBxXYw=@protonmail.com> +In-Reply-To: <CAF8yEM_gur=r2WvQ=y3bE53cfds=gQT3se-GAspHvMQzUnW-9Q@mail.gmail.com> +References: <CAF8yEM_gur=r2WvQ=y3bE53cfds=gQT3se-GAspHvMQzUnW-9Q@mail.gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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> <pubkey1> OP_CHECKSIGADD <pubkey2> OP_CHECKSIGADD <pubkey3> OP_CHECK= +SIGADD <m> 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: +> +> <pub_key_1> <pub_key_2> <pub_key_3> .. <pub_key_N> 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 <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>=C2=A0 OP_LOAD_POOL_AGG_PUB_KEY OP_CH= +ECKSIG +> +> 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 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 + + + |