From matsjj at gmail.com  Mon Jul 20 18:42:11 2015
From: matsjj at gmail.com (Mats Jerratsch)
Date: Mon, 20 Jul 2015 20:42:11 +0200
Subject: [Lightning-dev] Thoughts on HTLC Scripts
Message-ID: <CAE8CtVmL3dA9REjL_-BaArhZoOzwbCeO2E_vNcVJdkHU7diq1w@mail.gmail.com>

Hey everybody,

I'm currently working on a Lightning Implementation Client/Server in
Java, building on bitcoinj (just as a basic framework, I wrote my own
classes to realize LN). Will push it into GitHub within a few weeks I
guess.

I had an implementation ready, that would not need any further changes
for bitcoin (works today already), but I just threw it all off the
ship, reading through your paper. It was based on some trust
dependencies and channel transactions were highly asynchronous,
meaning that a LN-Network would not be possible (since one party will
always be assumed lower trust and therefore has a disadvantage in
enforcing the ruleset). I can share further details if there is any
interest (it further needed to exchange 3 transactions for each
payment in the channel, building up huge amount of data within a few
hundred payments....)

First I wanted to write up my solution for the anchor problem, but
then I realized, your solution makes it possible to have channels open
indefinitely, while mine doesn't. And while it really looks fishy,
indefinite channels are really worth it. However, it is important to
wait for the anchor tx of the other party. Otherwise the server has to
pay transaction fees for releasing his funds again and again (which
can really add up..).

While implementing the new redeemscripts, I noticed there is no delay
for the 'HTLC Receiver Redeemscript', when redeeming the contract
using R. Doesn't this mean that revoked or not, if the receiver has R,
he can instantly claim these outputs. Let's assume a channel with 4
states:

t=t0 - client has no funds in the channel (or very little, he wants to
receive money)
t=t1 - client has received funds and has lots of unsettled payments in
his channel
t=t2 - client settled with the server (revealed R)
t=t3 - client has spent all funds again

At t=t3, the client has no incentive anymore to play with the rules,
since there's nothing he can lose (his balance is zero after all..).
So he can broadcast the channel transaction from t1 and instantly
claim all outputs using R. While the server can technically claim the
funds aswell, using the COMMIT-REVOCATION-HASH, it boils down to a
race. I'm not really sure if this will solve the issue completely, but
I think OP_CSV after OP_DROP will mitigate this by ensuring some
delay. This is especially important other way round, as clients won't
be online all the time and the delay here really determines how often
the client has to check back.

Really good work though, although I just had to delete and rewrite a
good share of my work. ;)