Date: Thu, 18 Apr 2019 05:33:42 +0000
To: Nadav Kohen <nadav@suredbits.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <BuPb9X2Va172-mEpWEgdK8rcUEvLKJ4Y_804yfwJLULSa7tkTvpDyZ9GWJD0Q84AtdkzePOU-bTtRjdi5f-tbuJM4src6zaNIy9XM1tGeoQ=@protonmail.com>
In-Reply-To: <CALGTLwPjH8x_6gqRoXnkWKu8ZcJSgWBFV0vWss60MTi4E1MdHQ@mail.gmail.com>
References: <IAFPSZAn6TYt348fmmnPznQ_ApG7pa48eMjzTgrjuVAt6fS1tNieRxlcIXyTATy2vjZCUn4wVQcsyDlyb_3Ip46BstFRikB95-lKewAZBEE=@protonmail.com>
	<CALGTLwPjH8x_6gqRoXnkWKu8ZcJSgWBFV0vWss60MTi4E1MdHQ@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] Smart Contracts Unchained
Precedence: list

Good morning Nadav,

Yes, transporting contracts over a single direct channel is always possible=
.

When Lightning switches to Decker-Russell-Osuntokun ("eltoo"), do note that=
 contracts with an absolute timelock must be forced onchain earlier than th=
e absolute timelock by the CSV requirement of the channel (unilateral close=
 time).

With current Poon-Dryja channels, transported contracts must be augmented b=
y a 2-of-2 on all branches, which can be done by adding a 2-of-2 multisig o=
n the escrow branch, using temporary keys.
The purpose of the 2-of-2 is to enforce that the only valid claims to the c=
ontract have an `nSequence` representing the unilateral close time of the c=
hannel.
xref. HTLC-timeout and HTLC-success transactions in BOLT#3.

Transporting over multiple hops requires that compliance to a contract make=
s one side reveal information that the other side does not know, together w=
ith some kind of timeout/backoff.
Practically speaking, only HTLC-type contracts can be transported.
For example, DLCs will have many possible branches where the Oracle provide=
s a signature for one branch, and this signature is what is learned by the =
other party in the contract.
In addition, DLCs for practical use require a timeout (in case the Oracle f=
ails to reveal the signature on the appointed time).
Thus, far fewer contracts can be transported over the network.

(Of note is that a Lightning channel is itself a contract (that is transpor=
table only within a direct channel); this is the basis of channel factories=
, where the factory level is effectively a "channel" with more than two par=
ticipants, and transporting Lightning channels instead of HTLCs)
(You may be interested in looking at the "Fulgurite" effort)

OF note is that DLCs have an Oracle.
I observe that escrow services (which are specializations of the Smart Cont=
racts Unchained technique) are basically oracles also.
If DLCs can transport their oracle signatures over multiple hops, then it s=
hould be possible for Smart Contracts Unchained to transport the federation=
/escrow signatures over multiple hops also.
I do not know the math behind DLCs enough to be certain, however, and leave=
 it to better mathematicians than I.

Regards,
ZmnSCPxj

Regards,
ZmnSCPxj

=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, April 18, 2019 12:17 AM, Nadav Kohen <nadav@suredbits.com> wro=
te:

> Hi all!
>
> I've been thinking a lot about how to add the benefits that lightning pro=
vides 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 alread=
y has on-chain funds locked up, and if parties cooperate, some of these fun=
ds can be moved into the 2/3 MultiSig output needed for the escrow scheme b=
y 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 the=
m to discover if they have an advantage in the contract (or after some smal=
l but reasonable time), their counter-party should go on chain with the com=
mitment 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 contract=
s)
>
> 1) A irrevocably commits to a 2/3 MultiSig output on their commitment tra=
nsaction 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 commitm=
ent 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 trans=
action
> 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 pret=
ty 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 whic=
h D gets money, d_1 < d_2 < ... < d_m, D must send n HTLCs to A with the am=
ounts 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 contra=
cting 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 pr=
eimages 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 tr=
ansactions 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 low=
er bound that works in all cases)
>
> If D does not reveal their preimages, A can get the relevant preimages fr=
om 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 su=
pport special double-hash HTLCs
>
> An alternative way to possibly do multi-hop routing that would require le=
ss be told to the escrow service, is to have each routing node add an outpu=
t on either side where it takes one position in one channel and the other p=
osition in the other channel (essentially allowing them to break event when=
 the contract is completed). This has the same problems as the Single Hop c=
ase as well as the additional problem (that I couldn't imagine a solution f=
or) of making the commitments to the 2/3 MultiSig output on commitment tran=
sactions atomic; in the single hop case incentives seem to work out but I d=
on't know how "failed routing" would be detected or handled in the multi-ho=
p case.
>
> Feedback welcome!
>
> Best,
> Nadav
>
> On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>
> > https://zmnscpxj.github.io/bitcoin/unchained.html
> >
> > Smart contracts have traditionally been implemented as part of the cons=
ensus rules of some blokchain.=C2=A0 Often this means creating a new blockc=
hain, or at least a sidechain to an existing blockchain.=C2=A0 This writeup=
 proposes an alternative method without launching a separate blockchain or =
sidechain, while achieving security similar to federated sidechains and add=
itional benefits to privacy and smart-contract-patching.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev