diff options
| author | Ruben Somsen <rsomsen@gmail.com> | 2019-06-12 23:26:01 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-12 21:26:15 +0000 |
| commit | e46e08822e655c3106d7110f427f8ea8e5597deb (patch) | |
| tree | 90ecf6f696ba0546ec694e2d5a4f6ce7be11a156 | |
| parent | 62ea93e63170a79538900ea1bf1d36fe5fa3f9cc (diff) | |
| download | pi-bitcoindev-e46e08822e655c3106d7110f427f8ea8e5597deb.tar.gz pi-bitcoindev-e46e08822e655c3106d7110f427f8ea8e5597deb.zip | |
Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
| -rw-r--r-- | 3d/22f2ccd25073d244ede2ccc4c8d571fda6acb9 | 311 |
1 files changed, 311 insertions, 0 deletions
diff --git a/3d/22f2ccd25073d244ede2ccc4c8d571fda6acb9 b/3d/22f2ccd25073d244ede2ccc4c8d571fda6acb9 new file mode 100644 index 000000000..6cf721b35 --- /dev/null +++ b/3d/22f2ccd25073d244ede2ccc4c8d571fda6acb9 @@ -0,0 +1,311 @@ +Return-Path: <rsomsen@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id DA8A723A9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Jun 2019 21:26:15 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com + [209.85.128.53]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A2BC9E6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Jun 2019 21:26:14 +0000 (UTC) +Received: by mail-wm1-f53.google.com with SMTP id w9so5152934wmd.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Jun 2019 14:26:14 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc:content-transfer-encoding; + bh=Od02+T61OIyTblj7T8QMDXb2PRnLhvavMle+bQwq89o=; + b=fH0Pw+mBpAzqRRjWm3k3BMPrN+TqKxbmWJtwWzJlioBZNfU6BUkAL5UPH2vnrty1BQ + iACCrD4xls3cAqFUusFHwq9W4XjC/7FJFuCaJRnd4IKXQse93kzvzg24UHwyx0tUkgJ6 + cqEKouS4SPXMSqSEqQ+lHhvjY9YlNTOcogKOCRkp1Y214s73Edzyx8itqT7WYHWR8h+k + ATMtFuNhF3qZLk/FyUeR5u1FgMuUZU7/l/yKrwSYXdrryv20jt8iKarfoxwQkzN3mnPS + cJcDnSNaovUEP4ojHEKZsZW9wm3fka86kd4JhvXSOuKyoN5T4O53Mcl5TEcA5QuH1G2v + xyTA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc:content-transfer-encoding; + bh=Od02+T61OIyTblj7T8QMDXb2PRnLhvavMle+bQwq89o=; + b=lZuN+uQVzN9QYstKbHXAYygh1B0KynKvkEStzm6JJAGSxl7XOKuKXRHj5Ec76numXh + qX93iXyfm2ku41DMHZ8xY2RiCNkUEfkFAYOrXI06HLK7O/XlSdndVT2b/LC3FScyKGWP + QEF0Mkim8SmKv0I6i4JWZjWyDIK6gPiit4xacfLK6TVcpc7NzxRDazxDSjCILCt8e6Kz + 6C+ifY5ovRtTpOo4m1rxaH4F0/FLlL1Y+MOMcctMEQWi1lrP0+h6o7YkiGS8DwyV3pk+ + Jw5QhpA4R9cyFV5O5se2iEs9pShYT7oEfl05WAmZIhJGwsrzgAXW0hXYEE+20v7e4dZd + 3aSg== +X-Gm-Message-State: APjAAAUFlO/rrxXnhbt0WYqb4WPvn3SLf9NyylYkUyWbU9AkEYUZPJL+ + gaVRxOjZEA2Nk7e4SxwsxhaL4MAhvN1MrhYG7sGCoFsR0kw= +X-Google-Smtp-Source: APXvYqz57MIDgjBxEieJjJTtc+0krhvGW0LocF7z3BRoHCjSfS5cg34QIDh3y9euMTQ8vy7m324+b8dGowhY/gElq48= +X-Received: by 2002:a1c:2907:: with SMTP id p7mr813606wmp.100.1560374773287; + Wed, 12 Jun 2019 14:26:13 -0700 (PDT) +MIME-Version: 1.0 +References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com> + <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com> + <CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@mail.gmail.com> + <L118b6Auac7OxL9DmyvXmFldcnSvb1xU807qtsPt6fGY0-fpg55U5VmEdAgC1T87r274UuqZ-iS0yDNBhZfvhsEW3ZHhdl1eb5Cg4I04ckE=@protonmail.com> +In-Reply-To: <L118b6Auac7OxL9DmyvXmFldcnSvb1xU807qtsPt6fGY0-fpg55U5VmEdAgC1T87r274UuqZ-iS0yDNBhZfvhsEW3ZHhdl1eb5Cg4I04ckE=@protonmail.com> +From: Ruben Somsen <rsomsen@gmail.com> +Date: Wed, 12 Jun 2019 23:26:01 +0200 +Message-ID: <CAPv7Tja9BCtzh=yjOX0nCK8E2K2JRpp7huCw_AwBXVM6J3+VfQ@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + RCVD_IN_DNSWL_NONE 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: Wed, 12 Jun 2019 21:30:30 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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: Wed, 12 Jun 2019 21:26:16 -0000 + +Hi ZmnSCPxj, + + +Thanks for the reply. Sorry to keep you waiting, Coredev and Breaking +Bitcoin have been keeping me busy. + +Transcript from Coredev (thanks Bryan): +http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statecha= +ins/ + +Blind Statechains at Breaking Bitcoin: +https://www.youtube.com/watch?v=3DDqhxPWsJFZE&t=3D4h59m4s + + +>an early draft + +I meant an early draft of Statechains, sorry if that was confusing. +But yes, it's essentially no different from channel factories without +eltoo. + + +>If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems = +this transitory/common key can be used for the chaperone. + +That is a good point. One thing I have not yet fully analysed are the +privacy considerations. Perhaps we don't want to reveal X on-chain. + + +>This would be nearer to my own Smart Contracts Unchained + +Adding scripting is not my preferred approach. The beauty of the +system is that the server doesn't evaluate any scripts whatsoever. + +That being said, Smart Contracts Unchained (SCU) can be inserted quite +elegantly as a separate smart contracting layer. + +The observation is that anything that can be done with a UTXO +on-chain, can also be done off-chain via Statechains, including SCU. + +If SCU is a single (N-of-N or (1-of-N + escrow)) key, you can simply +use this as the userKey (as well as inside the off-chain eltoo tx). + +It's pretty interesting how smart contracting can be added like this. +Cool stuff, ZmnSCPxj. I'll definitely be thinking about this more. + + +Cheers, +Ruben + +On Thu, Jun 6, 2019 at 8:32 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote: +> +> 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 = +Message =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 <rsomsen@gmail.com> wrote= +: +> +> > Hi ZmnSCPxj, +> > +> > Thank you for your comments. +> > +> > > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is= + not strictly required. We can still make use of the Decker-Wattenhofer con= +struction 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 chan= +nel factory. +> Factory operations would still require the signatures of all participants= +, but once a participant has released its signature, it cannot be sure whet= +her its channels should be rooted on the previous factory state or the next= + (i.e. the [Stale Factory problem](https://lists.linuxfoundation.org/piperm= +ail/lightning-dev/2019-April/001974.html) ). +> This is fixable if we use `SIGHASH_ANYPREVOUT` on channel update transact= +ions. +> Alternately without that flag we can run channels rooted on both the prev= +ious 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 eno= +ugh" swaps are in position to be stolen, trading off earned reputation for = +cold-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 Smar= +t Contracts Unchained. +> +> If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems= + this 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 regis= +ters it to userPubkey +> > // Extend existing chain +> > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =3D>= + returns blindSignature, registers the serverPubkey to nextUserPubkey +> +> Can be generalized, such that instead of pubKeys and their signatures, we= + have validation programs and their witnesses. +> +> For example, instead of userPubkey and nextUserPubkey we have a userScrip= +t and nextUserScript, with userSignature replaced by a userWitness. +> +> This would be nearer to my own Smart Contracts Unchained, though without = +committing 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= + signatures +> > > > [2] to make the entity unaware of what it's signing. I now think th= +is +> > > > is the more interesting approach. The functionality can be describe= +d +> > > > 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 nextUserPubke= +y +> > > > 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 t= +o +> > > > 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 j= +ust +> > > > Bitcoin, but let's walk through the primary envisioned use case whe= +re +> > > > we transfer the ownership of a Bitcoin UTXO off-chain. Note that th= +e +> > > > 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 serverPubk= +ey A +> > > > +> > > > - B then generates transitory key X, and creates a single MuSig k= +ey AX +> > > > (key X is called =E2=80=9Ctransitory=E2=80=9D because its priva= +te 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-chain) +> > > > +> > > +> > > 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-`nSequen= +ce` update systems. +> > > Number of maximum updates is limited by the starting `nSequence`, how= +ever 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 = +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. actua= +l Lightning channels (your given CoinSwap protocol is "only" two updates, f= +or instance) this is usually a good tradeoff, +> > > It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` i= +s too controversial to get into Bitcoin, provided Schnorr (definitely uncon= +troversial) does get into Bitcoin. +> > > +> > > > A and B can collude to take the money from C, but since all ins= +tances +> > > > of userSignature and blindSignature are published openly, cheat= +ing 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 eno= +ugh" swaps are in position to be stolen, trading off earned reputation for = +cold-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.= + This +> > > > means security can be on par with federated sidechains [5], and= + is +> > > > similar to how ZmnSCPxj replaced the escrow key with a federati= +on in +> > > > =E2=80=9CSmart Contracts Unchained=E2=80=9D [6]. +> > > > +> > > +> > > This makes me happy. +> > > Regards, +> > > ZmnSCPxj +> +> + |