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

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).




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