path: root/62/3aa8fd7732f399be0af5c15e834a893dd0ec13

Return-Path: <bob@mcelrath.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E2AC1C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 17:10:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id D8F4089434
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 17:10:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CeD6IAm3ogDK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 17:10:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 7B01C89432
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 17:10:20 +0000 (UTC)
Received: from mcelrath.org (localhost [127.0.0.1])
 by mcelrath.org (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 02RHAIp2017174
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); 
 Fri, 27 Mar 2020 17:10:18 GMT
Received: (from mcelrath@localhost)
 by mcelrath.org (8.14.4/8.14.4/Submit) id 02RHAI6o017173;
 Fri, 27 Mar 2020 17:10:18 GMT
X-Authentication-Warning: mcelrath.org: mcelrath set sender to
 bob@mcelrath.org using -f
Date: Fri, 27 Mar 2020 17:10:18 +0000
From: Bob McElrath <bob@mcelrath.org>
To: Tom Trevethan <tom@commerceblock.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200327171017.GM28113@mcelrath.org>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline
In-Reply-To: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Fri, 27 Mar 2020 17:32:37 +0000
Subject: Re: [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: Fri, 27 Mar 2020 17:10:22 -0000


--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Big picture, it seems to me this idea is workable and very interesting. I s=
ee
three likely enhancements that will be necessary or desirable:
    1. Atomic swap of multiple UTXOs, and binary decomposition of value in =
lots
    2. Key exchange ("addresses") to facilitate a secure comms path from=20
        sender -> receiver
    3. (Optional) single-use seals to close old state

(1) It's unlikely that a party sending a UTXO to another party will have a =
UTXO
of exactly the right size that's needed, already locked into the statechain=
=2E If
he has to create the UTXO first and then lock it into the statechain, the
statechain solution is no better than an on-chain send. And once the receiv=
er
has the UTXO, it's unlikely that he will want to send exactly that same amo=
unt
to another receiver later. This isn't a problem in Lightning where amounts =
can
be arbitrarily updated. As a consequence, I think Lightning is more valuabl=
e for
small-value payments, and statechains will be more valuable for larger valu=
es.

The natural solution is to decompose your outputs in a binary decomposition,
having e.g. UTXOs with 1048576 satoshis, another with 2097152 satoshis, and=
 so
on. Then when I want to send, I select the appropriate UTXOs as a binary
decomposition of the value I want to send, with a "lot size" of 1048576
satoshis, or the dust limit. The notion of "lots" like this is common in
traditional markets...many stocks are bought and sold in lots of 100, and f=
orex
is traded in lots of $100,000. Users of a statechain therefore need log(V)
available UTXOs locked into the statechain, where V is their value in BTC.
Having fixed lot sizes like this also makes coinjoin-type uses more viable.=
 The
statechain could also assist in dividing a UTXO into two utxos of the next =
lot
size down, so that I have the right UTXOs to hit the value I want to send.

This means that the statechain now has to *atomically* swap multiple UTXOs.=
 In
principle, it should be possible for a statechain to circumvent the
Pagnia-G=E4rtner theorem[1] as it is a trusted third party, but guaranteed =
output
delivery will still be a problem. If a statechain can do this, it is also
capable of performing such swaps across two blockchains, creating the
execution/clearing element (but not order book) for a DEX. This same mechan=
ism
can also be used to pay the SE for its service through a different UTXO tha=
n the
one being transferred.

Second (2), the steps in Tom's protocol presuppose a secure communications =
path
=66rom the sender's wallet to the receiver's. This is probably not practica=
l for a
myriad of reasons, but this data can be relayed through the SE if it is
encrypted for the target. This implies a new kind of "address" or "payment
request" that identifies the IP of the SE in use, pubkey of the
sender/recipient, and amount. If sender and receiver have each other's pubk=
eys
through another channel, as addresses/lightning payment requests are used t=
oday,
they can perform a Diffie-Hellman round mediated by the SE to establish a s=
ecure
communications path for the rounds of the protocol. Piggybacking on the
Lightning p2p network might be another option.

Third (3), a logical enhancement would be to use some kind of single-use se=
al,
which is "opened" when the UTXO is created or transferred, and "closed" whe=
n it
is transferred again. Thus a receiver can ensure that the sender is the hol=
der
of current state and not some old state.  It's a good idea from Peter Todd,=
 and
Tom's Mainstay[2] may be a way to do it. The SE itself can maintain a rolli=
ng
single-use seal Merkle root, periodically timestamped into Bitcoin for fast=
er
time resolution than Bitcoin, if you trust the SE but not your counterparty
(which is the trust assumption present in the first place). Getting Bitcoin
itself to reject backout transactions from closed seals is another problem.=
=2E.but
having a single-use seal implementation involved is a start.

=2E. [1] https://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.44.7863

=2E. [2] https://mainstay.xyz

Tom Trevethan via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> Hi all,
>=20
> 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 t=
he
> counterparty. The protocol as outlined by Ruben requires features not cur=
rently
> 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.
>=20
> There are two main modifications we are looking at:
> 1. Instead of an eltoo-based backup/refund transaction (enabling the curr=
ent
> owner to claim the UTXO in case the statechain entity disappears) we prop=
ose
> using a decrementing nLocktime for backup transactions as the output chan=
ges
> 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 wi=
th
> 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 requir=
e the
> current owner to be always online.
>=20
> 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE k=
ey 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 th=
en
> sign with a 2-of-2 ECDSA MPC. This enables each owner to generate their o=
wn
> 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):
>=20
> KeyGen:
>=20
> a. Owner 1 generates private key share o1 then calculates the correspondi=
ng
> public key of the share O1 and sends it to the SE: O1 =3D 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 =3D s=
1.G
> c. Both SE and Owner 1 then multiply the public keys they receive by thei=
r own
> private key shares to obtain the same shared public key P (which correspo=
nds to
> a shared private key of p =3D o1*s1): P =3D o1.(s1.G) =3D 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, O=
wner 1
> then signs and broadcasts the deposit transaction Tx0.
>=20
> Transfer from Owner 1 to Owner 2:
>=20
> 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 se=
nds
> the resulting value (x*s1*o2_inv*o1) to the SE.
> e. The SE then multiplies this received value by the modular inverse of t=
he
> 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 =3D s1*o2_inv*o1 and deletes s=
1. s2
> and o2 are now the key shares of `P` and can be used to colaboritively si=
gn
> (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 priva=
te 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 =3D s2*o2.G).
> h. Owner 2 then calculates their backup public key (B2 =3D b2.G) and send=
s 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) usin=
g the
> 2P ECDSA protocol, which Owner 2 then saves.
>=20
> The principle of the logic of the key transfer is that the two separate k=
ey
> 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 priv=
ate
> key share, and this (along with the private key share of the previous own=
er) is
> utilized by the SE to update their share. The use of the nonce (x) preven=
ts any
> of the participants from determining any information about each others se=
cret
> 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 =
=66rom
> x*s1*o2_inv*o1.
>=20
> This transfer protocol can be repeated to transfer the ownership to new o=
wners.
> 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, b=
ut
> this protocol removes the risk the the SE can be hacked by a previous own=
er to
> steal the funds.
>=20
> Any comments on the above would be greatly appreciated.
>=20
> Tom
> !DSPAM:5e7b7203210751402398759!

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
> !DSPAM:5e7b7203210751402398759!

--
Cheers, Bob McElrath

"For every complex problem, there is a solution that is simple, neat, and w=
rong."
    -- H. L. Mencken=20


--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAl5+M3kACgkQjwioWRGe9K0vbQCfW/kcUXtHnKEGftpVXmmVDKUM
6YsAoO8onD93Q/4qlq6lD/a6LGOVfvTM
=y6fO
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--