diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-06-06 00:09:28 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-06 00:09:34 +0000 |
| commit | d799eca43e32dd6978bf1e7680b17f0118b15738 (patch) | |
| tree | 6cd8093198a0f8492bb3651346f0b5ab315af6ad | |
| parent | ca1bd9ca6bdf98a8826bb6e8a77487de9690b140 (diff) | |
| download | pi-bitcoindev-d799eca43e32dd6978bf1e7680b17f0118b15738.tar.gz pi-bitcoindev-d799eca43e32dd6978bf1e7680b17f0118b15738.zip | |
Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
| -rw-r--r-- | ae/fc0e43d76b511d6c696cc2e4f77c26719d93af | 146 |
1 files changed, 146 insertions, 0 deletions
diff --git a/ae/fc0e43d76b511d6c696cc2e4f77c26719d93af b/ae/fc0e43d76b511d6c696cc2e4f77c26719d93af new file mode 100644 index 000000000..7ac13f9d7 --- /dev/null +++ b/ae/fc0e43d76b511d6c696cc2e4f77c26719d93af @@ -0,0 +1,146 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id BAA18CAE + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Jun 2019 00:09:34 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch + [185.70.40.135]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BBCDA711 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Jun 2019 00:09:33 +0000 (UTC) +Date: Thu, 06 Jun 2019 00:09:28 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1559779771; + bh=aRDeJ4pIktwFveeKhMTnkDw5WK39Q3UokC5gY9E5aos=; + h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: + From; + b=v4sbaeGkTbpoIR12naiVxduhSXjRZch7iMNMTKpg2Q06DIbgRaXOvn1qfgqNDKRq3 + JFnBL7hzlCMEIZUEiPmqiyK+2lMZnIEwUDsEcF3aGHP76FDBbIqS9k/kN/bt2SyrWp + wja9CsBqup9pqjsh2mX5pZkxYDNSsZY+458n0Zlc= +To: Ruben Somsen <rsomsen@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com> +In-Reply-To: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com> +References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Thu, 06 Jun 2019 06:54:47 +0000 +Subject: Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic + blind signing server +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +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: Thu, 06 Jun 2019 00:09:34 -0000 + +Good morning Ruben, + +> At +> Scaling Bitcoin =E2=80=9818 [1] I briefly mentioned utilizing blind signa= +tures +> [2] to make the entity unaware of what it's signing. I now think this +> is the more interesting approach. The functionality can be described +> fairly elegantly as follows. + +I agree. +I had no interest in Statechains at all before, but now that you have blind= + signing servers, this is significantly more interesting. + + +> +> Blind signing server with two functions users can call: +> +> // Start new signature chain +> (1) requestNewKey(userPubkey) =3D> returns a new serverPubkey and +> registers it to userPubkey +> +> // Extend existing chain +> (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =3D> +> returns blindSignature, registers the serverPubkey to nextUserPubkey +> +> The resulting output is a public ECC chain (one blindSignature per +> user, one chain per serverPubkey) of blindly signed messages, +> requested by users (1, 2, 3, etc.): +> +> userSignature1(blindedMessage1, userPubkey2) =3D> blindSignature1 +> userSignature2(blindedMessage2, userPubkey3) =3D> blindSignature2 +> etc. +> +> Assuming the server is honest (more on this below), we can use it to +> transfer over the signing rights of a private key without actually +> changing the key itself. +> +> The functionality is general and therefore suitable for more than just +> Bitcoin, but let's walk through the primary envisioned use case where +> we transfer the ownership of a Bitcoin UTXO off-chain. Note that the +> server is kept completely unaware that it's handling a BTC +> transaction, since it's signing blindly: +> +> - B uses function (1) with userPubkey =3D B to request serverPubkey A +> - B then generates transitory key X, and creates a single MuSig key AX +> (key X is called =E2=80=9Ctransitory=E2=80=9D because its private key= + will later be passed on) +> +> - B prepares tx1: 1BTC to AX (he doesn't send it yet) +> - B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-c= +hain) + +Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not *= +strictly* required. +We can still make use of the Decker-Wattenhofer construction instead. + +The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` up= +date systems. +Number of maximum updates is limited by the starting `nSequence`, however i= +f we put an update system inside an update system, we can "reset" the `nSeq= +uence` of the inner update system by updating the outer update system. +We can chain this concept further and add more update systems nested inside= + update systems to gain more leverage from the maximum relative wait time. + +As we expect fewer updates are needed for statechains than e.g. actual Ligh= +tning channels (your given CoinSwap protocol is "only" two updates, for ins= +tance) this is usually a good tradeoff, + +It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is too = +controversial to get into Bitcoin, provided Schnorr (definitely uncontrover= +sial) does get into Bitcoin. + +> A and B can collude to take the money from C, but since all instances +> of userSignature and blindSignature are published openly, cheating is +> publicly detectable (e.g. the server signed two messages from B +> instead of one). + +This still admits the possibility of an exit scam once a few "big enough" s= +waps are in position to be stolen, trading off earned reputation for cold-s= +tored cash. + +> +> Trust can be distributed by turning the server into a multisig +> threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This +> means security can be on par with federated sidechains [5], and is +> similar to how ZmnSCPxj replaced the escrow key with a federation in +> =E2=80=9CSmart Contracts Unchained=E2=80=9D [6]. + +This makes me happy. + +Regards, +ZmnSCPxj + |