📅 Original date posted:2018-12-19
📝 Original message:Ruben Somsen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> Hi Johnson,
>
> The design considerations here seem similar to the ML discussion of
> whether Graftroot should be optional [1].
>
>>While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>
> As far as I can tell it should be compatible with Statechains [2],
> since it pretty much mirrors Eltoo in setup.
>
> My understanding is somewhat lacking, so perhaps I am missing the
> mark, but it is not completely clear to me how this affects
> fungibility if taproot gets added and the setup and trigger tx for
> Eltoo get combined into a single transaction. Would the NOINPUT
> spending condition be hidden inside the taproot commitment?
I'm not aware of a way to combine the setup and trigger transaction. The
trigger transaction was introduced in order to delay the start of the
timeouts until a later time, to avoid having an absolute lifetime limit
and having really huge timeout. If we were to combine the trigger
transaction with the setup transaction (which is broadcast during
channel creation), all of those timeouts would start counting down
immediately, and we could just skip the trigger transaction
altogether. It'd be more interesting to combine update and trigger
transactions in a sort of cut-through combination, but that doesn't seem
possible outside of Mimblewimble.
Cheers,
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 18:15:44
in reply to nevent1q…wkz9
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 18:15:44Event JSON
{
"id": "25ec14eb6ded45e23e6c84a2fd02b2c6074aabdafe67511c0b4327d49b1c5f2e",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686161744,
"kind": 1,
"tags": [
[
"e",
"f6eafb725e9193cb9f6572435a7ea1dfee1c129eae53a74d28a60bc4e59ff9f2",
"",
"root"
],
[
"e",
"6db8a849e729fb3c380589e4792b92fced534f208f64058359cefe3470fc6f1c",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2018-12-19\n📝 Original message:Ruben Somsen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nwrites:\n\n\u003e Hi Johnson,\n\u003e\n\u003e The design considerations here seem similar to the ML discussion of\n\u003e whether Graftroot should be optional [1].\n\u003e\n\u003e\u003eWhile this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?\n\u003e\n\u003e As far as I can tell it should be compatible with Statechains [2],\n\u003e since it pretty much mirrors Eltoo in setup.\n\u003e\n\u003e My understanding is somewhat lacking, so perhaps I am missing the\n\u003e mark, but it is not completely clear to me how this affects\n\u003e fungibility if taproot gets added and the setup and trigger tx for\n\u003e Eltoo get combined into a single transaction. Would the NOINPUT\n\u003e spending condition be hidden inside the taproot commitment?\n\nI'm not aware of a way to combine the setup and trigger transaction. The\ntrigger transaction was introduced in order to delay the start of the\ntimeouts until a later time, to avoid having an absolute lifetime limit\nand having really huge timeout. If we were to combine the trigger\ntransaction with the setup transaction (which is broadcast during\nchannel creation), all of those timeouts would start counting down\nimmediately, and we could just skip the trigger transaction\naltogether. It'd be more interesting to combine update and trigger\ntransactions in a sort of cut-through combination, but that doesn't seem\npossible outside of Mimblewimble.\n\nCheers,\nChristian",
"sig": "81d60d7d07b5bf53588235fd5fa55dbb1141554c45ff9ff3084d931a8c55455412f9a909d47db656bcd8ff77fe49cd62c605a5f3f1127dd72c4ebecd913705d9"
}