{"type":"rich","version":"1.0","author_name":"npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9","author_url":"https://nostr.ae/npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-12-20\n📝 Original message:\u003e On 20 Dec 2018, at 6:09 AM, Christian Decker \u003cdecker.christian at gmail.com\u003e wrote:\n\u003e \n\u003e Ruben Somsen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e\n\u003e writes:\n\u003e \n\u003e\u003e Hi Johnson,\n\u003e\u003e \n\u003e\u003e The design considerations here seem similar to the ML discussion of\n\u003e\u003e whether Graftroot should be optional [1].\n\u003e\u003e \n\u003e\u003e\u003e While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?\n\u003e\u003e \n\u003e\u003e As far as I can tell it should be compatible with Statechains [2],\n\u003e\u003e since it pretty much mirrors Eltoo in setup.\n\u003e\u003e \n\u003e\u003e My understanding is somewhat lacking, so perhaps I am missing the\n\u003e\u003e mark, but it is not completely clear to me how this affects\n\u003e\u003e fungibility if taproot gets added and the setup and trigger tx for\n\u003e\u003e Eltoo get combined into a single transaction. Would the NOINPUT\n\u003e\u003e spending condition be hidden inside the taproot commitment?\n\u003e \n\u003e I'm not aware of a way to combine the setup and trigger transaction. The\n\u003e trigger transaction was introduced in order to delay the start of the\n\u003e timeouts until a later time, to avoid having an absolute lifetime limit\n\u003e and having really huge timeout. If we were to combine the trigger\n\u003e transaction with the setup transaction (which is broadcast during\n\u003e channel creation), all of those timeouts would start counting down\n\u003e immediately, and we could just skip the trigger transaction\n\u003e altogether. It'd be more interesting to combine update and trigger\n\u003e transactions in a sort of cut-through combination, but that doesn't seem\n\u003e possible outside of Mimblewimble.\n\u003e \n\u003e Cheers,\n\u003e Christian\n\n\nCorrect me if I’m wrong.\n\nFor the sake of simplicity, in the following I assume BIP118, 143, and 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible optimisations.\n\n1. A and B are going to setup a channel.\n\n2. They create one setup tx, with a setup output of the following script: \u003cs\u003e CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign\n\n3. They create the update tx 0, spending the setup output with NOINPUT and locktime = s+1, to the update-0 output with the script:\nIF 2 As0 Bs0 2 CHECKMULTISIG ELSE \u003cs+1\u003e CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF\n\n4. They create the settlement tx 0, spending the update-0 output with As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs\n\n5. They sign the setup tx and let it confirm\n\n6. To update, they create the update tx 1, spending the setup output with NOINPUT and locktime = s+2, to the update-1 output with the script:\nIF 2 As1 Bs1 2 CHECKMULTISIG ELSE \u003cs+2\u003e CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF\nand create the settlement tx 1, spending the update-1 output with As1 and Bs1 using relative-locktime, with 2 settlement outputs\n\n7. To close the channel, broadcast update tx 1. Wait for several confirmations. And broadcast settlement-tx-1\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181220/4c9d8779/attachment-0001.html\u003e"}