Date: Tue, 16 Mar 2021 06:09:56 +0000
To: Jeremy <jlrubin@mit.edu>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <plFEi9xoSnZ0TDJ7wH2dJx1F727FCSBrPsa2-26AXtveHKolt9bzTE1tiGIoPSjhgBfToVID2YHEaMGwwVU5dZ3Sozmz9UO-6HvbEDmm67I=@protonmail.com>
In-Reply-To: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
References: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing
	rules, no fork required
Precedence: list

Good morning Jeremy,

This is a very cool idea!

> Multiple Delegates: By signing a txn with several delegate outputs, it is=
 possible to enforce multiple disparate conditions. Normally this is superf=
luous -- why not just concatenate S1 and S2? The answer is that you may hav=
e S1 require a relative height lock and S2 require a relative time lock (th=
is was one of the mechanisms investigated for powswap.com).

I am somewhat confused by this.
Do you mean that the delegating transaction (the one signed using the scrip=
t of A with `SIGHASH_NONE`) has as input (consumes) multiple delegate outpu=
ts D1, D2... with individual scripts S1, S2... ?

> Sequenced Contingent Delegation: By constructing a specific TXID that may=
 delegate the coins, you can make a coin's delegation contingent on some ot=
her contract reaching a specific state. For example, suppose I had a contra=
ct that had 100 different possible end states, all with fixed outpoints at =
the end. I could delegate coins in different arrangements to be claimable o=
nly if the contract reaches that state. Note that such a model requires som=
e level of coordination between the main and observing contract as each Coi=
n delegate can only be claimed one time.

Does this require that each contract end-state have a known TXID at setup t=
ime?

> Redelegating: This is where A delegates to S, S delegates to S'. This typ=
e of mechanism most likely requires the coin to be moved on-chain to the sc=
ript (A OR S or S'), but the on-chain movement may be delayed (via presigne=
d transactions) until S' actually wants to do something with the coin.

The script `A || S || S'` suggests that delegation effectively still allows=
 the original owner to still control the coin, right?
Which I suppose is implied by "Revocation" above.

Regards,
ZmnSCPxj