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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 28216C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:35:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 0FF9060EB1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:35:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 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,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id It5djBAaU2ma
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:35:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp3.osuosl.org (Postfix) with ESMTPS id 86D2C60C05
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:35:41 +0000 (UTC)
Date: Tue, 03 May 2022 09:35:31 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1651570538;
bh=vaqiscGNnST1BTJEOsz6fsK0AIaZkhZ07A9VoOiF10U=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=gApfqf27lBdveJ8tDMiqRNHMfql/yAW8GZwEw7wnE0czpzL08WcwxskEBjtwykWl+
NDTB4uQu0zPvDR8j4bxeFacHoP4QYE8vFmiWXg4nEkqUdrKNOu7m9hwSrrWmAORbxz
p4UanUVnyB5aLn1dKf7SwRCY6IpLCdc8Uxdn7+uej59+Ou54VsCy7DJ8i0/Aqou6ZY
5wOxHRuzCkVl1vGtM30MxDlyJfO/HrxI8MSbqMjqgigSrd+kd2tmuIU5TXRveN6PS5
9f1UkZ5eUCadPKSqmAW6t/PITweBrxmInWThezWL//zcw1QU1PEz5hKOGGSKtAa/C7
d0jpQJ1xwM2rg==
To: vjudeu@gazeta.pl,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <9WZCDiqADRzJudttdoDBbzOf65MpFgxUHU-4Qf3b9tJRglu81V-UB4wvvNJntGS-_F3X4mEVJPFqNRAkykn935hVGrnvxeYeX9I2nRClmRI=@protonmail.com>
In-Reply-To: <160600410-14147cd52da04b7e94af778dff5502bf@pmq7v.m5r2.onet>
References: <160600410-14147cd52da04b7e94af778dff5502bf@pmq7v.m5r2.onet>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Pay to signature hash as a covenant
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, 03 May 2022 09:35:43 -0000
Good morning vjudeu,
> Typical P2PK looks like that: "<signature> <pubkey> OP_CHECKSIG". In a ty=
pical scenario, we have "<signature>" in out input and "<pubkey> OP_CHECKSI=
G" in our output. I wonder if it is possible to use covenants right here an=
d right now, with no consensus changes, just by requiring a specific signat=
ure. To start with, I am trying to play with P2PK and legacy signatures, bu=
t it may turn out, that doing such things with Schnorr signatures will be m=
ore flexible and will allow more use cases.
>
>
> The simplest "pay to signature" script I can think of is: "<signature> OP=
_SWAP OP_CHECKSIG". Then, any user can provide just a "<pubkey>" in some in=
put, as a part of a public key recovery. The problem with such scheme is th=
at it is insecure. Another problem is that we should handle it carefully, b=
ecause signatures are removed from outputs. However, we could replace it wi=
th some signature hash, then it will be untouched, for example: "OP_TOALTST=
ACK OP_DUP OP_HASH160 <signatureHash> OP_EQUALVERIFY OP_FROMALTSTACK OP_CHE=
CKSIG".
>
> And then, signatures are more flexible than public keys, because we can u=
se many different sighashes to decide, what kind of transaction is allowed =
and what should be rejected. Then, if we could use the right signature with=
correct sighashes, it could be possible to disable key recovery and requir=
e some specific public key, then that scheme could be safely used again. I =
still have no idea, how to complete that puzzle, but it seems to be possibl=
e to use that trick, to restrict destination address. Maybe I should wrap s=
uch things in some kind of multisig or somehow combine it with OP_CHECKSIGA=
DD, any ideas?
You can do the same thing with P2SH, P2WSH, and P2TR (in a Tapscript) as we=
ll.
Note that it is generally known that you *can* use pre-signed transactions =
to implement vaults.
Usually what we refer to by "covenant" is something like "this output will =
definitely be constructed here" without necessarily requiring a signature.
HOWEVER, what you are proposing is not ***quite*** pre-signed transactions!
Instead, you are (ab)using signatures in order to commit to particular sigh=
ashes.
First, let me point out that you do not need to hash the signature and *the=
n* use a raw `scriptPubKey`, which I should *also* point it is not going to=
pass `IsStandard` checks (and will not propagate on the mainnet network re=
liably, only on testnet).
Instead, you can use P2WSH and *include* the signature outright in the `red=
eemScript`.
Since the output `scriptPubKey` is really just the hash of the `redeemScrip=
t`, this is automatically a hash of a signature (plus a bunch of other byte=
s).
So your proposal boils down to using P2WSH and having a `redeemScript`:
redeemScript =3D <fixedSignature> <fixPubKey> OP_CHECKSIG
Why include the `fixPubKey` in the `redeemScript`?
In your scheme, you would provide the signature and pubkey in the `scriptSi=
g` that spends the `scriptPubKey`.
But in a post-P2WSH world, `redeemScript` will also be provided in the `wit=
ness`, so you *also* provide both the signature and the pubkey, and both ar=
e hashed before appearing on the `scriptPubKey` --- which is exactly what y=
ou are proposing anyway.
The above pre-commits to a particular transaction, depending on the `SIGHAS=
H` flags of the `fixedSignature`.
Of note is that the `fixPubKey` can have a throwaway privkey, or even a ***=
publicly-shared*** privkey.
Even if an alternate signature is created from well-known privkey, the `re=
deemScript` will not allow any other signature to be accepted, it will only=
use the one that is hardcoded into the script.
Using a publicly-shared privkey would allow us to compute just the expected=
`sighash`. them derove the `fixedSignature` that should be in the `redeemS=
cript`.
In particular, this scheme would work just as well for the "congestion cont=
rol" application proposed for `OP_CTV`.
`OP_CTV` still wins in raw WUs spent (just the 32-WU hash), but in the abse=
nce of `OP_CTV` because raisins, this would also work (but you reveal a 33-=
WU pubkey, and a 73-WU/64-WU signature, which is much larger).
Validation speed is also better for `OP_CTV`, as it is just a hash, while t=
his scheme uses signature validation in order to commit to a specific hash =
anyway (a waste of CPU time, since you could just check the hash directly i=
nstead of going through the rigmarole of a signature, but one which allows =
us to make non-recursive covenants with some similarities to `OP_CTV`).
A purported `OP_CHECKSIGHASHVERIFY` which accepts a `SIGHASH` flag and a ha=
sh, and checks that the sighash of the transaction (as modified by the flag=
s) is equal to the hash, would be more efficient, and would also not differ=
by much from `OP_CTV`.
This can be used in a specific branch of an `OP_IF` to allow, say, a cold p=
rivkey to override this branch, to start a vault construction.
The same technique should work with Tapscripts inside Taproot (but the `fix=
edPubKey` CANNOT be the same as the internal Taproot key!).
Regards,
ZmnSCPxj
|
