rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 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