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
|
Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id A5528C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:07:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 7544060D61
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:07:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7544060D61
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=messagingengine.com header.i=@messagingengine.com
header.a=rsa-sha256 header.s=fm3 header.b=S9d3J6XX
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, 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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id w489kxGPoq6y
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:07:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 00BC660A9B
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25])
by smtp3.osuosl.org (Postfix) with ESMTPS id 00BC660A9B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:07:19 +0000 (UTC)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.nyi.internal (Postfix) with ESMTP id 6C9305C0126;
Tue, 31 Jan 2023 21:07:17 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute5.internal (MEProxy); Tue, 31 Jan 2023 21:07:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:date:feedback-id:feedback-id:from:from:in-reply-to
:in-reply-to:message-id:mime-version:references:reply-to:sender
:subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender
:x-me-sender:x-sasl-enc; s=fm3; t=1675217237; x=1675303637; bh=e
Z4oyliyffnoUeaOz42UTtNmKBn2dPkJm6kNXT0GwYg=; b=S9d3J6XXfbRl1d9nn
czr00swsTyODii3AjP9sSwussOQE/haxHp4Zcwy82cIDgHLwh/wUlvzfCSKKYxwx
Tf3rZaACwjBv7I1rZSxNSFEUR2mfaStLxVsDqh1YnQvXMOnJxqzZrbMNUy++qJXC
+fcBA5sQuNK5HA/HzyWSKATyLkIrfto0a68mxkOsEwNeR9vrRz2ofxe+WUY/dkSl
bcBYlFrirrpqTbUTzsuluhwtHA3oTALNk6MHY6cttCd/CjT7dNP6V344+WZdRGbP
6FvInWSERuUpB7Ry6yTkqTc6t+nEjjdNY8FktCEjaEyR7l94TQDyZ86a+Oivr8+C
bcazg==
X-ME-Sender: <xms:VcnZYw9x3cQCWvo67n7In8gRXOp5xnXKAEhS9Fzh9PXTA74zcO_Rog>
<xme:VcnZY4u5pkniEL9a0TSXx5t27B6PjAbhnu2hIznOvpY-WCJHDyNl_rejbooXJjtGQ
GlaB1BxGGMVbDrR4u8>
X-ME-Received: <xmr:VcnZY2A6NLQZoADSOVa2rP-GGAUFM9epZ0yd_eZXYYWfDxwfnfnHP8X7_mSguA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefhedggeefucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepfffhvffufggjfhfkgggtgfesthhqmhdttderjeenucfhrhhomheprfgvthgv
rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
gvrhhnpefhteeuleffvddujeejteejjefgjeefleeiieejudeiiedvueegffefueeglefg
ueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvg
htvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:VcnZYweHEvweAhHNzRkcIqLIhlVOLBfQ_o4SSOXl5pyPtKLBKIUOWA>
<xmx:VcnZY1OM68EpRdQ7cMuNt1LWJXk7Q3r6Gw9FuJlcZ2NjOX6GrwxzNQ>
<xmx:VcnZY6ntxwgSqY7wyZ7zK1YhDMwVOf9AHYKuLSNN9guLhug5tGdrsQ>
<xmx:VcnZY2r_doRw-l1DY-kFIjvR-CTlV8cVxYNdH1xfkipsBZEKAO3sGw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
31 Jan 2023 21:07:16 -0500 (EST)
Date: Tue, 31 Jan 2023 21:07:16 -0500
From: Peter Todd <pete@petertodd.org>
To: Christopher Allen <ChristopherA@lifewithalacrity.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
User-Agent: K-9 Mail for Android
In-Reply-To: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
Message-ID: <764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot
OP_FALSE OP_IF OP_PUSH
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, 01 Feb 2023 02:07:21 -0000
On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bit=
coin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>All other things being equal, which is better if you need to place a
>64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>taproot transaction such as:
>
>OP_FALSE
>OP_IF
>OP_PUSH my64bytes
>OP_ENDIF
What's wrong with OpPush <data> OpDrop?
>I know that the anti-OP_RETURN folk would say =E2=80=9Cneither=2E=E2=80=
=9D But if there was
>no other choice for a particular protocol, such as a timestamp or a
>commitment, which is better? Or is there a safer place to put 64 bytes th=
at
>is more uncensorable but also does not clog UTXO space, only spent
>transaction `-txindex` space?
>
>My best guess was that the taproot method is better, but I suspect there
>might be some who disagree=2E I'd love to hear all sides=2E
An important consideration with using taproot is that you need to have the=
data you are committing too to be able to to spend the txout in the future=
=2E OpReturn doesn't have that problem, meaning that in a situation like a =
hard drive failure, you can still recover the funds from a wallet seed=2E
Also, it is incorrect to say that OpReturn outputs "clog UTXO space"=2E Th=
e whole point of OpReturn is to standardize a way to keep such outputs out =
of the UTXO set=2E There is the 75% discount to using witness space=2E But =
considering the size of a transaction as a whole using taproot instead of O=
pReturn doesn't save much=2E
Finally, _64_ bytes is more than a mere 32 byte commitment=2E What specifi=
c use case do you actually have in mind here? Are you actually publishing d=
ata, or simply committing to data? If the latter, you can use ECC commitmen=
ts and have no extra space at all=2E
|
