path: root/3d/22f2ccd25073d244ede2ccc4c8d571fda6acb9

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
>
>