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
|
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 C3971C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2022 14:30:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id B20E460C29
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2022 14:30:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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, RCVD_IN_MSPIKE_H5=0.001,
RCVD_IN_MSPIKE_WL=0.001, 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 Lt_f8prqnZJH
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2022 14:30:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
by smtp3.osuosl.org (Postfix) with ESMTPS id CDE2A60B75
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2022 14:30:43 +0000 (UTC)
Date: Wed, 09 Mar 2022 14:30:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1646836241;
bh=XAjVX9ANet064ktBRK7aVqbku9A1TMrAVfbqbBpmDAM=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=eOziOZGnSMDKr8TQXyYfXMt42WTORMQ3wXf1lI+Nh+XCgSwjbx79wnfojFlx37f9+
CID1BpBn41q9WYllfB4pOlUD/35bTcPaLwZl5M1WoU/3dl8hR98sNJ8U0ePEV8xhCI
wRimvL6RxZHpex6f1NUv/7f4EuwWcxu5O451QSSJFORVjQipPawM4dLYlajDVrCiVW
0IjEXg6iriovH5nyscV6MPQGS4fYdTgyUntQeVPeP44g0mATxCbDGwcGZwi5u6t9EL
d/epUYq8EKWjQE3ycVF6TUSAFOQ4SGJ04xpqR0Cgr3iAYaLsh1GSisLTENdUKgF7zq
Gp+qHJGSwE60A==
To: Bram Cohen <bram@chia.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <lMd2d3ntj6T-VfDDZ0SHn7cUdWWeFFWO3sHolPwMTdRyGUMRY8JwtICT0vbNy9PPg-u_inUplQ-OvB-wKvXNkEUB17pXBhA7ZDwu9vxiRx0=@protonmail.com>
In-Reply-To: <CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com>
References: <20220308012719.GA6992@erisian.com.au>
<NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
<CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
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, 09 Mar 2022 14:30:44 -0000
Good morning Bram,
> On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > But cross-input signature aggregation is a nice-to-have we want for Bit=
coin, and, to me, cross-input sigagg is not much different from cross-input=
puzzle/solution compression.
>
> Cross-input signature aggregation has a lot of headaches unless you're us=
ing BLS signatures, in which case you always aggregate everything all the t=
ime because it can be done after the fact noninteractively. In that case it=
makes sense to have a special aggregated signature which always comes with=
a transaction or block. But it might be a bit much to bundle both lisp and=
BLS support into one big glop.
You misunderstand my point.
I am not saying "we should add sigagg and lisp together!"
I am pointing out that:
* We want to save bytes by having multiple inputs of a transaction use the =
same single signature (i.e. sigagg).
is not much different from:
* We want to save bytes by having multiple inputs of a transaction use the =
same `scriptPubKey` template.
> > For example you might have multiple HTLCs, with mostly the same code ex=
cept for details like who the acceptor and offerrer are, exact hash, and ti=
melock, and you could claim multiple HTLCs in a single tx and feed the deta=
ils separately but the code for the HTLC is common to all of the HTLCs.
> > You do not even need to come from the same protocol if multiple protoco=
ls use the same code for implementing HTLC.
>
> HTLCs, at least in Chia, have embarrassingly=C2=A0little code in them. Li=
ke, so little that there's almost nothing to compress.
In Bitcoin at least an HTLC has, if you remove the `OP_PUSH`es, by my count=
, 13 bytes.
If you have a bunch of HTLCs you want to claim, you can reduce your witness=
data by 13 bytes minus whatever number of bytes you need to indicate this.
That amounts to about 3 vbytes per HTLC, which can be significant enough to=
be worth it (consider that Taproot moving away from encoded signatures sav=
es only 9 weight units per signature, i.e. about 2 vbytes).
Do note that PTLCs remain more space-efficient though, so forget about HTLC=
s and just use PTLCs.
>
> > This does not apply to current Bitcoin since we no longer accept a SCRI=
PT from the spender, we now have a witness stack.
>
> My mental model of Bitcoin is to pretend that segwit was always there and=
the separation of different sections of data is a semantic quibble.
This is not a semantic quibble --- `witness` contains only the equivalent o=
f `OP_PUSH`es, while `scriptSig` can in theory contain non-`OP_PUSH` opcode=
s.
xref. `1 RETURN`.
As-is, with SegWit the spender no longer is able to provide any SCRIPT at a=
ll, but new opcodes may allow the spender to effectively inject any SCRIPT =
they want, once again, because `witness` data may now become code.
> But if they're fully baked into the scriptpubkey then they're opted into =
by the recipient and there aren't any weird surprises.
This is really what I kinda object to.
Yes, "buyer beware", but consider that as the covenant complexity increases=
, the probability of bugs, intentional or not, sneaking in, increases as we=
ll.
And a bug is really "a weird surprise" --- xref TheDAO incident.
This makes me kinda wary of using such covenant features at all, and if stu=
ff like `SIGHASH_ANYPREVOUT` or `OP_CHECKTEMPLATEVERIFY` are not added but =
must be reimplemented via a covenant feature, I would be saddened, as I now=
have to contend with the complexity of covenant features and carefully che=
ck that `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` were implemented corr=
ectly.
True I also still have to check the C++ source code if they are implemented=
directly as opcodes, but I can read C++ better than frikkin Bitcoin SCRIPT=
.
Not to mention that I now have to review both the (more complicated due to =
more general) covenant feature implementation, *and* the implementation of =
`SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` in terms of the covenant feat=
ure.
Regards,
ZmnSCPxj
|
