📅 Original date posted:2016-03-08
📝 Original message:
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
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:45:51
in reply to nevent1q…p2zu
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:45:51Event JSON
{
"id": "0138405d8ee0bdabe9ae41f8ff99e781073f9e80396c94d02bd74b9754ce88c1",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314751,
"kind": 1,
"tags": [
[
"e",
"9dffd851f36e0464b9b84a18f034d9a166bd96caa924994430620e4b51393055",
"",
"root"
],
[
"e",
"62adbcedc7ddb4f81a4a000b3cf42c176db9cff6d43b09cffbf0281bfc9afc40",
"",
"reply"
],
[
"p",
"bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57"
]
],
"content": "📅 Original date posted:2016-03-08\n📝 Original message:\nHi Nicolas,\n\nYes, I do think exploring using signatures as a method of revocation is\ninteresting! For revoking Commitments, I believe if you did disclosure\nof the private-key as a method of revocation, then it's possible to\nachieve this compactness without using OP_CODESEPARATOR.\n\nSide note: It's necessary to disclose temporary private keys (instead of\nsignatures) under this mechanism, since it's possible to compactly store\nthe keys by making it derived from a tree or chain of hash functions.\n\nA compact revocable example for Bob to broadcast could be:\n\u003cPubkeyAlice\u003e OP_CHECKSIG\nOP_NOTIF\n\t\u003cCSVDelay\u003e OP_DROP OP_CSV \nOP_ENDIF\n\u003cPubkeyBob\u003e\nOP_CHECKSIG\n\nOn the other hand, if Alice broadcasted it, her script could be:\n\u003cPubkeyBob\u003e OP_CHECKSIG\nOP_NOTIF\n\t\u003cCSVDelay\u003e OP_DROP OP_CSV \nOP_ENDIF\n\u003cPubkeyAlice\u003e\nOP_CHECKSIG\n\nAlice successful redemption of her broadcast would be:\n(after one week)\n\u003cAliceSig\u003e \u003c0\u003e\n\nBob's penalty transaction on Alice's broadcast would be:\n\u003cAliceSig\u003e \u003cBobSig\u003e\n\nIf Alice did not broadcast the correct Commitment, Bob can take the\nmoney immediately because she disclosed her private key when creating\nthe new Commitment transaction, so Bob has both PrivkeyBob and\nPrivkeyAlice. If Alice correctly broadcast the most recent Commitment,\nBob does not have PrivkeyAlice so he cannot take the funds, but Alice\ndoes not have PrivkeyBob so she has to wait for the CSV delay.\n\nIf the goal is to save space, it saves a little in the\ntimeout/non-penalty case, but the transactions are larger for penalty\ncases (although they may be less frequent).\n\nIt's also possible to make it just a multisig output with the child\ntransaction spending from it pre-signed as well using nSequence, but\nthat requires more storage and more on-chain transactions (while saving\nin the script output size), this design is not necessary for this\nparticular instance if there's OP_CSV.\n\nAs a side note, OP_CODESEPARATOR may become useful if there is\nSIGHASH_NOINPUT inside segregated witness in the future, by being able\nto have one signature be able to apply towards multiple types of\ntransactions (e.g. different redeemScript/scriptPubKey r-values or\npubkeys).\n\n-- \nJoseph Poon",
"sig": "25be2dcecec0c37b267198c42e3188c92860683a3f29b47c08b501296fdf6b1f1c944985ce898170d99e12374c50be4fae54180d289d492e30664c7ffe0b40ef"
}