📅 Original date posted:2018-02-09
📝 Original message:I'm also highly interested in the case where you sign a delegate
conditional on another delegate being signed, e.g. a bilateral agreement.
In order for this to work nicely you also need internally something like
segwit so that you can refer to one side's delegation by a signature-stable
identity.
I don't have a suggestion of a nice way to do this at this time, but will
stew on it.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <jlrubin at mit.edu> wrote:
> This might be unpopular because of bad re-org behavior, but I believe the
> utility of this construction can be improved if we introduce functionality
> that makes a script invalid after a certain time (correct me if I'm
> wrong, I believe all current timelocks are valid after a certain time and
> invalid before, this is the inverse).
>
> Then you can exclude old delegates by timing/block height arguments, or
> even pre-sign delegates for different periods of time (e.g., if this
> happens in the next 100 blocks require y, before the next 1000 blocks but
> after the first 100 require z, etc).
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
> On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev at rgrant.org>
>> wrote:
>> > Am I reading correctly that this allows unilateral key rotation (to a
>> > previously unknown key), without invalidating the interests of other
>> > parties in the existing multisig (or even requiring any on-chain
>> > transaction), at the cost of storing the signed delegation?
>>
>> Yes, though I'd avoid the word rotation because as you note it doesn't
>> invalidate the interests of any key, the original setup remains able
>> to sign. You could allow a new key of yours (plus everyone else) to
>> sign, assuming the other parties agree... but the old one could also
>> still sign.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180208/75f279de/attachment-0001.html>;
Jeremy [ARCHIVE] /
npub1q8…8qwta
2023-06-07 18:10:30
in reply to nevent1q…eaem
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 18:10:30Event JSON
{
"id": "50fa6ae7a0016fa9c00158e684aec3d876b39fff790ca932e03e0bea7bac82b6",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686161430,
"kind": 1,
"tags": [
[
"e",
"2c4ac7b10c60a79e3222a978e68f7b31f3c05b671343599c2ea55f4413483685",
"",
"root"
],
[
"e",
"f0b3d0120a9d2ea5db62725d61d23c14de7c7f68c7c927a3c6574eaac6aa24e0",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2018-02-09\n📝 Original message:I'm also highly interested in the case where you sign a delegate\nconditional on another delegate being signed, e.g. a bilateral agreement.\n\nIn order for this to work nicely you also need internally something like\nsegwit so that you can refer to one side's delegation by a signature-stable\nidentity.\n\nI don't have a suggestion of a nice way to do this at this time, but will\nstew on it.\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\nOn Thu, Feb 8, 2018 at 11:29 PM, Jeremy \u003cjlrubin at mit.edu\u003e wrote:\n\n\u003e This might be unpopular because of bad re-org behavior, but I believe the\n\u003e utility of this construction can be improved if we introduce functionality\n\u003e that makes a script invalid after a certain time (correct me if I'm\n\u003e wrong, I believe all current timelocks are valid after a certain time and\n\u003e invalid before, this is the inverse).\n\u003e\n\u003e Then you can exclude old delegates by timing/block height arguments, or\n\u003e even pre-sign delegates for different periods of time (e.g., if this\n\u003e happens in the next 100 blocks require y, before the next 1000 blocks but\n\u003e after the first 100 require z, etc).\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\n\u003e On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant \u003cbitcoin-dev at rgrant.org\u003e\n\u003e\u003e wrote:\n\u003e\u003e \u003e Am I reading correctly that this allows unilateral key rotation (to a\n\u003e\u003e \u003e previously unknown key), without invalidating the interests of other\n\u003e\u003e \u003e parties in the existing multisig (or even requiring any on-chain\n\u003e\u003e \u003e transaction), at the cost of storing the signed delegation?\n\u003e\u003e\n\u003e\u003e Yes, though I'd avoid the word rotation because as you note it doesn't\n\u003e\u003e invalidate the interests of any key, the original setup remains able\n\u003e\u003e to sign. You could allow a new key of yours (plus everyone else) to\n\u003e\u003e sign, assuming the other parties agree... but the old one could also\n\u003e\u003e still sign.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180208/75f279de/attachment-0001.html\u003e",
"sig": "6ea0681045e5123b75ef8903c0ced5967c11394d4829f700e4971b24985a6f9c9243ab3c798bfb704fdf1a7b8ea4331cba13ba31ab956ad37e9b9054fc704223"
}