From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BAA18CAE for ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com> In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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