<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'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"><<a href="mailto:joseph@lightning.network" target="_blank">joseph@lightning.network</a>></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's possible to<br>
achieve this compactness without using OP_CODESEPARATOR.<br>
<br>
Side note: It's necessary to disclose temporary private keys (instead of<br>
signatures) under this mechanism, since it'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>
<PubkeyAlice> OP_CHECKSIG<br>
OP_NOTIF<br>
<CSVDelay> OP_DROP OP_CSV<br>
OP_ENDIF<br>
<PubkeyBob><br>
OP_CHECKSIG<br>
<br>
On the other hand, if Alice broadcasted it, her script could be:<br>
<PubkeyBob> OP_CHECKSIG<br>
OP_NOTIF<br>
<CSVDelay> OP_DROP OP_CSV<br>
OP_ENDIF<br>
<PubkeyAlice><br>
OP_CHECKSIG<br>
<br>
Alice successful redemption of her broadcast would be:<br>
(after one week)<br>
<AliceSig> <0><br>
<br>
Bob's penalty transaction on Alice's broadcast would be:<br>
<AliceSig> <BobSig><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'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'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>