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
|
Return-Path: <dave@dtrt.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3D2E0C0029
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 13 Jun 2023 08:51:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 225BA821A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 13 Jun 2023 08:51:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 225BA821A5
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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 LoAkJ76Nrctk
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 13 Jun 2023 08:51:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F0C7781FD3
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5])
by smtp1.osuosl.org (Postfix) with ESMTPS id F0C7781FD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 13 Jun 2023 08:51:43 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 461AA2800050;
Tue, 13 Jun 2023 01:51:40 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Tue, 13 Jun 2023 01:51:39 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 12 Jun 2023 22:51:39 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Joost Jager <joost.jager@gmail.com>
In-Reply-To: <CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com>
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
<CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
<CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
<fe630ee713829e1ce2df33a8438cbcf5@dtrt.org>
<CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <211fef60bb46fae7f69e8e5882ff27cb@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 9a0.64882e1b.f3ac1.0
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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, 13 Jun 2023 08:51:45 -0000
On 2023-06-11 09:25, Joost Jager wrote:
> Isn't it the case that that op-dropped partial signature for the
> ephemeral key isn't committed to and thus can be modified by anyone
> before it is mined
That's correct; I hadn't thought of that, sorry.
> I am really looking for a bitcoin-native solution to leverage
> bitcoin's robustness and security properties.
I understand. I would briefly point out that there are other advantages
to not storing a signature for an ephemeral key in the annex. For
example, if you want to generate multiple different potential spending
transactions, you need to store one signature for each potential
transaction. The more data you store in the annex, the less scalable
the vault protocol becomes; by comparison, it's possible to cheaply
store a very large amount of data offchain with high robustness.
Also, depending on construction of the vault, a possible advantage of a
presigned vault (without using the annex) over a solution like OP_VAULT
is that all actions might be able to use keypath spends. That would be
highly efficient, increasing the usability of vaults. It would also be
more private, which may be important to certain classes of vault users.
Even if OP_VAULT was added to Bitcoin, it would be interesting to have
an alternative vault protocol that offered different tradeoffs.
> That years-long timeline that you sketch for witness replacement (or
> any other policy change I presume?) to become effective is perhaps
> indicative of the need to have an alternative way to relay
> transactions to miners besides the p2p network?
The speed depends on the policy change. In this case, I think there's a
reasonable argument to be made that a mitigation for the problems of
annex relay should be widely deployed before we enable annex relay.
Bitcoin Core's policy is designed to both prevent the abuse of relay
node resources and also serve the transaction selection needs of miners.
Any alternative relay system will need to solve the same general
problems: how to prevent abuse of the relayers and help miners choose
the best transactions. Ideas for alternative relay like those
previously proposed on this list[1] avoid certain problems but also
(AFAICT) create new problems.
To be specific towards this proposal, if an alternative relay network
naively implemented annex relay, any miners who used that network could
receive a coinjoin-style transaction with a large annex that
significantly reduced the transaction's feerate. By comparison, any
miners who continued to only receive transactions from the P2P network
of Bitcoin Core (or similar) nodes would have received the transaction
without an annex at its original (higher) feerate, allowing them to to
receive greater revenue if they mined it. If, instead, the alternative
relay network implemented the witness replacement proposal you've linked
to, those miners could still receive up to 4.99% less revenue than
Bitcoin Core-based miners and the operators of the alternative relay
network might have had to pay extra costs for the replacement relays.
You can tweak the proposal to tweak those ratios, but I'm not sure
there's a case where an alternative relay network comes up as a clear
winner over the existing network for general purpose transactions.
Instead, like many things, it's a matter of tradeoffs.
> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.
Apologies for the salt, but there is a good solution: don't use the
block chain to store backup data.
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html
|
