Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-03 📝 Original message: Carsten Otto ...
📅 Original date posted:2018-05-03
📝 Original message:
Carsten Otto <carsten.otto at andrena.de> writes:
> 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.
The setup transaction is simply a transaction that spends some funds and
creates a single output, which has the script from Figure 2, but since
that would be a forward reference, I decided to handwave and call it a
multisig. A simple fix would be to change the setup phase bullet point
at the beginning of section 3, would that be sufficient?
> 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?
If instead of calling it a multisig we call it a multiparty output and
reference the script in Figure 2, that'd be addressed as well.
> 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?
Well, it has arbitrary inputs, and a single output with the script from
Figure 2, in the non-trigger case, and in the trigger case it'd be just
a `2 A B 2 OP_CMSV`.
Published at
2023-06-09 12:50:21Event JSON
{
"id": "39c1fc91700e3e077f6b8bc09218b14c2afe653cfaed6d5b33b594dc87e4a827",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315021,
"kind": 1,
"tags": [
[
"e",
"8810a687a398ff4253aa82a57b227d1be6d62119c3d2aac97b46109ae04c407a",
"",
"root"
],
[
"e",
"8f66e689ed6020eb5c7b00e6f961ca764042c6b5d600ea7003913986bf53a2b8",
"",
"reply"
],
[
"p",
"8a718cc163bd0c956b748cfd134e84f90a27d5fdaccac045fbc8e7693f0080b8"
]
],
"content": "📅 Original date posted:2018-05-03\n📝 Original message:\nCarsten Otto \u003ccarsten.otto at andrena.de\u003e writes:\n\u003e the paper is a bit confusing regarding the setup transaction, as it is\n\u003e not described formally. There also seems to be a mixup of \"setup\n\u003e transaction\" and \"funding transaction\", also named T_{u,0} without\n\u003e showing it in the diagrams.\n\nThe setup transaction is simply a transaction that spends some funds and\ncreates a single output, which has the script from Figure 2, but since\nthat would be a forward reference, I decided to handwave and call it a\nmultisig. A simple fix would be to change the setup phase bullet point\nat the beginning of section 3, would that be sufficient?\n\n\u003e In 3.1 the funding transaction is described as funding \"to a multisig\n\u003e address\". In the description of trigger transactions the change is\n\u003e described as \"The output from the setup transaction is changed into a\n\u003e simple 2-of-2 multisig output\" - which it already is?\n\nIf instead of calling it a multisig we call it a multiparty output and\nreference the script in Figure 2, that'd be addressed as well.\n\n\u003e As far as I understand the situation, the trigger transaction is needed\n\u003e because the broadcasted initial/funding/setup transaction includes an\n\u003e OP_CLV, which then starts the timer and could lead to premature\n\u003e settlement. Removing OP_CLV (and having in a transaction that is only\n\u003e published later when it is needed), i.e. by changing it to a simple\n\u003e multisig output, seems to solve this issue.\n\u003e\n\u003e Could you (Christian?) explain how the \"setup transaction\" is supposed\n\u003e to look like without the changes described in section 4.2?\n\nWell, it has arbitrary inputs, and a single output with the script from\nFigure 2, in the non-trigger case, and in the trigger case it'd be just\na `2 A B 2 OP_CMSV`.",
"sig": "587ce820b4167717c3d879b9e9fc870dc7ad7064c2d93997a0e8166646a6022d20936026a610e37c75a296a2c1169e602636ef4727fd3da36175a8200471b769"
}