<div>Good morning Conner,<br></div><div><br></div><div>I have an insane idea.<br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><p><br></p><p class="inbox-inbox-p1"><br></p><div><span class="inbox-inbox-s1">One minimal&nbsp;</span>solution could be to send signatures for independent sweep<br></div><div>transactions, allowing&nbsp;<span class="inbox-inbox-s1">the watchtower to sweep each </span><span class="inbox-inbox-s2">HTLC</span><span class="inbox-inbox-s1"> output individually.<br>This is nice because it&nbsp;permits the watchtower to sweep exactly the subset of<br></span><span class="inbox-inbox-s2">HTLCs</span><span class="inbox-inbox-s1"> that ever transition&nbsp;into the second stage, and under any permutation<br></span><span class="inbox-inbox-s2">wrt</span><span class="inbox-inbox-s1">. </span><span class="inbox-inbox-s2">ordering&nbsp;</span>of confirmed second stage transactions.</div><p><br></p><p class="inbox-inbox-p1"><br></p><div><span class="inbox-inbox-s1">With the single transaction per&nbsp;</span><span class="inbox-inbox-s2">HTLC</span><span class="inbox-inbox-s1"> approach, the total number of signatures that<br>are sent to the watchtower remains linear in the number </span><span class="inbox-inbox-s2">HTLCs</span><span class="inbox-inbox-s1"> on the commitment<br></span>transaction. This approach does have the downside of consuming slightly more</div><div>fees, since each output is swept with a distinct transaction.<br></div></div></blockquote><div><br></div>I consider the idea, to take this even further.&nbsp; Why have one blob contain data for multiple justice transactions?&nbsp; Since the WatchTower will make multiple justice transactions for each outpoint of the revoked commitment transaction, why not make it one-blob-one-justice?<br><br>Currently our basic idea is that a single blob is keyed to the revoked commitment txid, and contains how to claim the main outputs, and all the second-stage HTLCs from that commitment txid.<br><br>But I observe, that on the revoked commitment txid, there is exactly one output that needs to be claimed in a timely manner, and that is the output that goes to the stealing node.&nbsp; The output that goes to the protected node is safe, and if the second stage of the HTLC outputs are not yet claimed, those outputs are also safe.<br><br>And on the second-stage HTLC (HTLC-success or HTLC-timeout), there is also exactly one output that needs to be claimed in a timely manner.<br><br>So I consider the idea, that we create (txid[:16], blob) pairs for the commitment transaction, and separate (txid[:16], blob) pairs for each second-stage HTLC transaction, and upload all this to the WatchTower.<br><br>Each blob then only contains, encrypted:<br><br>1.&nbsp; The outnum on the tx being watched for.<br>2.&nbsp; The witness stack (signature plus witness script).<br>3.&nbsp; The scriptpubkey to pay out to.<br><br>We could pad this so that the witness stack size does not leak whether the tx being watched is a revoked commitment transaction or a revoked HTLC-success or HTLC-timeout transaction, and also some extra padding so that if we add more possible transactions to watch (or Bitcoin makes some excessively long standard scriptpubkey), we have some space to expand into.<br><br>This greatly simplifies WatchTower construction, as justice transactions it has to synthesize are simple one-input, one-output transactions (or possibly two-output, with the other output being the WatchTower bounty; perhaps the revoking signature on the witness stack could be SIGHASH_SINGLE (is that safe???) and the first output goes to the protected node, with the rest of the value split between the WatchTower and the mining fee, and the justice transaction opt-in RBF, so that the WatchTower can balance between remaining CSV timelock available and mining fees; this would also allow the same blob to be given to different WatchTowers, for even more insurance).<br><div><br></div><div>We could possibly move the outnum outside the blob, and have (txid[:16], outnum, blob), with the key for lookup being (txid[:16], outnum), so that a single monitored transaction can trigger multiple justice transactions for each outnum given.&nbsp; This has the advantage that even if we completely change channel commitment structure, and the contracts we transport over channels (e.g. to support discreet log contracts), there will be no need to change existing WatchTowers: we always specify the entire witness stack of the justice transaction and the output of the justice transaction, and can freely change it.&nbsp; Whether this is a big enough advantage, I do not know.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>