Hi ZmnSCPxj, Christian, list,

the paper is a bit confusing regarding the setup transaction, as it is
not described formally. There also seems to be a mixup of "setup
transaction" and "funding transaction", also named T_{u,0} without
showing it in the diagrams.

In 3.1 the funding transaction is described as funding "to a multisig
address". In the description of trigger transactions the change is
described as "The output from the setup transaction is changed into a
simple 2-of-2 multisig output" - which it already is?

As far as I understand the situation, the the trigger transaction is
needed because the broadcasted initial/funding/setup transaction
includes an OP_CLV (possibly enforcing premature settlement). Removing
OP_CLV, i.e. by changing it to a simple multisig output, seems to solve
this issue.

Could you (Christian?) explain how the "setup transaction" is supposed
to look like without the changes described in section 4.2?

I like the idea proposed by ZmnSCPxj, but I'm not able to weigh the
pro/cons of both approaches. For a direct unilateral close both peers
would need to know the first update transaction and an attached
settlement transaction, which is comparable to the approach presented in
the paper (trigger transaction and settlement transaction).

The main advantage of getting rid of the trigger transaction seems to be
that only two transactions (latest update and settlement) have to be
committed to the blockchain in the unilateral case, compared to three
(trigger, latest update, settlement) in the approach presented in the

andrena objects ag
Ganghoferstraße 70
80339 München


Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger

Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824

Bitte beachten Sie auch unsere anstehenden Veranstaltungen:

Attachment: signature.asc
Description: PGP signature

Lightning-dev mailing list

Reply via email to