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