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
|
Return-Path: <rot13maxi@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 40229C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 13:26:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 1B62460BD7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 13:26:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1B62460BD7
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=lc6RZ+0J
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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,
RCVD_IN_MSPIKE_H2=-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 EWwp-X1X4HRp
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 13:26:00 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 37F2F60B35
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
by smtp3.osuosl.org (Postfix) with ESMTPS id 37F2F60B35
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 13:25:59 +0000 (UTC)
Date: Thu, 02 Feb 2023 13:25:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1675344357; x=1675603557;
bh=ZpX1KFZimuaC6f+hyHBc+rky2t3zLYO5IVvqxkyXDYI=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=lc6RZ+0JjBtQ5KI2QcjYP/XZjc+gnYMGAsmxsz62TL6vbV/ThPyFmRehfoh9BjMU7
hhKAuigHbeLy4EOWT49Fj29FpiwXxF3y9eJOCilgfDgu2z0t+H9AuZTHgOi7pNGIAS
27KsyPxX4SnfFL4LQb2OqO4VRGbadKDicK76uw1sslNNuRi0vjp2g08qFXPsVCysYr
jTEozbJxm/vLASkTQmTL1FTNHvGkjYbVctLsg54W3a8edBY8RLYqD1DFWeXHCbyiqk
mlRRhDW8IRNwrRywWXK2QWaOLDL7Sp4WYmMNaLK3EDeoEkw5T62y/zbEGUlWE643y2
BQJDYzQIgbiwA==
To: bitcoin-dev@lists.linuxfoundation.org
From: Rijndael <rot13maxi@protonmail.com>
Message-ID: <ca8622cb-445e-4258-bbac-b3ee1ce95f4c@protonmail.com>
In-Reply-To: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
Feedback-ID: 41648937:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 02 Feb 2023 13:33:02 +0000
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: Thu, 02 Feb 2023 13:26:04 -0000
Hello Christopher,
I think if the protocol that you were designing always had <80 bytes,
I'd prefer the OP_RETURN. I think the "witness envelope" has two major
disadvantages compared to the OP_RETURN method:
1. You need to first spend to he address that commits to the script that
encodes your data payload. So you have a two step process of first
spending to a "commitment" address and then a second spend to "reveal"
your payload. You can CPFP to get them both into the same block, but its
still two transactions, so more cost, etc.
2. Because of the two step process in (1), if for some reason you were
unable to get the "reveal" transaction into a block (for example there's
widespread censorship of transactions that match the format of the
"reveal" script), then you might have money that's stuck in the "commit"
stage of the protocol. The way out of this would be to get your money
out via the keypath or another tapleaf, but then you need to spend money
to cancel a step in your protocol. Of course there could be widespread
censorship of your OP_RETURNs too, but you don't have to spend funds on
the cancellation spends.
I think (2) is actually a pretty weak argument because as we saw in the
full-rbf discussion, as long as there's some threshold number of nodes
in the network that relay transactions to miners, you can probably find
a path to a miner (IIRC the number was on the order of 15% of the
network?). So I think the big reason to pick OP_RETURN over the witness
embedding is that you save a transaction and possibly some
failure-recovery/cancellation logic.
Obviously if your data is larger than 80 bytes, then you probably want
to do the witness-embedding method. If your data smaller, then a
pay-to-contract tweak probably the best thing from a space and
fingerprinting perspective.
- rijndael
On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev wrote:
> All other things being equal, which is better if you need to place a
> 64-bytes into the Bitcoin blockchain? A traditional=C2=A0OP_RETURN=C2=
=A0or 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 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 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
>
|
