<div dir="ltr">I am catching up with the latest dev of lightning.<div>I thought you wanted SIGHASH_NOPINPUT in order</div><div>to fix the problem of storage requirement.</div><div><br></div><div>I have not thought about using private key on HD.</div><div>However, I think the index (also used for derivation)</div><div>of the commitment would need to be stored in the</div><div>transaction. </div><div>So if Bob notice old commitment, he does not have </div><div>to bruteforce what was the key he used.</div><div><br></div><div>I re-read slowly your post on bitcoin-dev about</div><div>SIGHASH_NOINPUT, and noticed the problem it </div><div>was to fix was for third party monitoring.</div><div><br></div><div>But that the linear storage of the channel participant</div><div>was a problem already solved. I&#39;m synching. :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 11:56 AM, Joseph Poon <span dir="ltr">&lt;<a href="mailto:joseph@lightning.network" target="_blank">joseph@lightning.network</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nicolas,<br>
<br>
Yes, I do think exploring using signatures as a method of revocation is<br>
interesting! For revoking Commitments, I believe if you did disclosure<br>
of the private-key as a method of revocation, then it&#39;s possible to<br>
achieve this compactness without using OP_CODESEPARATOR.<br>
<br>
Side note: It&#39;s necessary to disclose temporary private keys (instead of<br>
signatures) under this mechanism, since it&#39;s possible to compactly store<br>
the keys by making it derived from a tree or chain of hash functions.<br>
<br>
A compact revocable example for Bob to broadcast could be:<br>
&lt;PubkeyAlice&gt; OP_CHECKSIG<br>
OP_NOTIF<br>
        &lt;CSVDelay&gt; OP_DROP OP_CSV<br>
OP_ENDIF<br>
&lt;PubkeyBob&gt;<br>
OP_CHECKSIG<br>
<br>
On the other hand, if Alice broadcasted it, her script could be:<br>
&lt;PubkeyBob&gt; OP_CHECKSIG<br>
OP_NOTIF<br>
        &lt;CSVDelay&gt; OP_DROP OP_CSV<br>
OP_ENDIF<br>
&lt;PubkeyAlice&gt;<br>
OP_CHECKSIG<br>
<br>
Alice successful redemption of her broadcast would be:<br>
(after one week)<br>
&lt;AliceSig&gt; &lt;0&gt;<br>
<br>
Bob&#39;s penalty transaction on Alice&#39;s broadcast would be:<br>
&lt;AliceSig&gt; &lt;BobSig&gt;<br>
<br>
If Alice did not broadcast the correct Commitment, Bob can take the<br>
money immediately because she disclosed her private key when creating<br>
the new Commitment transaction, so Bob has both PrivkeyBob and<br>
PrivkeyAlice. If Alice correctly broadcast the most recent Commitment,<br>
Bob does not have PrivkeyAlice so he cannot take the funds, but Alice<br>
does not have PrivkeyBob so she has to wait for the CSV delay.<br>
<br>
If the goal is to save space, it saves a little in the<br>
timeout/non-penalty case, but the transactions are larger for penalty<br>
cases (although they may be less frequent).<br>
<br>
It&#39;s also possible to make it just a multisig output with the child<br>
transaction spending from it pre-signed as well using nSequence, but<br>
that requires more storage and more on-chain transactions (while saving<br>
in the script output size), this design is not necessary for this<br>
particular instance if there&#39;s OP_CSV.<br>
<br>
As a side note, OP_CODESEPARATOR may become useful if there is<br>
SIGHASH_NOINPUT inside segregated witness in the future, by being able<br>
to have one signature be able to apply towards multiple types of<br>
transactions (e.g. different redeemScript/scriptPubKey r-values or<br>
pubkeys).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Joseph Poon<br>
</font></span></blockquote></div><br></div>