Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Jeremy <jlrubin@mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

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@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@lists.linuxfoundation.org> wrote:
>
>> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4702 bytes --]