Date: Tue, 16 Aug 2022 04:38:47 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <20220816043842.a2rbh7cugztle56p@artanis>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] A method for BIP322 signing delegation
Precedence: list

(Note: I'm going to stick with this thread for all proposals for BIP322 pol=
ishing, not just delegation - unless the subject matter changes radically a=
s other people discuss it.)

Instead of the admittingly complicated scheme using transactions, I've crea=
ted one that utilizes multisig to make the possible delegatees known at sig=
ning time. I had a discussion with vjudeu, garlonicon, and aliashraf about =
this over the past week or so, and while we did not reach a consensus about=
 the solution to use, I feel that this scheme requires the least amount of =
modifications to BIP322 draft.

The problem being solved is how to delegate signatures to other scriptPubKe=
ys* [sic] for privacy purposes.

*Here, I use P2WPKH addresses, under the assumption that the delegatees are=
 people. If the delegatees are just some automated scripts or processes [as=
 was mentioned in the BIP], then this scheme is equally valid with P2WSH mu=
ltisignatures with appropriately constructed scriptPubKeys.

What's about to follow was copied almost word-for-word from my forum post w=
ith extraneous paragraphs removed:

---

It is extremely simple and doesn't require any additional transactions:

- Replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH=
 multisig. N is the number of people you want to be able to create the sign=
ature, and their respective pubkeys are included in the script.
-- In this way the possible delegatees are fixed at signature creation time=
 and cannot be extended by creating more transactions.
- Replace the challenge solution in "to_sign" (it's the input that spends t=
he output we made in "to_spend") with a witness stack containing: n <pub1> =
<pub2> ... <pubn> 1 <a-signature> 0
-- The signature is generated as if it were for a real P2WPKH-multisig tran=
saction. [the zero at the end is due to a bug in OP_CHECKMULTISIG that pops=
 an extra element].

appendix - don't mix up this delegation and Full with UTXOs together - it i=
ncreases the numebr of permutations that implementations have to verify.

Pros:

- No recursive transactions.
- If Alice and Bob are the two delegates of a signature (and one of them si=
gn it), Carol does not know any of the private keys or challenge solutions =
and thus cannot claim the script was signed by her [besides the public keys=
 of Alice and Bob are already in the signature]. Required, to avoid signatu=
re fraud.
- The Address field is not used when delegating, so the engine can actually=
 print which (compressed) public key it is signed against - i.e. the addres=
s verification is provable, as opposed to reactive Legacy signatures.
-- Additionally, they will all be Segwit Bech32 addresses so it can just de=
rive and print the corresponding bc1 address instead.
- There is no opcode or new algorithm introduced, so no soft-fork is requir=
ed.

Cons:

- Everyone knows the public keys of the delegators, so there is no privacy =
[then again, in light of the signature fraud problem, this is possibly a no=
n-issue].

---

I'd like to hear everyone's opinions about this.

I don't know who suggested the idea of delegation in the first place, but C=
Cing luke-jr because he participated in that Github discussion, so his opin=
ion about this scheme will clarify a lot of things about this problem.

- Ali