path: root/cc/6a2dc9784ab4f72182e9b2d375e2ec34e6b4a3

Return-Path: <nadav@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7168F115D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Apr 2019 16:17:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com
	[209.85.166.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4ACB51C0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Apr 2019 16:17:23 +0000 (UTC)
Received: by mail-io1-f44.google.com with SMTP id d201so21041563iof.7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Apr 2019 09:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=suredbits-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=LdExkb+A6YdWfZVjt8PIHX3u4x2thPw8Zd/FShyzj58=;
	b=V7wvgnquAeMpy1JPkImHpX1JVL7BQ/yAmBM1qWtHpwZmCzKc0fFMkFrUYEPX/7NsOp
	xkMXIjsL2GIrAIyV7puhBqaJRgfLFp60AJ3WTuYISI7f67EtY7AL9MfdmSDNIrA0GAsT
	s49IJTDc8FRwLWW41s+o4gRIEJV+iQqD3LV5Oiv4PaCuYxbQbnVl43Dt5yVOY4a5ffia
	OX9Gpve/8IqbEr388aKGM4BajAZ7A0d2cxXUpW6/wXh0otpNusEcjLOd57pliXJbIyow
	kc9DjEOBd/4WBMDzfEljd2wlLY/0PKENw/wF19lR7cbLsLRHdJFvr11CXk0AqH6PgpGT
	v4yg==
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;
	bh=LdExkb+A6YdWfZVjt8PIHX3u4x2thPw8Zd/FShyzj58=;
	b=jjHX4NVztjFDLREam74ZsHSZnhfLGyoiLv3Vp2mGsZj6N/xbGOC87/c9+yK/Q1DJfB
	kjCb/ORi7gxGIrY3uq28s3LBcrbobZceooqkaiL3Af5gxK9UdDeOYV8Ukf0DuL1aB4sb
	9FCTozUKa+cWHphJx1Xb9P8P8F8768HiEYdnyqXpkw1e8tk4hBI2OJkzafNK4bhhL0u/
	7JWNUF2YYhMbx5HxCVqsqRZz5VX6SsDjt4HJu6/sfFvQyDMtKIKe8VTQ52xCW39aQ9ZB
	8Y7yxGuiqQFSp/AlTBHuxKWOtxXY25CF6tYevX/L5oIeE/grkprJBcPDqAXRd4MfP9RO
	eM6w==
X-Gm-Message-State: APjAAAVQ6Of69CEk3UmW5IRhqw8GL30E2JpakJdvsQGiBpibWAYKrUiI
	48igPn9mnsO8OwKm6u0zlsHemRJ/R0wzbr9jT19ZCQ==
X-Google-Smtp-Source: APXvYqyx1DCoHHoAEwlMtitDDDWIIiiVTOkDdoTTv21Uys1s4ftKpbdNZGJOQTCQ0uYSN+CUAGm5sKBe1oNEzQp3Ku0=
X-Received: by 2002:a5e:9806:: with SMTP id s6mr59285220ioj.86.1555517842523; 
	Wed, 17 Apr 2019 09:17:22 -0700 (PDT)
MIME-Version: 1.0
References: <IAFPSZAn6TYt348fmmnPznQ_ApG7pa48eMjzTgrjuVAt6fS1tNieRxlcIXyTATy2vjZCUn4wVQcsyDlyb_3Ip46BstFRikB95-lKewAZBEE=@protonmail.com>
In-Reply-To: <IAFPSZAn6TYt348fmmnPznQ_ApG7pa48eMjzTgrjuVAt6fS1tNieRxlcIXyTATy2vjZCUn4wVQcsyDlyb_3Ip46BstFRikB95-lKewAZBEE=@protonmail.com>
From: Nadav Kohen <nadav@suredbits.com>
Date: Wed, 17 Apr 2019 11:17:11 -0500
Message-ID: <CALGTLwPjH8x_6gqRoXnkWKu8ZcJSgWBFV0vWss60MTi4E1MdHQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007222490586bc388b"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,URI_NOVOWEL 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: Thu, 18 Apr 2019 13:40:26 +0000
Subject: Re: [bitcoin-dev] Smart Contracts Unchained
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, 17 Apr 2019 16:17:24 -0000

--0000000000007222490586bc388b
Content-Type: text/plain; charset="UTF-8"

Hi all!

I've been thinking a lot about how to add the benefits that lightning
provides in terms of privacy and speed to the smart contracts unchained
setup. The high-level idea is to utilize the fact that a lightning channel
already has on-chain funds locked up, and if parties cooperate, some of
these funds can be moved into the 2/3 MultiSig output needed for the escrow
scheme by cooperating off-chain (and then moved back to their channel
balances off-chain as well). The following is an admittedly pretty rough
outline of how this might be accomplished.

A - B : Smart Contracts in a Lightning Channel

1) Parties both commit to a 2/3 MultiSig output on their next commitment
transaction
2) Parties then both revoke_and_ack
3) When the contract yields a result, the to_local and to_remote balances
can be updated and the 2/3 MultiSig output can be removed
4) If either party is uncooperative, their counter-party can force close
the channel and funds can be resolved on-chain using the escrow

If either party does not revoke_and_ack well before any potential for them
to discover if they have an advantage in the contract (or after some small
but reasonable time), their counter-party should go on chain with the
commitment transaction containing the 2/3 MultiSig

A - B - C : Single Hop Smart Contracts (Useful if someone, B in this case,
wants to provide a hub that matches users wanting to enter smart contracts)

1) A irrevocably commits to a 2/3 MultiSig output on their commitment
transaction with B (which B also commits to but does not yet revoke their
old state)
2) C irrevocably commits to the same 2/3 MultiSig output on their
commitment transaction with B (which B also commits to)
3) B irrevocably commits to both outputs
4) When the contract yields a result, say A should win some money from C,
then A can ask B to remove that output (and update balances) by revealing
to B how to claim funds from C
5) B can then ask C to remove the output and add to B's balance

If B does not revoke_and_ack on either channel, then the affected
counter-party should close the channel and go on chain with the 2/3
MultiSig transaction
If B refuses to remove the output, A can claim their funds on-chain where B
can learn how to claim funds from C
If C refuses to remove the output, B can claim their funds on-chain using
the information revealed by A

Problems: How do we ensure that only B can claim the 2/3 MultiSig from C,
and not anyone who sees A's on-chain spend of their 2/3 MultiSig? I'm
pretty sure this is possible to do but I don't know Script well enough

A - B - C - D : Fully Routed Smart Contracts

1) Given the n possible outcomes in which A gets money from the contract
between A and D, a_1 < a_2 < ... < a_n, and the m possible outcomes in
which D gets money, d_1 < d_2 < ... < d_m, D must send n HTLCs to A with
the amounts a_1, a_2 - a_1, a_3 - a_2, ..., a_n - a_(n-1) and A must send m
HTLCs to D with amounts d_1, d_2 - d_1, d_3 - d_2, ..., d_m - d_(m-1)
2) These HTLCs must be special and have two hashes, where either preimage
unlocks the funds
3) In the payments from A to D, A knows one preimage and the smart
contracting platform knows the other (and similarly for D to A)
4) Should a_i be the outcome of the contract, D should tell A what the
preimages are to payments 1 through i
5) D should fail all m payments
6) A should fail all payments i+1 through n
(It is possible and in fact likely that there can be ways to use fewer
transactions and thus less collateral than this, perhaps by using
subtraction and not just addition as in a_i - d_j, what I've presented is
simply a lower bound that works in all cases)

If D does not reveal their preimages, A can get the relevant preimages from
the smart contracting platform

Problems: The smart contracting platform is given more information about
the contract in the happy path in this scheme. Also, all routers need to
support special double-hash HTLCs

An alternative way to possibly do multi-hop routing that would require less
be told to the escrow service, is to have each routing node add an output
on either side where it takes one position in one channel and the other
position in the other channel (essentially allowing them to break event
when the contract is completed). This has the same problems as the Single
Hop case as well as the additional problem (that I couldn't imagine a
solution for) of making the commitments to the 2/3 MultiSig output on
commitment transactions atomic; in the single hop case incentives seem to
work out but I don't know how "failed routing" would be detected or handled
in the multi-hop case.

Feedback welcome!

Best,
Nadav

On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> https://zmnscpxj.github.io/bitcoin/unchained.html
>
> Smart contracts have traditionally been implemented as part of the
> consensus rules of some blokchain.  Often this means creating a new
> blockchain, or at least a sidechain to an existing blockchain.  This
> writeup proposes an alternative method without launching a separate
> blockchain or sidechain, while achieving security similar to federated
> sidechains and additional benefits to privacy and smart-contract-patching.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi all!<br></div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr">I&#39;ve been thinking a lot about how to add the benefits that li=
ghtning provides in terms of privacy and speed to the smart contracts uncha=
ined setup. The high-level idea is to utilize the fact that a lightning cha=
nnel already has on-chain funds locked up, and if parties cooperate, some o=
f these funds can be moved into the 2/3 MultiSig output needed for the escr=
ow scheme by cooperating off-chain (and then moved back to their channel ba=
lances off-chain as well). The following is an admittedly pretty rough outl=
ine of how this might be accomplished.<br><br>A - B : Smart Contracts in a =
Lightning Channel<br><br>1) Parties both commit to a 2/3 MultiSig output on=
 their next commitment transaction<br>2) Parties then both revoke_and_ack<b=
r>3) When the contract yields a result, the to_local and to_remote balances=
 can be updated and the 2/3 MultiSig output can be removed<br>4) If either =
party is uncooperative, their counter-party can force close the channel and=
 funds can be resolved on-chain using the escrow<br><br>If either party doe=
s not revoke_and_ack well before any potential for them to discover if they=
 have an advantage in the contract (or after some small but reasonable time=
), their counter-party should go on chain with the commitment transaction c=
ontaining the 2/3 MultiSig<br><br>A - B - C : Single Hop Smart Contracts (U=
seful if someone, B in this case, wants to provide a hub that matches users=
 wanting to enter smart contracts)<br><br>1) A irrevocably commits to a 2/3=
 MultiSig output on their commitment transaction with B (which B also commi=
ts to but does not yet revoke their old state)<br>2) C irrevocably commits =
to the same 2/3 MultiSig output on their commitment transaction with B (whi=
ch B also commits to)<br>3) B irrevocably commits to both outputs<br>4) Whe=
n the contract yields a result, say A should win some money from C, then A =
can ask B to remove that output (and update balances) by revealing to B how=
 to claim funds from C<br>5) B can then ask C to remove the output and add =
to B&#39;s balance<br><br>If B does not revoke_and_ack on either channel, t=
hen the affected counter-party should close the channel and go on chain wit=
h the 2/3 MultiSig transaction<br>If B refuses to remove the output, A can =
claim their funds on-chain where B can learn how to claim funds from C<br>I=
f C refuses to remove the output, B can claim their funds on-chain using th=
e information revealed by A<br><br>Problems: How do we ensure that only B c=
an claim the 2/3 MultiSig from C, and not anyone who sees A&#39;s on-chain =
spend of their 2/3 MultiSig? I&#39;m pretty sure this is possible to do but=
 I don&#39;t know Script well enough<br><br>A - B - C - D : Fully Routed Sm=
art Contracts<br><br>1) Given the n possible outcomes in which A gets money=
 from the contract between A and D, a_1 &lt; a_2 &lt; ... &lt; a_n, and the=
 m possible outcomes in which D gets money, d_1 &lt; d_2 &lt; ... &lt; d_m,=
 D must send n HTLCs to A with the amounts a_1, a_2 - a_1, a_3 - a_2, ..., =
a_n - a_(n-1) and A must send m HTLCs to D with amounts d_1, d_2 - d_1, d_3=
 - d_2, ..., d_m - d_(m-1)<br>2) These HTLCs must be special and have two h=
ashes, where either preimage unlocks the funds<br>3) In the payments from A=
 to D, A knows one preimage and the smart contracting platform knows the ot=
her (and similarly for D to A)<br>4) Should a_i be the outcome of the contr=
act, D should tell A what the preimages are to payments 1 through i<br>5) D=
 should fail all m payments<br>6) A should fail all payments i+1 through n<=
br>(It is possible and in fact likely that there can be ways to use fewer t=
ransactions and thus less collateral than this, perhaps by using subtractio=
n and not just addition as in a_i - d_j, what I&#39;ve presented is simply =
a lower bound that works in all cases)<br><br>If D does not reveal their pr=
eimages, A can get the relevant preimages from the smart contracting platfo=
rm<br><br>Problems: The smart contracting platform is given more informatio=
n about the contract in the happy path in this scheme. Also, all routers ne=
ed to support special double-hash HTLCs<br><br>An alternative way to possib=
ly do multi-hop routing that would require less be told to the escrow servi=
ce, is to have each routing node add an output on either side where it take=
s one position in one channel and the other position in the other channel (=
essentially allowing them to break event when the contract is completed). T=
his has the same problems as the Single Hop case as well as the additional =
problem (that I couldn&#39;t imagine a solution for) of making the commitme=
nts to the 2/3 MultiSig output on commitment transactions atomic; in the si=
ngle hop case incentives seem to work out but I don&#39;t know how &quot;fa=
iled routing&quot; would be detected or handled in the multi-hop case.</div=
><div dir=3D"ltr"><br></div><div>Feedback welcome!</div><div><br></div><div=
>Best,<br></div><div>Nadav<br></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><a href=3D"https://zmnscpxj.github.=
io/bitcoin/unchained.html" rel=3D"noreferrer" target=3D"_blank">https://zmn=
scpxj.github.io/bitcoin/unchained.html</a><br>
<br>
Smart contracts have traditionally been implemented as part of the consensu=
s rules of some blokchain.=C2=A0 Often this means creating a new blockchain=
, or at least a sidechain to an existing blockchain.=C2=A0 This writeup pro=
poses an alternative method without launching a separate blockchain or side=
chain, while achieving security similar to federated sidechains and additio=
nal benefits to privacy and smart-contract-patching.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000007222490586bc388b--