summaryrefslogtreecommitdiff
path: root/01/9b680b36fe8cd1ddbbb84b3095e19e35773eaf
blob: 554b3e7fdd6527a038f8f83aaa530b2a09932b8d (plain)
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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DA3EDC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Aug 2022 15:06:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B3880408B1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Aug 2022 15:06:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B3880408B1
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
 header.a=rsa-sha256 header.s=2013 header.b=ktzkZxok
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DhtvuHD61Vce
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Aug 2022 15:06:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DE42A400A6
Received: from smtpo97.poczta.onet.pl (smtpo97.poczta.onet.pl
 [213.180.149.150])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DE42A400A6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 Aug 2022 15:06:08 +0000 (UTC)
Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4M2tYN0mmnzlgbhV;
 Wed, 10 Aug 2022 17:06:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1660143960; bh=zsqAA5QJNOpUvhhnC2Hg/YVPkFNfZhgtN+cs6RPmnQI=;
 h=From:Cc:To:Date:Subject:From;
 b=ktzkZxokF8q7JCq0A3cfHTtEfH1e7pB/aRkBA6v4vOyTeT9Kq7Pd7qCqvfaSbYrk/
 gW4ubwnubukA8TpbSWA/gtDx2nXwRlesXDD9S6KGHmSj9uPmAn5wEoXTxBAqUq11TV
 UcuCKl4aQ9j6SczOp8zG6P9x9hxghDajTySn6JUo=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.241.34] by pmq4v.m5r2.onet via HTTP id ;
 Wed, 10 Aug 2022 17:06:00 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: Ali Sherief <ali@notatether.com>
Date: Wed, 10 Aug 2022 17:05:59 +0200
Message-Id: <166373835-fcb0adc6e7c70aa2d37a60a977c1af89@pmq4v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.241.34;PL;2
X-Mailman-Approved-At: Wed, 10 Aug 2022 15:10:25 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Regarding BIP322 edge cases
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: Wed, 10 Aug 2022 15:06:11 -0000

> I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDAT=
ASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA p=
ublic key recovery

You can always perform key recovery for legacy ECDSA: "<signature> OP_SWAP =
OP_CHECKSIG" is always spendable, for any valid <r,s> DER-encoded pair. Her=
e, if "<signature> <messageHash> <pubkey> OP_CHECKDATASIG" works for signat=
ure verification BIP, then you only need to provide "<signature>" as an inp=
ut, the rest could be placed in some output, and your program could easily =
compute that. Or you can use "OP_DUP OP_HASH160 <address> OP_EQUALVERIFY <m=
essageHash> OP_SWAP OP_CHECKDATASIG" as your output script, then the signer=
 has to provide a valid signature, and a valid public key explicitly, but i=
f you only have some signature, then you can always recover that key by you=
rself.

Because if OP_CHECKDATASIG is not handled, then still, signing by scripts c=
an handle that, but the Script would be unnecessarily complex. And because =
there is no need to introduce OP_CHECKDATASIG on-chain, it can be safely do=
ne inside this BIP.

> I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help im=
plement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instructi=
on.

Because if you want to support any script, and you want to add a new opcode=
, you have to make it somehow compatible with existing schemes. You have to=
 assign some byte for OP_CHECKDATASIG or for any new opcodes you want to ad=
d. And you don't want to assign just the next free opcode, because you will=
 get OP_CHECKSIGADD or other opcodes from TapScript, so your script decoder=
 will no longer handle two script versions at once. Unless you want to make=
 it also compatible with altcoins like BCH, but I guess it is not needed.


On 2022-08-10 15:53:31 user Ali Sherief <ali@notatether.com> wrote:
> > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has t=
o be somehow introduced to make it compatible with "Bitcoin Message".

I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATAS=
IG can take <signature> <pubkeyhash> off the stack and perform an ECDSA pub=
lic key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid betwe=
en OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.

But the implementations would have to decode the Base58 address into "0x00"=
 plus the address hash. As the only supported invoice type for the Legacy s=
igning methods, this should be straight forward to do.

> And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then =
it is "conditionally valid transaction".

I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help impl=
ement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.

- Ali

On Wed, 10 Aug 2022 04:59:46 +0200, vjudeu@gazeta.pl wrote:
> > I'm not sure what is to be gained from adding an opcode
>
> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to =
be somehow introduced to make it compatible with "Bitcoin Message". And we =
have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "co=
nditionally valid transaction". It is also possible to assign some unused o=
pcode, but then it will be more complex, because in Script, those opcodes m=
ake transaction invalid, but inside TapScript, those opcodes are defined as=
 OP_SUCCESS, and make things automatically valid.
>
>
> On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> > Although there is a Github issue/PR at https://github.com/bitcoin/bips/=
pull/1347 for addressing all the TODO items of BIP322, I decided to throw i=
t in the mailing list again to see if anyone else has suggestions for deali=
ng with them.
>
> So in an older copy of the draft at https://github.com/bitcoin/bips/blob/=
b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the s=
ome TODO items, and I will copy-paste the ones in the Specification section=
 (for full proofs) here:
>
> > TODO: How does this interact with as-of-yet-unspecified "Silent Transac=
tions"?
> > TODO: Some invalid opcode to allow only in various proof types?
> > TODO: A way for the initial signer to delegate to another scriptPubKey;=
 needed for better privacy and CoinJoin/Lightning compatibility
>
> So to start with, I believe it will be very helpful to limit what opcodes=
 scriptPubKeys to be elligible to sign from them. The specification already=
 does so to a point, but in order for these to be recognizable, it's my opi=
nion that one of the NOPs should be placed at the beginning of the script t=
o activate proof parsing mode.
>
> Of course, an opcode is not necessary at all, if the program is able to i=
nfer from context where the proof is coming from. After all, since they can=
not be broadcasted, they can't be mined in blocks, so will never be encount=
ered in a full node's usual verifier. I'm not sure what is to be gained fro=
m adding an opcode - the only source for real transactions is from P2P-obta=
ined blocks, so when a human inputs a signature to be verified, it can chec=
k that a real transaction is not being inserted by looking for the invalid =
input.
>
> For Silent Transactions, I have already given my suggestion in the PR, th=
at some subsection can be made saying that it can operate with them by usin=
g its scriptPubKey (and other stuff that may be necessary - I am not excatl=
y sure what goes inside the Witness stack of message_signature).
>
> In the case of the last TODO, related to delegation to another scriptPubK=
ey, I am not quite sure at the moment what to do about it - perhaps you guy=
s can place a MAST (two Merkle branches, to be specific) - the first branch=
 has the original signer's scriptPubKey, the second branch contains the del=
egated signer's scriptPubKey.
>
> - Ali