<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">On 17 Dec 2018, at 11:48 PM, Ruben Somsen <<a href="mailto:rsomsen@gmail.com" class="">rsomsen@gmail.com</a>> wrote:<br class=""><br class="">Hi Johnson,<br class=""><br class="">The design considerations here seem similar to the ML discussion of<br class="">whether Graftroot should be optional [1].<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Yes, but the “tagging” emphasises more on the payer’s side: if the payer cannot guarantee that the payee would never reuse the key, the payer could avoid any NOINPUT-related trouble by tagging properly.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""><blockquote type="cite" class="">While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?<br class=""></blockquote><br class="">As far as I can tell it should be compatible with Statechains [2],<br class="">since it pretty much mirrors Eltoo in setup.<br class=""><br class="">My understanding is somewhat lacking, so perhaps I am missing the<br class="">mark, but it is not completely clear to me how this affects<br class="">fungibility if taproot gets added and the setup and trigger tx for<br class="">Eltoo get combined into a single transaction. Would the NOINPUT<br class="">spending condition be hidden inside the taproot commitment?<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">For the design considerations I mentioned above, the tags must be explicit and configurable by the payer. So it couldn’t be hidden in taproot.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">If you don’t care about fungibility, you can always tag your setup output, and makes it ready for NOINPUT spending. Every update will need 2 signatures: a NOINPUT to spend the setup output or an earlier update output, and a NOINPUT to settle the latest update output.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">If you care about fungibility, you can’t tag your setup output. Every update will need 3 signatures: a SINGLEINPUT (aka ANYONECANPAY) to spend the setup output, a NOINPUT to spend an earlier update output, and a NOINPUT to settle the latest update output.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">(Actually, as soon as you made the first update tx with SINGLEINPUT, you don’t strictly need to make any SINGLEINPUT signatures in the later updates again, as the first update tx (or any update with a SINGLEINPUT signature) could be effectively the trigger tx. While it makes the settlement more expensive, it also means accidentally missing a SINGLEINPUT signature will not lead to any fund loss. So security-wise it’s same as the always-tagging scenario.)</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">The most interesting observation is: you never have the need to use NOINPUT on an already confirmed UTXO, since nothing about a confirmed UTXO is mutable. And every smart contract must anchor to a confirmed UTXO, or the whole contract is double-spendable. So the ability to NOINPUT-spend a setup output should not be strictly needed. In some (but not all) case it might make the protocol simpler, though.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">So the philosophy behind output tagging is “avoid NOINPUT at all cost, until it is truly unavoidable"</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote></div><br class=""><div class="">After thinking more carefully, I believe output tagging could have no adverse effect on eltoo.</div><div class=""><br class=""></div><div class="">Consider a system without tagging, where you could always spend an output with NOINPUT. Under taproot, state update could be made in 2 ways:</div><div class=""><br class=""></div><div class="">a) Making 2 sigs for each update. One sig is a “script path” locktime NOINPUT spending of the setup output or an earlier update output. One sig is a “key path” relative-locktime NOINPUT spending of the new update output. In taproot terminology, “key path” means direct spending with the scriptPubKey, and “script path” means revealing the script hidden in taproot. Key path spending is always cheaper.</div><div class=""><br class=""></div><div class="">b) Making 3 sigs for each update. One sig is a key path SINGLEINPUT (aka ANYONECANPAY) or NOINPUT spending of the setup output, without any locktime. One sig is a script path locktime NOINPUT spending of an earlier update output (if this is not the first update). One sig is a key path relative-locktime NOINPUT spending of the new update output</div><div class=""><br class=""></div><div class="">Note that in b), the first signature could be either SINGLEINPUT or NOINPUT, and they just work as fine. So SINGLEINPUT should be used to avoid unnecessary replayability.</div><div class=""><br class=""></div><div class="">In the case of uncooperative channel closing, b) is always cheaper than a), since this first broadcast signature will be a key path signature. Also, b) has better privacy if no one is cheating (only the last update is broadcast). The only information leaked in b) is the use of SINGLEINPUT and the subsequent relative-locktime NOINPUT. However, the script path signature in a) will leak the state number, which is the maximum number of updates made in this channel.</div><div class=""><br class=""></div><div class="">In conclusion, b) is cheaper and more private, but it is more complex by requiring 3 sigs per update rather than 2. I think it is an acceptable tradeoff. (And as I mentioned in my last mail, missing some SINGLEINPUT sigs is not the end of the world. As long as you find one SINGLEINPUT sig in your backup, it safely falls back to the trigger tx model)</div><div class=""><br class=""></div><div class="">What if we require output tagging? For privacy reason you shouldn’t tag your setup tx, so the setup output could not be spent with NOINPUT. Option a) doesn’t work, but b) only requires SINGLEINPUT and has no problem. So in a fee-minimising and privacy-maximising eltoo design, output tagging should have no adverse effect.</div></body></html>