Date: Thu, 06 Jun 2019 00:09:28 +0000
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
Subject: Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic
	blind signing server
Precedence: list

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