1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Return-Path: <ali@notatether.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 147F9C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2022 04:39:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id D7CF440921
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2022 04:39:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D7CF440921
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no 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 qHiHTpCaAwTK
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2022 04:39:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DAD7C408DB
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23])
by smtp4.osuosl.org (Postfix) with ESMTPS id DAD7C408DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2022 04:39:01 +0000 (UTC)
Date: Tue, 16 Aug 2022 04:38:47 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
s=protonmail; t=1660624736; x=1660883936;
bh=lzHoK+76KN9/nHFHZR0RB8pL3uwDMpX0Lmaxo2P7DHs=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:Feedback-ID:From:To:
Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID;
b=M1i0z7rus1UlRZ20CK05sZY5Wvh7/aBwEp9j24xvkOrlNzFQCvJLICXkoat3leyHv
bV2rCQIDmm6/lT3l7kEMAnz6EJuUoqSqop2JBjvoJSjGQnJ15WLTrbsw06wtU3CNJQ
Uz+eETpBw6DhONJQPsjUU48NrFO/m2zYXQVBo4XlrayDSeIsuBnoXN0A7z/9CJH9wd
51f/uAe6eIfX40smR/JV+6fpQCgxGi0q4HeVRdGrnLwnLIjLGbxsa3eCp9JL3YAlAF
XnUgKuso0XstS8RRYKIHjyT+FUScRLxZykn5ikBBpD0YJbimtSwZsfhEoaAeVY3bV0
w+X8YGHmMeDoA==
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
X-Mailman-Approved-At: Tue, 16 Aug 2022 08:35:45 +0000
Subject: Re: [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: Tue, 16 Aug 2022 04:39:25 -0000
(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
|
