Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-08 📝 Original message: I am catching up with the ...
📅 Original date posted:2016-03-08
📝 Original message:
I am catching up with the latest dev of lightning.
I thought you wanted SIGHASH_NOPINPUT in order
to fix the problem of storage requirement.
I have not thought about using private key on HD.
However, I think the index (also used for derivation)
of the commitment would need to be stored in the
transaction.
So if Bob notice old commitment, he does not have
to bruteforce what was the key he used.
I re-read slowly your post on bitcoin-dev about
SIGHASH_NOINPUT, and noticed the problem it
was to fix was for third party monitoring.
But that the linear storage of the channel participant
was a problem already solved. I'm synching. :)
On Tue, Mar 8, 2016 at 11:56 AM, Joseph Poon <joseph at lightning.network>
wrote:
> Hi Nicolas,
>
> Yes, I do think exploring using signatures as a method of revocation is
> interesting! For revoking Commitments, I believe if you did disclosure
> of the private-key as a method of revocation, then it's possible to
> achieve this compactness without using OP_CODESEPARATOR.
>
> Side note: It's necessary to disclose temporary private keys (instead of
> signatures) under this mechanism, since it's possible to compactly store
> the keys by making it derived from a tree or chain of hash functions.
>
> A compact revocable example for Bob to broadcast could be:
> <PubkeyAlice> OP_CHECKSIG
> OP_NOTIF
> <CSVDelay> OP_DROP OP_CSV
> OP_ENDIF
> <PubkeyBob>
> OP_CHECKSIG
>
> On the other hand, if Alice broadcasted it, her script could be:
> <PubkeyBob> OP_CHECKSIG
> OP_NOTIF
> <CSVDelay> OP_DROP OP_CSV
> OP_ENDIF
> <PubkeyAlice>
> OP_CHECKSIG
>
> Alice successful redemption of her broadcast would be:
> (after one week)
> <AliceSig> <0>
>
> Bob's penalty transaction on Alice's broadcast would be:
> <AliceSig> <BobSig>
>
> If Alice did not broadcast the correct Commitment, Bob can take the
> money immediately because she disclosed her private key when creating
> the new Commitment transaction, so Bob has both PrivkeyBob and
> PrivkeyAlice. If Alice correctly broadcast the most recent Commitment,
> Bob does not have PrivkeyAlice so he cannot take the funds, but Alice
> does not have PrivkeyBob so she has to wait for the CSV delay.
>
> If the goal is to save space, it saves a little in the
> timeout/non-penalty case, but the transactions are larger for penalty
> cases (although they may be less frequent).
>
> It's also possible to make it just a multisig output with the child
> transaction spending from it pre-signed as well using nSequence, but
> that requires more storage and more on-chain transactions (while saving
> in the script output size), this design is not necessary for this
> particular instance if there's OP_CSV.
>
> As a side note, OP_CODESEPARATOR may become useful if there is
> SIGHASH_NOINPUT inside segregated witness in the future, by being able
> to have one signature be able to apply towards multiple types of
> transactions (e.g. different redeemScript/scriptPubKey r-values or
> pubkeys).
>
> --
> Joseph Poon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/27be3571/attachment-0001.html>;
📝 Original message:
I am catching up with the latest dev of lightning.
I thought you wanted SIGHASH_NOPINPUT in order
to fix the problem of storage requirement.
I have not thought about using private key on HD.
However, I think the index (also used for derivation)
of the commitment would need to be stored in the
transaction.
So if Bob notice old commitment, he does not have
to bruteforce what was the key he used.
I re-read slowly your post on bitcoin-dev about
SIGHASH_NOINPUT, and noticed the problem it
was to fix was for third party monitoring.
But that the linear storage of the channel participant
was a problem already solved. I'm synching. :)
On Tue, Mar 8, 2016 at 11:56 AM, Joseph Poon <joseph at lightning.network>
wrote:
> Hi Nicolas,
>
> Yes, I do think exploring using signatures as a method of revocation is
> interesting! For revoking Commitments, I believe if you did disclosure
> of the private-key as a method of revocation, then it's possible to
> achieve this compactness without using OP_CODESEPARATOR.
>
> Side note: It's necessary to disclose temporary private keys (instead of
> signatures) under this mechanism, since it's possible to compactly store
> the keys by making it derived from a tree or chain of hash functions.
>
> A compact revocable example for Bob to broadcast could be:
> <PubkeyAlice> OP_CHECKSIG
> OP_NOTIF
> <CSVDelay> OP_DROP OP_CSV
> OP_ENDIF
> <PubkeyBob>
> OP_CHECKSIG
>
> On the other hand, if Alice broadcasted it, her script could be:
> <PubkeyBob> OP_CHECKSIG
> OP_NOTIF
> <CSVDelay> OP_DROP OP_CSV
> OP_ENDIF
> <PubkeyAlice>
> OP_CHECKSIG
>
> Alice successful redemption of her broadcast would be:
> (after one week)
> <AliceSig> <0>
>
> Bob's penalty transaction on Alice's broadcast would be:
> <AliceSig> <BobSig>
>
> If Alice did not broadcast the correct Commitment, Bob can take the
> money immediately because she disclosed her private key when creating
> the new Commitment transaction, so Bob has both PrivkeyBob and
> PrivkeyAlice. If Alice correctly broadcast the most recent Commitment,
> Bob does not have PrivkeyAlice so he cannot take the funds, but Alice
> does not have PrivkeyBob so she has to wait for the CSV delay.
>
> If the goal is to save space, it saves a little in the
> timeout/non-penalty case, but the transactions are larger for penalty
> cases (although they may be less frequent).
>
> It's also possible to make it just a multisig output with the child
> transaction spending from it pre-signed as well using nSequence, but
> that requires more storage and more on-chain transactions (while saving
> in the script output size), this design is not necessary for this
> particular instance if there's OP_CSV.
>
> As a side note, OP_CODESEPARATOR may become useful if there is
> SIGHASH_NOINPUT inside segregated witness in the future, by being able
> to have one signature be able to apply towards multiple types of
> transactions (e.g. different redeemScript/scriptPubKey r-values or
> pubkeys).
>
> --
> Joseph Poon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/27be3571/attachment-0001.html>;