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
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4DF8BC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 03:00:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 15CBB402F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 03:00:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 15CBB402F2
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=fZvxvG5M
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 fR6O0CJK85qU
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 02:59:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2444340195
Received: from o243.poczta.onet.pl (o243.poczta.onet.pl [213.180.142.243])
by smtp2.osuosl.org (Postfix) with ESMTPS id 2444340195
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 02:59:58 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4M2ZRV0qsBz4Wq0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2022 04:59:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1660100390; bh=sbAaG6x6BdDkzpMTU2Xtrx+TLiOq2Zf0r5n8oTHXYpw=;
h=From:To:In-Reply-To:Date:Subject:From;
b=fZvxvG5MXdZM/RFCI/xF9pkaSw5IliHye+Lq9E+/ZsbURbmkm8bQoDX3pPNxvdhKS
GGguyogek6A+5UuAs/jWHwCIqodoReCvvZokmCFaztIUXIwL+7fYCREZ0qeWhud+uO
hNU5PKFy6ySg8oMo0bMyj0vb3RKY8xx0o1brXzN4=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.240.242] by pmq5v.m5r2.onet via HTTP id ;
Wed, 10 Aug 2022 04:59:50 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: "Ali Sherief <ali@notatether.com>,
Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
bitcoin-dev@lists.linuxfoundation.org
In-Reply-To: <20220809130908.yykum37tre7um4j3@artanis>
Date: Wed, 10 Aug 2022 04:59:46 +0200
Message-Id: <165836641-bc7ec98411dacebd3de15c1b1f7c5cf4@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.240.242;PL;1
X-Mailman-Approved-At: Wed, 10 Aug 2022 08:22:32 +0000
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 03:00:01 -0000
> 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 ha=
ve opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "cond=
itionally valid transaction". It is also possible to assign some unused opc=
ode, but then it will be more complex, because in Script, those opcodes mak=
e transaction invalid, but inside TapScript, those opcodes are defined as O=
P_SUCCESS, and make things automatically valid.
On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
> Although there is a Github issue/PR at https://github.com/bitcoin/bips/pu=
ll/1347 for addressing all the TODO items of BIP322, I decided to throw it =
in the mailing list again to see if anyone else has suggestions for dealing=
with them.
So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6=
b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the som=
e 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 Transacti=
ons"?
> TODO: Some invalid opcode to allow only in various proof types?
> TODO: A way for the initial signer to delegate to another scriptPubKey; n=
eeded for better privacy and CoinJoin/Lightning compatibility
So to start with, I believe it will be very helpful to limit what opcodes s=
criptPubKeys to be elligible to sign from them. The specification already d=
oes so to a point, but in order for these to be recognizable, it's my opini=
on that one of the NOPs should be placed at the beginning of the script to =
activate proof parsing mode.
Of course, an opcode is not necessary at all, if the program is able to inf=
er from context where the proof is coming from. After all, since they canno=
t be broadcasted, they can't be mined in blocks, so will never be encounter=
ed in a full node's usual verifier. I'm not sure what is to be gained from =
adding an opcode - the only source for real transactions is from P2P-obtain=
ed blocks, so when a human inputs a signature to be verified, it can check =
that a real transaction is not being inserted by looking for the invalid in=
put.
For Silent Transactions, I have already given my suggestion in the PR, that=
some subsection can be made saying that it can operate with them by using =
its scriptPubKey (and other stuff that may be necessary - I am not excatly =
sure what goes inside the Witness stack of message_signature).
In the case of the last TODO, related to delegation to another scriptPubKey=
, I am not quite sure at the moment what to do about it - perhaps you guys =
can place a MAST (two Merkle branches, to be specific) - the first branch h=
as the original signer's scriptPubKey, the second branch contains the deleg=
ated signer's scriptPubKey.
- Ali
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
