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

[A similar message was posted in the Bitcointalk BIP322 thread.]

OK, I just figured out how to solve the delegation problem. It builds on Je=
remy Rubin's transaction delegation post which I linked to a few days ago.

In BIP322, there is a [planned] provision for some person to delegate signi=
ng to another person. That means the second person can do all the signing s=
tuff that the first person could do, and the signature is as if the first p=
erson signed it.

What this could be useful for?

- L2/Lightning Network, a channel is just 2-of-2 multisig, so a prospective=
 channel co-creator "delegate" signing to the channel itself, by signing a =
UTXO inside the multisig - signing along with the other party, creating a d=
ummy output (see below), which can be signed to prove liquidity on behalf o=
f the channel, while keeping the channel itself anonymous.
- CoinJoin, To prove that some CoinJoin coordinator is liquid without viola=
ting its anonymity by revealing public keys, the person managing the CoinJo=
ins delegates signing from all UTXOs to be used in the CJ, at once, delegat=
ing signing to another dummy output.
- By the same token, Mixers can prove their liquidity without revealing the=
ir UTXO set.
- Silent Payments, where the public key is not even known in the first plac=
e, the address of a silent payment can delegate signing to another dummy ou=
tput which only the sender and receiver know about.

So how does this delegation work? It's very simple:

1. All UTXOs that want to delegate signing to a different party must sign a=
 preliminary transaction of this format:
- All input/output amounts are zero.
- input 1 is an invalid input of the kind in BIP322
- the rest of the inputs are the UTXOs wanting to delegate signing to a dif=
ferent party, with valid signatures/witness stacks.
- there is only one output, and it is a P2WSH output with the following scr=
ipt:
OP_PUSH <hash-of-address-hash> OP_SWAP OP_HASH160 OP_EQUALVERIFY
- And the witness stack that will "spend" the transaction in the "to_spend"=
 tx is simply:
<address-hash>
- Likewise, the "to_spend" tx has only one input, refering to the txid of t=
he delegating transaction with output point 0 i.e. the UTXO <delegation-txi=
d>:0. Outputs of "to_spend" remain the same.
-- Contrary to the use of Hash160, we are NOT hashing a public key or scrip=
t. We are hashing an address hash, implying that we are using addresses.

Do you know why I said "delegating to a different party"? Because it could =
be a functionally different entity, just like how CEO is diffferent from LL=
C company even if it has only 1 employee. The "address" here represents a k=
ind of company <but is not a smart contract> - it can represent a channel, =
it can represent a coinjoin, it can represent a silent payment. The channel=
/CJ/etc. only has to hash the decoded RIPEMD160 of an address, with another=
 SHA256-RIPEMD160, to make an "address" that can be used to sign messages f=
rom.

This "address" aka. LLC company can even be encoded with Bech32 to make it =
look like a real address - obviously don't send any funds directly to that =
address because they will be lost - and in fact, it *should* be Bech32-enco=
ded when transmitting the Signed Message.

A signed message has these three parts:

Message
Address
Signature

BIP322 specifies the signature is just the raw transaction format of "to_si=
gn". Normally, the address would simply be the address you are signing from=
, but in the case of delegation, it is desireable for the original addresse=
s to remain anonymous. So since an address must be filled in somewhere, the=
 Bech32 "hash-of-address-hash" created above can be used as a P2WSH address=
.

Advantages of this scheme:

- The real addresses/UTXOs signing the transaction are only known to each o=
ther and whoever is managing the "to_delegate" transaction.
- Only the real signers and the person who is in charge of the P2WSH output=
 can sign the "to_delegate" output and thus sign a message from it (note th=
at they could be the same person).
- There can be an arbitrary number of delegations before the transaction is=
 actually signed (the new person who is in charge of signing, i.e. has the =
P2WSH output of the "to_delegate" transaction can simply generate another a=
ddress hash, and delegate to that "address" in another transaction, giving =
some other person that "address" if they want to)
- Delegated signatures can wrap Full and Full with UTXOs signing formats, s=
o Light clients do not have to directly support those two formats, either f=
or complexity reasons, or because they have no UTXO set.
- And crucially: **There is no on-chain transaction, so the delegation is p=
rivate and cannot be traced back by the public**.

And there are virtually no disadvantages to this.

I should emphasize that you don't delegate signing to another person, you d=
elegate signing to another party that may just be comprised by one person. =
I say this because the delegation does not make any new on-chain UTXOs that=
 someone could posess, but it simply creates a hash160 of some address hash=
 that was generated by the delegators, and the hash-of-address-hash does no=
t necessarily have to represent a person, it can also represent a service.

FAQ:

Q: Does this utilize the Full format?
A: Yes.

Q: How to represent the delegation in a signed transaction?
A: Just encode the hash-of-address-hash in Bech32 version 0 and put it in t=
he Address field.

Q: If the delegation is private, then how can the address-hash be known and=
 the transaction signed?
A: The UTXO signers take a random address associated with them <could be on=
e of their own address, could be the address of a multisig that is being us=
ed elsewhere etc.> and then make the hash160 of that address. Whoever they =
give this to, can sign a BIP322 transaction.

Q: How can the public verify a delegated BIP322 transaction if the address-=
hash is private?
A: The hash-of-address-hash is revealed in the Address, not in the Signatur=
e. BIP322 states that the signature only contains the "to_sign" transaction=
, which does not contain the witness stack of "to_spend" that has the hash-=
of-address-hash (because THAT was already spent in "to_spend") therefore th=
e address hash is Bech32 (version 0) encoded and can be decoded to re-const=
ruct "to_spend" transaction and from there "to_sign".

Q: How to differentiate between non-delegated and delegated signatures?
A: You can't. But then again, BIP322 doesn't differentiate between "message=
 signatures from an address" and a signature from a set of UTXOs so it woul=
dn't be able to identify a delegated transaction anyway.
Rather, a full-blown verification software should present a list-box or a s=
et of radio buttons, that toggles between "Legacy", "Simple", "Full", "Full=
 with UTXOs" and "Full with Delegation" - Each of these controls the conten=
t in the Address field - this would already be required to support validati=
ng Legacy signatures anyway, which are otherwise incompatible with the tran=
saction-based signing (and this is the workaround BIP322 specifies to suppo=
rt that).

Q: What if the verifier does not have a UTXO set (light clients)?
A: Then present three toggles or radio buttons: "Legacy", "Simple", and "De=
legated" - each of these options only require a single encoded address to b=
e specified in the field, and Full, and Full With UTXOs signatures can be w=
rapped with a delegation to support a single address. Consequentially, thes=
e control how the signed transaction is [re]constructed for sign/verify.

CC'ing Kalle as he might be interested in this.

- Ali