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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id DA82CC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 02:19:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id C8C8A4024E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 02:19:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001,
SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TeDNTBJ1dfd6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 02:19:02 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp4.osuosl.org (Postfix) with ESMTPS id 0886540236
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Jan 2022 02:19:01 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1nEMHQ-0005rm-PN; Mon, 31 Jan 2022 12:18:58 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Mon, 31 Jan 2022 12:18:52 +1000
Date: Mon, 31 Jan 2022 12:18:52 +1000
From: Anthony Towns <aj@erisian.com.au>
To: James O'Beirne <james.obeirne@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220131021852.GA4149@erisian.com.au>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
<CAMZUoKmU1cwUAQaBv5m8oo8H3TWBvgsZ_OkQaMC0n0+3cpFtWg@mail.gmail.com>
<CAPfvXfLr4n6RsS6VbEZR59=MRwAx41Crx88ko8-qnRXW4nFYGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPfvXfLr4n6RsS6VbEZR59=MRwAx41Crx88ko8-qnRXW4nFYGA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV
and ANYPREVOUT
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: Mon, 31 Jan 2022 02:19:02 -0000
On Thu, Jan 27, 2022 at 07:18:54PM -0500, James O'Beirne via bitcoin-dev wrote:
> > I don't think implementing a CTV opcode that we expect to largely be
> > obsoleted by a TXHASH at a later date is yielding good value from a soft
> > fork process.
> Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.
I don't think caching is a particular problem even for the plethora of
flags Russell described: you cache each value upon use, and reuse that
cached item if it's needed for other signatures within the tx; sharing
with BIP 143, 341 or 342 signatures as appropriate. Once everything's
cached, each signature then only requires hashing about 32*17+4 = ~548
bytes, and you're only hashing each part of the transaction once in
order to satisfy every possible flag.
> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release?
I think the work to release something like TXHASH is all in deciding:
- if TXHASH or CTV or something else is the better "UX"
- what is a good tx to message algorithm and how it should be
parametized
- what's an appropriate upgrade path for the TXHASH/CTV/??? mechanism
BIP 119 provides one answer to each of those, but you still have to do
the work to decide if its a *good* answer to each of them.
> My guess is "a while" -
If we want to get a good answer to those questions, it might be true
that it takes a while; but even if we want to rush ahead with more of
a "well, we're pretty sure it's not going to be a disaster" attitude,
we can do that with TXHASH (almost) as easily as with CTV.
> The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.
I think most of the opposition is just that support for CTV seems to be
taking the form "something must be done; this is something, therefore
it must be done"...
I'd be more comfortable if the support looked more like "here are the
alternatives to CTV, and here's the advantages and drawbacks for each,
here's how they interact with other ideas, and here's why we think,
on balance, we think this approach is the best one". But mostly the
alternatives are dismissed with "this will take too long" or "this enables
recursive covenants which someone (we don't know who) might oppose".
Cheers,
aj
|
