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
|
Return-Path: <christophera@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B5EBDC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 00:47:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 90C9260DB7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 00:47:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 90C9260DB7
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=lifewithalacrity-com.20210112.gappssmtp.com
header.i=@lifewithalacrity-com.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=SkYJQIGB
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no 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 Dj-r5TdDIt50
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 00:47:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6181E60D91
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
[IPv6:2a00:1450:4864:20::134])
by smtp3.osuosl.org (Postfix) with ESMTPS id 6181E60D91
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 00:47:12 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id u12so16373608lfq.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 16:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lifewithalacrity-com.20210112.gappssmtp.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=A1mdRAX1rY8dEeXsRRkOlPPXly8souQq5sgwhqEWzCk=;
b=SkYJQIGBcpXBNkJOAXCPJ9StSKE3vpAJTs5W/7Ya2Vs2E3Hwu3U87ECuTi57hEtZZW
y6nC9ZBeV+L61BDeQWVXPl1WcTdZRoLopXOYaGLUGd3HDaihho9il+t/rE5JomvkE2cO
ju0GJElimfqY9TwBBKf2dVKb8wNbs/oJhyMf0Bd84bHgQZZM+oahbTS5pECIHpHOHrlr
1/vaf5W9huga3WtfD3KRKbzRbft2viH+Of42C5p3vMlTWtvI44hfu7uXctsne9I95FVb
K89EjMu8oRRcQxt2/r7ghOxmOm3V2a7t7XF8DLbVhsYxQ2Gw+oXYjpXf7B6XqHjdi/91
WGAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=A1mdRAX1rY8dEeXsRRkOlPPXly8souQq5sgwhqEWzCk=;
b=D6Wfvt+lERyJHAcbu9B+4Q9Y/82iYluIhNLCBRMUhRmnym1DJTFupOWZ2T1IR/W3fz
TNzmQCU7u/YLJsGB14V+KE4BG24bHaHHo3DIQtAxUN5UwrEjf3y/boyPwZY97hG8M46c
mnuIAxIdA2lVCHLB2BOPGCvJ5GtWaXzQf6xFOqVcQ49N48i1BlE4B5rDSDmFJEs23syw
RzFsWgukdp7eUJcwZe3iPM1A7VOerHBiBg8eufCTEPRvG1AYru3McUwWR1/eLRtFaspq
tScgf65DEMRN0Ywowe0Yv+kKswiTWwUo8NrJNFCvngWhfLAZC9WHFFmw0LeVKEnLp2OI
m20Q==
X-Gm-Message-State: AO0yUKVu508KSNuPaX3i5iK+w/C4pb+P8vbT6w0dYmUCPFmIMREu59V8
qRCq0883L0nwf7wJmRDiiOuDYc0bFt5A/VHpocNuqSV31OxM9w==
X-Google-Smtp-Source: AK7set+0GILDBe+K8s35SAWbmWvbnWiwRpfiotrw2jB1KVX+tcKg7kDydzw91hVb58qoHFOsyglnV6E867Vn8CMhhCA=
X-Received: by 2002:a19:ae0d:0:b0:4d0:7b7:65dc with SMTP id
f13-20020a19ae0d000000b004d007b765dcmr32986lfc.122.1675212429520; Tue, 31 Jan
2023 16:47:09 -0800 (PST)
MIME-Version: 1.0
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Tue, 31 Jan 2023 16:46:32 -0800
Message-ID: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c8f74905f398c905"
X-Mailman-Approved-At: Wed, 01 Feb 2023 01:23:24 +0000
Subject: [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 00:47:13 -0000
--000000000000c8f74905f398c905
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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
I know that the anti-OP_RETURN folk would say =E2=80=9Cneither.=E2=80=9D Bu=
t 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 that
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. I'd love to hear all sides.
-- Christopher Allen
--000000000000c8f74905f398c905
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">All other things being equal, which is better if you need =
to place a 64-bytes into the Bitcoin blockchain? A traditional=C2=A0OP_RETU=
RN=C2=A0or a spent taproot transaction such as:<div><br>OP_FALSE</div><div>=
OP_IF=C2=A0</div><div>OP_PUSH my64bytes</div><div>OP_ENDIF<br><br></div><di=
v>I know that the anti-OP_RETURN folk would say =E2=80=9Cneither.=E2=80=9D =
But if there was no other choice for a particular protocol, such as a times=
tamp or a commitment, which is better? Or is there a safer place to put 64 =
bytes that is more uncensorable but also does not clog UTXO space, only spe=
nt transaction `-txindex` space?<br></div><div><br></div><div>My best guess=
was that the taproot method is better, but I suspect there might be some w=
ho disagree. I'd love to hear all sides.</div><div><br></div><div>-- Ch=
ristopher Allen</div><div><br></div></div>
--000000000000c8f74905f398c905--
|
