Date: Thu, 06 Jun 2019 06:31:45 +0000
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <L118b6Auac7OxL9DmyvXmFldcnSvb1xU807qtsPt6fGY0-fpg55U5VmEdAgC1T87r274UuqZ-iS0yDNBhZfvhsEW3ZHhdl1eb5Cg4I04ckE=@protonmail.com>
In-Reply-To: <CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@mail.gmail.com>
References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com>
	<8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com>
	<CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic
	blind signing server
Precedence: list

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 <rsomsen@gmail.com> 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