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 972B02F for ; Thu, 6 Jun 2019 06:32:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64E6234F for ; Thu, 6 Jun 2019 06:32:12 +0000 (UTC) Date: Thu, 06 Jun 2019 06:31:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1559802711; bh=EFVEpMyZGMvSOG3+Hih/Ph+AQEpob3wcpiMOWSlO49c=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=AMhp/SUuBF2f7JpbXYNdmyCz9HC5hjz+lRnaM9+TzRiFKWGY86f3dI/iYSuGyl3h9 hoWYEpTygRvBsozfjYmhKqRczPkyFzNERnSSlOEL2JiJE0zytPBnSwuwI0MniWniie n571SaTGzmFc1sv7b9HdzIsF8jnZm3fxcbYwf54Q= To: Ruben Somsen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.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 Cc: Bitcoin Protocol Discussion 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 06:32:13 -0000 Good morning Ruben, Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, June 6, 2019 1:20 PM, Ruben Somsen wrote: > Hi ZmnSCPxj, > > Thank you for your comments. > > > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is n= ot strictly required. We can still make use of the Decker-Wattenhofer const= ruction instead. > > Yes, an early draft (from before the eltoo paper) was using that > construction, but it seemed quite unwieldy. Timelocks have to be long, > nesting adds more transactions, channels expire faster with more use, > and tx fee handling is more complex. But you make a good point that if > SIGHASH_ANYPREVOUT turns out to be too controversial (or for > supporting older altcoins), this would be a potential fallback. The lack of `SIGHASH_ANYPREVOUT` does make it difficult to operate a channe= l factory. Factory operations would still require the signatures of all participants, = but once a participant has released its signature, it cannot be sure whethe= r its channels should be rooted on the previous factory state or the next (= i.e. the [Stale Factory problem](https://lists.linuxfoundation.org/pipermai= l/lightning-dev/2019-April/001974.html) ). This is fixable if we use `SIGHASH_ANYPREVOUT` on channel update transactio= ns. Alternately without that flag we can run channels rooted on both the previo= us and next factory states, which actually is similar to what we need to do= for splice-in (so we could reuse that code, possibly). > > > This still admits the possibility of an exit scam once a few "big enoug= h" swaps are in position to be stolen, trading off earned reputation for co= ld-stored cash. > > That is correct. The worst case for security still comes down to > having to trust the federation, but the transitory key, as well as the > blind signature scheme, does add an interesting layer of separation > that makes it essentially "non-custodial". The article I linked has > more on this. Of note is that this is roughly the same as the common key in my own Smart = Contracts Unchained. If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems t= his transitory/common key can be used for the chaperone. Going further on Smart Contracts Unchained, I observe that the below: > // Start new signature chain > (1) requestNewKey(userPubkey) =3D> returns a new serverPubkey and registe= rs it to userPubkey > // Extend existing chain > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =3D> r= eturns blindSignature, registers the serverPubkey to nextUserPubkey Can be generalized, such that instead of pubKeys and their signatures, we h= ave validation programs and their witnesses. For example, instead of userPubkey and nextUserPubkey we have a userScript = and nextUserScript, with userSignature replaced by a userWitness. This would be nearer to my own Smart Contracts Unchained, though without co= mmitting to the smart contract onchain, only offchain in the server. > > Cheers, > Ruben > > On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj ZmnSCPxj@protonmail.com wrote: > > > Good morning Ruben, > > > > > At > > > Scaling Bitcoin =E2=80=9818 [1] I briefly mentioned utilizing blind s= ignatures > > > [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 b= lind 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 jus= t > > > 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 (o= ff-chain) > > > > > > > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is n= ot strictly required. > > We can still make use of the Decker-Wattenhofer construction instead. > > The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence= ` update systems. > > Number of maximum updates is limited by the starting `nSequence`, howev= er if we put an update system inside an update system, we can "reset" the `= nSequence` of the inner update system by updating the outer update system. > > We can chain this concept further and add more update systems nested in= side update systems to gain more leverage from the maximum relative wait ti= me. > > As we expect fewer updates are needed for statechains than e.g. actual = Lightning channels (your given CoinSwap protocol is "only" two updates, for= instance) 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 uncontr= oversial) does get into Bitcoin. > > > > > A and B can collude to take the money from C, but since all insta= nces > > > of userSignature and blindSignature are published openly, cheatin= g 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 enoug= h" swaps are in position to be stolen, trading off earned reputation for co= ld-stored cash. > > > > > Trust can be distributed by turning the server into a multisig > > > threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. T= his > > > means security can be on par with federated sidechains [5], and i= s > > > 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