From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8327BC07FF for ; Sun, 15 Nov 2020 22:18:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 76B44869CB for ; Sun, 15 Nov 2020 22:18:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNbpoh4BFb69 for ; Sun, 15 Nov 2020 22:18:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by whitealder.osuosl.org (Postfix) with ESMTPS id 31929869CA for ; Sun, 15 Nov 2020 22:18:30 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id t9so16802172edq.8 for ; Sun, 15 Nov 2020 14:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MA60qgdwHV7UBw2Ni84alQCYNCZJu9O11BQ45ukFtyI=; b=KN+wMJ3EvFkITxShovytmDItaieHBVxoPdlhRrvZAzi8ndBwkOiWRhSJyUAGFpm62b YnYxk1Lf23o355IMK27F7dHygfyNECXmv2BdZRfAWk5LmA9+Hx7OYIj2EQ6uWKm0bZUU hIX5Rezq3g42dytcOK2kqj9n7ecSSCNlu9r6NueGZ1RH8KyMKtLjVBvm1GkqIm3l9nvq 5C7iw6wlVKskT+nBkoG+rduRV5dlsoLJz3SvZrpiPdpx+Va/YcN77GjDO10FloZ9VZIh uwmQ4pNZakbhfUj7EKhaMDs1dWVrZRszc14nrGHC7kn5mTAzo2KzwnSYUqIHDCNqfjIB Nw2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MA60qgdwHV7UBw2Ni84alQCYNCZJu9O11BQ45ukFtyI=; b=qdQCk2/xOInQgzTKZGOXp8yB98tj8lAoWxY0R3PrFc4f4vBLIQpPlxhRGUKmpFqswo OsL9ukY1Buj1vJkma2u+Bj0SPOLRT3lyzYTvF3hB8JCYMzUqw5rVTNWgMV+cokfaT0qa gVyogxZn9m5L1vSP4Rh7OGft9LSTpUpVSV2wOs63nyY7sus8VFASS9czLGFv70/YN8Ll HoCaVI8bIHxjySraUVJ5GWvjjC/8JNWRyFlHL6hc/l49kQ90MmyJTUlvVYpIcHVysG2o W3k0S1g+A1aiGewx6RV8gH1Lw5lM9l7LkcQWsaGMGoiZ0BigI6f7hnd3RMEX7apb4U2F r2Qw== X-Gm-Message-State: AOAM531elWBKFgOGkmtB0JzEb391BqqAWfbIyapmauQU9E5WabZTyjFJ jm1w0RE5qjL0RqUUrn5VKdiKkTp4rFX6R0ZathO+GrWpbe9kiMNU X-Google-Smtp-Source: ABdhPJxvhFBEfZOA2kfnZUeAPbrCyotkyHvApGSGstpY8ykoXzmveUovv4ZejLoDpY8Lixz23eYLIyhu479hh0C/lqo= X-Received: by 2002:a50:9fe6:: with SMTP id c93mr12770246edf.30.1605478708300; Sun, 15 Nov 2020 14:18:28 -0800 (PST) MIME-Version: 1.0 From: Sridhar G Date: Sun, 15 Nov 2020 23:18:17 +0100 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000001a50bd05b42ca4f5" X-Mailman-Approved-At: Sun, 15 Nov 2020 23:03:55 +0000 Subject: [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: Sun, 15 Nov 2020 22:18:31 -0000 --0000000000001a50bd05b42ca4f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: .. N M OP_POOL Bitcoin network will create a =E2=80=98pool=E2=80=99 with all the =E2=80=98= N=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. * * OP_LOAD_POOL_AGG_PUB_KEY OP_CHECKSIG 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 pool at position 'i' of bitmap has signed or not(1 =3D signed, 0 - has not signe= d) 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 =E2=80=98M= =E2=80=99 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 --0000000000001a50bd05b42ca4f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi everyo= ne,


N-of-n m= ultisig transaction using Schnorr aggregate signature is trivial and is sim= ilar to the current P2PKH. I would like to propose a model for m-of-n multi= sig 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:


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap"><pub_key_1> <pub_k= ey_2> <pub_key_3> .. <pub_key_N> N M OP_POOL


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap">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. Depositin= g money to pool

= Deposits can be made to a pool with <POOL_ID> with the following scri= pt


<POOL_ID> OP_LOAD_POOL_AGG_PUB_KEY OP_CHECKSIG


3. Redeeming money from pool

=

= Redeem script would contain the aggr= egated signature from all signers and the bitmap of signers.


=

= <AGG_SIG> <SIG= NERS_BITMAP> <POOL_ID>=C2=A0 OP_LOAD_POOL_AGG_PUB_KEY=C2=A0 OP_CHECKSIG


Wit= h <AGG_SIG> <SIGNERS_BITMAP> provided by the person that redeem= s money from a pool, where

<AGG_SIG= > - is the aggregated signature

<SIGNERS_BITMAP> - Is a bitmap repre= senting whether the member of the pool at position 'i' of bitmap ha= s signed or not(1 =3D 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 thr= ee things

      3. loads the pool (POOL_ID)

    1. checks if th= ere are atleast 'm' signers (based on SIGNERS_BITMAP)

    2. aggregates the public key of the signers. (based on SIGNERS_= BITMAP)

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The opcode uses the top two elements from = the stack- the first element from the stack specifies the POOL_ID to load, = which will l= oad 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 public keys fro= m the pool have signed the transaction.


Having this scheme would enable-

  • 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).

  • Trust minimized off-chain scalability solutions due to th= e use of a sufficiently large pool of signers. Most existing pools might al= low for only a few signers as having many signers would mean higher transac= tion cost.


    • Downsides:

    1. We need to have the public keys of the members of the po= ol 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?<= /span>


    <= p style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Thanks! Looking for your feedback and= thoughts on this.

    -Sridhar<= /span>


    --0000000000001a50bd05b42ca4f5--