Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2B048AF5 for ; Thu, 6 Jun 2019 05:20:45 +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 3C378A8 for ; Thu, 6 Jun 2019 05:20:44 +0000 (UTC) Received: by mail-wm1-f53.google.com with SMTP id 22so969037wmg.2 for ; Wed, 05 Jun 2019 22:20:44 -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=xchAeficPWDRKEA3+lteY6P9BrPJ6RVvpjf+qsAXB3Q=; b=Enliw3EajRqnhaSh8haxAX8oXFsOBjNxZRUz3FkEIh52F9/7akVkvQ3h+p2OTQESl1 9hI/b3DQO1TtqdtRgOpzZ6WOeyG9CAZFgMtfSZl/h/RkRXCl7edqjfA+Q+2ZUNcTpvoS m6cM9NCo4P4O65lVYW2gAfqXG7bKd0hT8yZFtHz9Yizgl60j5qxUzwYdP5i/dbYPCauN lfGNblgeMLBRFxy2NjnlE2o2enG/CJ4zCPDiOH74T9Fyy3jDHBT/kpXhcoyFmu4pb76B PD7y/q4N/5k4vmmpjsUgXgLxS83yLBKxKCRAvAxazb83MlCS5oooD4pyITYoRB0HyZKC wdFQ== 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=xchAeficPWDRKEA3+lteY6P9BrPJ6RVvpjf+qsAXB3Q=; b=HWbKwuEnq5zAYvHGeXjn1kVXpdrm7MygRyqUzO2ZneQ3LmMq+WNAS/HaIYzyUcJfh7 Yf9C+RukcBNTBFtuV+tGck4fn8j7TQCy3ZR/GdaiVkDuls5e2YYaKn6oRqJOGRKfmx8b 1VMsHCd/DNH0tHmAECH2xXKA1FgYkCeHOhEueV49wvf3HU0cVhOwgnb5Q22E2yY/O+zP W9CZEilNd3CAxq1qhDO8Z7l0jhcnCUBz57PDj5yvqLBg+fGgQgJO5j38EaY36bkYj4w+ KGelRPzwO8zDtmSRe/DtNjpCKgUztkp6uS1X1Jfa1mkMtdsdE2RElRa2QIvb/L/6riFY aBNg== X-Gm-Message-State: APjAAAVmIHcankJqKDzEPfMbQTEoQRAdNDziD6ZNDfKL6GLTVhgSEfR8 LxlGXG3P8G1ell0wADepchNcRSnNWSDC4OaaZCc= X-Google-Smtp-Source: APXvYqxYv+sQ1EZnrm7dEhF7mp6M4GH9DzGBSMLwO87vjzG2ESTiuiorRZXU6zmhsxt6QxIwDuZtjH8kb+OQ/tGtOM4= X-Received: by 2002:a7b:c444:: with SMTP id l4mr12976072wmi.15.1559798442787; Wed, 05 Jun 2019 22:20:42 -0700 (PDT) MIME-Version: 1.0 References: <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com> In-Reply-To: <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com> From: Ruben Somsen Date: Thu, 6 Jun 2019 07:20:31 +0200 Message-ID: To: ZmnSCPxj 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: 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 05:20:45 -0000 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 constr= uction 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. >This still admits the possibility of an exit scam once a few "big enough" = 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. Cheers, Ruben On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj wrote: > > Good morning Ruben, > > > At > > Scaling Bitcoin =E2=80=9818 [1] I briefly mentioned utilizing blind sig= natures > > [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 bli= nd 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 A= X > > (key X is called =E2=80=9Ctransitory=E2=80=9D because its private k= ey 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-`nSequence` = update systems. > Number of maximum updates is limited by the starting `nSequence`, however= if we put an update system inside an update system, we can "reset" the `nS= equence` of the inner update system by updating the outer update system. > We can chain this concept further and add more update systems nested insi= de 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 Li= ghtning channels (your given CoinSwap protocol is "only" two updates, for i= nstance) this is usually a good tradeoff, > > It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is to= o controversial to get into Bitcoin, provided Schnorr (definitely uncontrov= ersial) does get into Bitcoin. > > > A and B can collude to take the money from C, but since all instanc= es > > 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"= 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. Thi= s > > means security can be on par with federated sidechains [5], and is > > similar to how ZmnSCPxj replaced the escrow key with a federation i= n > > =E2=80=9CSmart Contracts Unchained=E2=80=9D [6]. > > This makes me happy. > > Regards, > ZmnSCPxj