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
|
Return-Path: <ali@notatether.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id C8833C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 13:53:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 8CC5E80C2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 13:53:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8CC5E80C2B
Authentication-Results: smtp1.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=LchsJwC8
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 smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id JqsfYeAUd6fn
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 13:53:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BB73380B37
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23])
by smtp1.osuosl.org (Postfix) with ESMTPS id BB73380B37
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 13:53:30 +0000 (UTC)
Date: Wed, 10 Aug 2022 13:53:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
s=protonmail; t=1660139608; x=1660398808;
bh=QCgznMebjIyz+i5Yq4ypVNjflctjbS6e9K+uro2rXFs=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=LchsJwC8wZIUnJ6I1r1SxG38PRwxQQN5wprSMANxPETP8LpnaaxtUPBwkxfHyjT6z
39bnsqZZDm2q3ZT9yNzc6nnbNhWmXVLCMiqoC9w8q1Q551DhaT2fYHdq7DHSNsX+rT
fK2rJiQyPyNSKWn9V0kcC5WsBBnehek0zliHOAan7dXPwLN2dtosTUc4j4st/n5qmz
Eh7F24ClLBKuJ4gSfWIIGajmO4jlGQehCBmmBue4dEI5GLvanckCZNaHioNvM5szyd
b6O0z93xZpaKPxoDU4fIfnvjbbVBan/FaR0qYl0cJO3W8qaT9GQi3fodOjSejlo2A3
5wf+B5F4NK1Mw==
To: vjudeu@gazeta.pl
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <20220810135313.qxhshtuq3wx64osz@artanis>
In-Reply-To: <mailman.5.1660132803.3395.bitcoin-dev@lists.linuxfoundation.org>
References: <mailman.5.1660132803.3395.bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 10 Aug 2022 14:01:44 +0000
Cc: 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 13:53:33 -0000
> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to =
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
|
