📅 Original date posted:2018-05-03
📝 Original message:
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 trigger transaction is needed
because the broadcasted initial/funding/setup transaction includes an
OP_CLV, which then starts the timer and could lead to premature
settlement. Removing OP_CLV (and having in a transaction that is only
published later when it is needed), 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
paper. As a minor advantage the peers do not need to remember the
trigger transaction.
Bye,
Carsten
--
andrena objects ag
Ganghoferstraße 70
80339 München
http://www.andrena.de
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:
http://www.andrena.de/events
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180503/118d50e1/attachment.sig>;
Carsten Otto [ARCHIVE] /
npub13f…tgaqs
2023-06-09 12:50:21
in reply to nevent1q…pr9n
Author Public Key
npub13fccestrh5xf26m53n73xn5yly9z040a4n9vq30mernkj0cqszuq9tgaqsPublished at
2023-06-09 12:50:21Event JSON
{
"id": "8f66e689ed6020eb5c7b00e6f961ca764042c6b5d600ea7003913986bf53a2b8",
"pubkey": "8a718cc163bd0c956b748cfd134e84f90a27d5fdaccac045fbc8e7693f0080b8",
"created_at": 1686315021,
"kind": 1,
"tags": [
[
"e",
"8810a687a398ff4253aa82a57b227d1be6d62119c3d2aac97b46109ae04c407a",
"",
"root"
],
[
"e",
"37dcfd28a6c17d1183b2c500beb615aed2b8deb0b76641fc693570bb6b1960cf",
"",
"reply"
],
[
"p",
"8a718cc163bd0c956b748cfd134e84f90a27d5fdaccac045fbc8e7693f0080b8"
]
],
"content": "📅 Original date posted:2018-05-03\n📝 Original message:\nHi ZmnSCPxj, Christian, list,\n\nthe paper is a bit confusing regarding the setup transaction, as it is\nnot described formally. There also seems to be a mixup of \"setup\ntransaction\" and \"funding transaction\", also named T_{u,0} without\nshowing it in the diagrams.\n\nIn 3.1 the funding transaction is described as funding \"to a multisig\naddress\". In the description of trigger transactions the change is\ndescribed as \"The output from the setup transaction is changed into a\nsimple 2-of-2 multisig output\" - which it already is?\n\nAs far as I understand the situation, the trigger transaction is needed\nbecause the broadcasted initial/funding/setup transaction includes an\nOP_CLV, which then starts the timer and could lead to premature\nsettlement. Removing OP_CLV (and having in a transaction that is only\npublished later when it is needed), i.e. by changing it to a simple\nmultisig output, seems to solve this issue.\n\nCould you (Christian?) explain how the \"setup transaction\" is supposed\nto look like without the changes described in section 4.2?\n\nI like the idea proposed by ZmnSCPxj, but I'm not able to weigh the\npro/cons of both approaches. For a direct unilateral close both peers\nwould need to know the first update transaction and an attached\nsettlement transaction, which is comparable to the approach presented in\nthe paper (trigger transaction and settlement transaction).\n\nThe main advantage of getting rid of the trigger transaction seems to be\nthat only two transactions (latest update and settlement) have to be\ncommitted to the blockchain in the unilateral case, compared to three\n(trigger, latest update, settlement) in the approach presented in the\npaper. As a minor advantage the peers do not need to remember the\ntrigger transaction.\n\nBye,\nCarsten\n-- \nandrena objects ag\nGanghoferstraße 70\n80339 München\n\nhttp://www.andrena.de\n\nVorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle\nAufsichtsratsvorsitzender: Rolf Hetzelberger\n\nSitz der Gesellschaft: Karlsruhe\nAmtsgericht Mannheim, HRB 109694\nUSt-IdNr. DE174314824\n\nBitte beachten Sie auch unsere anstehenden Veranstaltungen:\nhttp://www.andrena.de/events\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 195 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180503/118d50e1/attachment.sig\u003e",
"sig": "c574c3a0c07bde474be632a7b4f8794046ee0239b3bee74c6a7e08976c20de9d22b46a74568734c89d7d302b6b920a7ebb955f79ff940825d0d68122c3aa79c9"
}