path: root/a9/b935a4101b5f02a63309ea0aba661237ab1476

Return-Path: <tom@commerceblock.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C641CC0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Mar 2020 14:44:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id B48BA87770
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Mar 2020 14:44:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4x15Q-Rl+zH8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Mar 2020 14:44:54 +0000 (UTC)
X-Greylist: delayed 00:27:46 by SQLgrey-1.7.6
Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com
 [209.85.167.44])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 0BFE887748
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Mar 2020 14:44:54 +0000 (UTC)
Received: by mail-lf1-f44.google.com with SMTP id t21so1990209lfe.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Mar 2020 07:44:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:from:date:message-id:subject:to;
 bh=qburXB+YwqjTV6CQGL79WILkx6BmdBL6uDaZRdAVpko=;
 b=ACUsDae8G7jjWLJMdjEQLgUNGHpg42U94HpYlJOtMfgGrKHp9KmRJ2n+XGWrknkMRJ
 W8NHOEIAcbPaNOUysojmQxQm8nsyZUkydI0HtgcOEBqbezPTJkIc0jG/WZdrJ9RUo50U
 9+7tuG4lwuOUtpDeObL49OgG9HYicKjDKyS/gqTzaOa9G/yLvquRnSlyE+hHv8GnpirI
 tnlm0xQSerQtfY1Mwxib6WwhNCl/Zd77LJqF8ajED5/SHSk7NhlyGo4jpwNlLYcgFYNh
 8bCK1OLJBDwDk9dUaMNrdUbWzVOwI7ZDcDjpAaXE4xu5PHtmf3XVyMyNc9cnvcnTSMwk
 kEBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=qburXB+YwqjTV6CQGL79WILkx6BmdBL6uDaZRdAVpko=;
 b=XvZDXM7iVpDOcXh79gpPxnTVz82dbsPT85OVg2QcvL1M7ap/20V4c/Yle1qlRXUAH9
 vGPiS6KqpLqJYFCGy40P4HQ5N+BLYmCgkXPnEFihqZrL/qIj1BzeU4+pGBeyQ6gbeR/0
 y31R5H/n6MRSTI1QfIhUtKJG2vYypBBOxXsWPovVFiKZLj0pNsSeaR7cpH3b8MI177N5
 8/fdmH6u+Q5026KEht5ojQEtbKUsGmYP3kBspXzMTXoH/bsWJhPsiWhiqP3vnXOJxvww
 rEdHncbrcgQpjWCttFtdMbnU7Qjk914A+dPimDZeHclAfKDwmFQTsEfaFG/rgzBbwb+N
 Q1Ew==
X-Gm-Message-State: ANhLgQ3I2wFawd8UiXSNojSBATWVhx/eEC6qCXRRB0cOh4gQw1/WMJL6
 IoXjXPXDsow6aWqW8ZBvFCQ8KGABlLL4TLRfWlyrRFJ6mQ==
X-Google-Smtp-Source: ADFU+vssJE71KplP7jvlBiWIUSr4xIrDkEyTDyGqQmGomBQxMMtMYGrF8owVCi+9RMpNj93MjQSwg2MNfEwWZCN3ptI=
X-Received: by 2002:aa7:c3d4:: with SMTP id l20mr2904867edr.67.1585144341282; 
 Wed, 25 Mar 2020 06:52:21 -0700 (PDT)
MIME-Version: 1.0
From: Tom Trevethan <tom@commerceblock.com>
Date: Wed, 25 Mar 2020 13:52:10 +0000
Message-ID: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000061523805a1ae2d32"
X-Mailman-Approved-At: Wed, 25 Mar 2020 15:00:07 +0000
Subject: [bitcoin-dev] Statechain implementations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 25 Mar 2020 14:44:55 -0000

--00000000000061523805a1ae2d32
Content-Type: text/plain; charset="UTF-8"

Hi all,

We are starting to work on an implementation of the statechains concept (
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
with particular interest in using the protocol enable the change of
ownership (novation) of an individual position in an active discreet log
contract (DLC) without an on-chain transaction, and without needing the
cooperation of the counterparty. The protocol as outlined by Ruben requires
features not currently available in Bitcoin (like SIGHASH_NOINPUT), and it
is uncertain when (or even if) this will be added. So we are looking at
variants that would work with current Bitcoin functionality, and it would
be good to get some feedback on them.

There are two main modifications we are looking at:
1. Instead of an eltoo-based backup/refund transaction (enabling the
current owner to claim the UTXO in case the statechain entity disappears)
we propose using a decrementing nLocktime for backup transactions as the
output changes hands. Here, the first owner gets a backup transaction with
an nLocktime at some future height (h0), then the next owner gets a backup
transaction with nLocktime (h0-c) where c is a confirmation window. This
approach has the downside of limiting the lifetime of the UTXO, but it also
doesn't require the current owner to be always online.

2. Replacing the 2-of-2 multisig output (paying to statechain entity SE key
and transitory key) with a single P2(W)PKH output where the public key
shared between the SE and the current owner. The SE and the current owner
can then sign with a 2-of-2 ECDSA MPC. This enables each owner to generate
their own private key share, and the SE changes their key share at each
change of ownership (with the shared public key remaining the same). This
works as follows (.G is EC point multiplication, * is scalar
multiplication):

KeyGen:

a. Owner 1 generates private key share o1 then calculates the corresponding
public key of the share O1 and sends it to the SE: O1 = o1.G
b. The SE then generates a private key: s1 (the SE private key share),
calculates the corresponding public key and sends it to Owner 1: S1 = s1.G
c. Both SE and Owner 1 then multiply the public keys they receive by their
own private key shares to obtain the same shared public key P (which
corresponds to a shared private key of p = o1*s1): P = o1.(s1.G) = s1.(o1.G)
d. Owner 1 creates a funding transaction (Tx0) to pay an amount A to the
address corresponding to P (but doesn't sign it).
e. Once Owner 1 and SE cooperatively sign the first backup transaction,
Owner 1 then signs and broadcasts the deposit transaction Tx0.

Transfer from Owner 1 to Owner 2:

a. Owner 2 generates two private keys: o2 (the new owner UTXO private key
share) and b2 (the new owner refund private key).
b. The SE generates a temporary blinding nonce x and calculates the value
x*s1 and sends this securely to Owner 2.
c. Owner 2 then multiplies this received value by the modular inverse of o2
(o2_inv) and then sends this value (x*s1*o2_inv), to Owner 1.
d. Owner 1 then multiplies this received value by the key share o1 and
sends the resulting value (x*s1*o2_inv*o1) to the SE.
e. The SE then multiplies this received value by the modular inverse of the
temporary nonce (x_inv) to obtain x*s1*o2_inv*o1*x_inv. This cancels the
blinding nonce x to give s1*o2_inv*o1. This value, when multiplied by the
new owner key share o2 equals the original shared private key s1*o1.
f. The SE then sets this value equal to s2 = s1*o2_inv*o1 and deletes s1.
s2 and o2 are now the key shares of `P` and can be used to colaboritively
sign (with 2P ECDSA). So long as the SE delets s1, the old owner key share
(o1) is of no use in deriving or co-signing with the full shared private
key, and is invalidated.
g. The shared public key P remains unchanged, but the corresponding private
key (which no individual party ever has knowledge of or can derive) can
only be determined from the key shares of the SE and Owner 2 (i.e. P =
s2*o2.G).
h. Owner 2 then calculates their backup public key (B2 = b2.G) and sends it
to the SE.
i. The SE creates a backup transaction (Tx2) that pays the output of Tx0 to
the address corresponding to B2 , with `nLockTime` set to a block height h0
- c0, where c0, is a confirmation time sufficient to guarantee that Tx2 can
be confirmed in the blockchain before Tx1 (therefore making Tx1 invalid).
j. Owner 2 and the SE then cooperate to sign Tx2 with shared key (P) using
the 2P ECDSA protocol, which Owner 2 then saves.

The principle of the logic of the key transfer is that the two separate key
shares are updated, but the full shared private key (which no-one knows)
remains the same. The new owner chooses a new secret value for their
private key share, and this (along with the private key share of the
previous owner) is utilized by the SE to update their share. The use of the
nonce (x) prevents any of the participants from determining any information
about each others secret keys. In this way Owner 2 cannot determine s1 from
x*s1, Owner 1 cannot determine s1 or o2 from x*s1*o2_inv and the SE cannot
determine o1 or o2 from x*s1*o2_inv*o1.

This transfer protocol can be repeated to transfer the ownership to new
owners. Each time the SE key share sX is updated, the previous key shares
become invalid and are of no use even if the current key share is
subsequently revealed. The SE still needs to be trusted to delete the old
key share, but this protocol removes the risk the the SE can be hacked by a
previous owner to steal the funds.

Any comments on the above would be greatly appreciated.

Tom

--00000000000061523805a1ae2d32
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>We are starting to work on an implementatio=
n of the statechains concept (<a href=3D"https://medium.com/@RubenSomsen/st=
atechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">https://me=
dium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-=
1ae4845a4a39</a>), with particular interest in using the protocol enable th=
e change of ownership (novation) of an individual position in an active dis=
creet log contract (DLC) without an on-chain transaction, and without needi=
ng the cooperation of the counterparty. The protocol as outlined by Ruben r=
equires features not currently available in Bitcoin (like SIGHASH_NOINPUT),=
 and it is uncertain when (or even if) this will be added. So we are lookin=
g at variants that would work with current Bitcoin functionality, and it wo=
uld be good to get some feedback on them. <br><br>There are two main modifi=
cations we are looking at: <br>1. Instead of an eltoo-based backup/refund t=
ransaction (enabling the current owner to claim the UTXO in case the statec=
hain entity disappears) we propose using a decrementing nLocktime for backu=
p transactions as the output changes hands. Here, the first owner gets a ba=
ckup transaction with an nLocktime at some future height (h0), then the nex=
t owner gets a backup transaction with nLocktime (h0-c) where c is a confir=
mation window. This approach has the downside of limiting the lifetime of t=
he UTXO, but it also doesn&#39;t require the current owner to be always onl=
ine. <br><br>2. Replacing the 2-of-2 multisig output (paying to statechain =
entity SE key and transitory key) with a single P2(W)PKH output where the p=
ublic key shared between the SE and the current owner. The SE and the curre=
nt owner can then sign with a 2-of-2 ECDSA MPC. This enables each owner to =
generate their own private key share, and the SE changes their key share at=
 each change of ownership (with the shared public key remaining the same). =
This works as follows (.G is EC point multiplication, * is scalar multiplic=
ation):<br><br>KeyGen:<br><br>	a. Owner 1 generates private key share o1 th=
en calculates the corresponding public key of the share O1 and sends it to =
the SE: O1 =3D o1.G<br>	b. The SE then generates a private key: s1 (the SE =
private key share), calculates the corresponding public key and sends it to=
 Owner 1: S1 =3D s1.G<br>	c. Both SE and Owner 1 then multiply the public k=
eys they receive by their own private key shares to obtain the same shared =
public key P (which corresponds to a shared private key of p =3D o1*s1): P =
=3D o1.(s1.G) =3D s1.(o1.G)<br>	d. Owner 1 creates a funding transaction (T=
x0) to pay an amount A to the address corresponding to P (but doesn&#39;t s=
ign it). <br>	e. Once Owner 1 and SE cooperatively sign the first backup tr=
ansaction, Owner 1 then signs and broadcasts the deposit transaction Tx0. <=
br><br>Transfer from Owner 1 to Owner 2:<br><br>	a. Owner 2 generates two p=
rivate keys: o2 (the new owner UTXO private key share) and b2 (the new owne=
r refund private key).<br>	b. The SE generates a temporary blinding nonce x=
 and calculates the value x*s1 and sends this securely to Owner 2. <br>	c. =
Owner 2 then multiplies this received value by the modular inverse of o2 (o=
2_inv) and then sends this value (x*s1*o2_inv), to Owner 1.<br>	d. Owner 1 =
then multiplies this received value by the key share o1 and sends the resul=
ting value (x*s1*o2_inv*o1) to the SE.<br>	e. The SE then multiplies this r=
eceived value by the modular inverse of the temporary nonce (x_inv) to obta=
in x*s1*o2_inv*o1*x_inv. This cancels the blinding nonce x to give s1*o2_in=
v*o1. This value, when multiplied by the new owner key share o2 equals the =
original shared private key s1*o1. <br>	f. The SE then sets this value equa=
l to s2 =3D s1*o2_inv*o1 and deletes s1. s2 and o2 are now the key shares o=
f `P` and can be used to colaboritively sign (with 2P ECDSA). So long as th=
e SE delets s1, the old owner key share (o1) is of no use in deriving or co=
-signing with the full shared private key, and is invalidated. <br>	g. The =
shared public key P remains unchanged, but the corresponding private key (w=
hich no individual party ever has knowledge of or can derive) can only be d=
etermined from the key shares of the SE and Owner 2 (i.e. P =3D s2*o2.G).<b=
r>	h. Owner 2 then calculates their backup public key (B2 =3D b2.G) and sen=
ds it to the SE.<br>	i. The SE creates a backup transaction (Tx2) that pays=
 the output of Tx0 to the address corresponding to B2 , with `nLockTime` se=
t to a block height h0 - c0, where c0, is a confirmation time sufficient to=
 guarantee that Tx2 can be confirmed in the blockchain before Tx1 (therefor=
e making Tx1 invalid).<br>	j. Owner 2 and the SE then cooperate to sign Tx2=
 with shared key (P) using the 2P ECDSA protocol, which Owner 2 then saves.=
 <br><br>The principle of the logic of the key transfer is that the two sep=
arate key shares are updated, but the full shared private key (which no-one=
 knows) remains the same. The new owner chooses a new secret value for thei=
r private key share, and this (along with the private key share of the prev=
ious owner) is utilized by the SE to update their share. The use of the non=
ce (x) prevents any of the participants from determining any information ab=
out each others secret keys. In this way Owner 2 cannot determine s1 from x=
*s1, Owner 1 cannot determine s1 or o2 from x*s1*o2_inv and the SE cannot d=
etermine o1 or o2 from x*s1*o2_inv*o1. <br><br>This transfer protocol can b=
e repeated to transfer the ownership to new owners. Each time the SE key sh=
are sX is updated, the previous key shares become invalid and are of no use=
 even if the current key share is subsequently revealed. The SE still needs=
 to be trusted to delete the old key share, but this protocol removes the r=
isk the the SE can be hacked by a previous owner to steal the funds. <br><b=
r>Any comments on the above would be greatly appreciated. <br><br>Tom<br></=
div>

--00000000000061523805a1ae2d32--