<div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"></div><br><br>&gt; * I do not think CoinJoin is much improved by this opcode.<br><div>&gt;   Typically, you would sign off only if one of the outputs of the CoinJoin transaction is yours, and this does not really improve this situation.</div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Coinjoin benefits a lot I think.</div><br></div><br><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Coinjoin is improved because you can fit more users into the protocol and create many more outputs at lower cost or include more participants. Ideally a coinjoin creates a lot of outputs so that the ownership is smeared more, but this has a cost at the time of the coinjoin.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Coinjoin is also improved because you don&#39;t reveal the outputs created by the coinjoin until some time, perhaps very far in the future, when you need the coin. In fact, you only need to reveal where you&#39;re moving the coins to participants in your subtree because participants need only verify their branch.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">It also makes the protocol more stable with respect to input choice. This is because, similar to how NOINPUT may work, OP_COSHV outputs are spendable without knowing what the TXID will be. Therefore if someone changes their input or non segwit spend script, it won&#39;t break the presigned txns. This also means that all the inputs can be ANYONECANPAY, so there is no need to reveal your inputs before anyone else.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">This culminates in being able to open channels from a coinjoin safely, I believe this is difficult/impossible to do currently.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div><br></div><br>&gt; * Using this for congestion control increases blockchain usage by one TXO and one input, ending up with *more* bytes onchain, and a UTXO that will be removed later in (we hope) short time.<br><div>&gt;   I do not know if this is a good idea, to increase congestion by making unnecessary intermediate transaction outputs, at times when congestion is a problem.</div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">This is a good idea because it improves QoS for most users.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">For receiving money pending spendable but confirmed payment (i.e. certified checks) is superior to having unconfirmed funds.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">For sending money, being able to clear all liabilities in a single txn decreases business exposure to fee variance and confirmation time variance. E.g., if I&#39;m doing payroll in Bitcoin I will pay big fines if I am a day late. If I have 10,000 employees this might be painful if fees are currently up.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">It also helps to have a backlog of low priority txns to support the fee market.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Overall block bandwidth utilization is fairly spikey, so having long term well known outputs that are not time sensitive can be used to better utilize bandwidth.<br></div></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">The total extra bandwidth btw is really small given the expansion factor optimizations available.</div><br></div><br>&gt; * I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain update mechanism) on top of this opcode, so I cannot support replacing `SIGHASH_NOINPUT` with this opcode.<br><div>&gt;   In particular, while the finite loop support by this opcode appears (at first glance) to be useable as the &quot;stepper&quot; for an offchain update mechanism, I cannot find a good way to short-circuit the transaction chain without `SIGHASH_NOINPUT` anyway.</div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">I&#39;m not deeply familiar with DRO channels. This opcode isn&#39;t a replacement for SIGHASH_NOINPUT -- SIGHASH_NOINPUT is mentioned merely to contrast using SIGHASH_NOINPUT for the uses presented in this BIP. </div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Lastly there&#39;s no &#39;replacing&#39;. Neither NOINPUT nor COSHV are accepted by the community at large yet, and they do different things.<br></div><br></div><div><br></div>&gt; * Channel factories created by this opcode do not, by themselves, support updates to the channel structure.<br><div>&gt;   But such simple &quot;close only&quot; channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign in order to enter the factory).</div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">I&#39;m not really an expert at Bitcoin Lightning, but this basic mechanism should work. </div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Imagine the script at a leaf node:<br></div></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Taproot([Alice, Bob], [OP_COSHV &lt;H(H(2 coins to uncooperative script))&gt;]<br></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">where uncooperative script is:</div><br><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span>Taproot([Alice, Bob], [&quot;<span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1 week</span>&quot; CHECKSEQUENCEVERIFY DROP<span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"> </span>OP_COSHV &lt;H(H(Pay alice <span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2 coins</span>))&gt;<span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">)</span></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Cooperative closing skips the extra transactions. Updates are signed against the uncooperative script with repudation. E.g.:</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div>    HASH160 &lt;revokehash&gt; EQUAL<br>    IF<br>        &lt;Bob&#39;s pubkey&gt;<br>    ELSE<br>        &quot;<span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1 week</span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span>&quot; CHECKSEQUENCEVERIFY DROP<br>        &lt;Alice&#39;s pubkey&gt;<br>    ENDIF<br>    CHECKSIG<div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">It can even be optimized by letting the uncooperative script branches in the leaf be blaming Alice or Bob.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">Does that not work?<br></div><br></div></div>