path: root/3e/5b5cc8126625576bdbe3604e41d647f6b97729

Return-Path: <ali@notatether.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 52424C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Aug 2022 04:25:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 401DC419DE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Aug 2022 04:25:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 401DC419DE
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=notatether.com header.i=@notatether.com
 header.a=rsa-sha256 header.s=protonmail header.b=jbxCv1iM
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bqtveyYWwytI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Aug 2022 04:25:43 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7BADE419D7
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7BADE419D7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Aug 2022 04:25:42 +0000 (UTC)
Date: Sun, 14 Aug 2022 04:25:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
 s=protonmail; t=1660451139; x=1660710339;
 bh=n0rmamCLjrz/CP5Y7ra9AHVWqySZdFmshtBhwE2oad4=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:Feedback-ID:From:To:
 Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID;
 b=jbxCv1iMBlGCJN3XV+Xfpr5EkihXE0nu2YUmUrmQG/9iekl4zZ0js1KDP8myzbhww
 fTpfrEfmIzGgMKnnD+DumGSG9dUWjh99lad/6Kd4Tp63eeworIa1029G6nF9szYqHZ
 mTlRku29PxOIEx2iJop0SRKRx4yKDcuTlcaBGCZ20Rg/TIz1mxOXjOjv3oU/A3Wh0J
 VtOx0geCImhNqBM6iR8ICO7yKIiPZlJXRf9U45KNU924KS3XdXurSpj+badvldZUVf
 X3EI2sekvZTO421AUoGOyQ+gP1YN2pwy02FDQSKg8EJeZ0g7ddItNyT+4oPQLE+7nj
 NbEhyu1CUeVEQ==
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
X-Mailman-Approved-At: Sun, 14 Aug 2022 08:19:39 +0000
Subject: [bitcoin-dev] A method for BIP322 signing delegation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Aug 2022 04:25:46 -0000

[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