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: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 59D44C0011
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Feb 2022 03:19:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 41F9B401AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Feb 2022 03:19:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id bUSKYUbDpQFA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Feb 2022 03:19:42 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18])
by smtp2.osuosl.org (Postfix) with ESMTPS id A15124010C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Feb 2022 03:19:42 +0000 (UTC)
Date: Fri, 25 Feb 2022 03:19:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645759179;
bh=SjNFSpCV4/eiEIlw9DyVjWgbQI0tqQPA/SBaLfQQHOU=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=sWXbWxJIz0jkc9yGCSgCcMkf1rgsERPCS/rWCkcV7cROFm/eYjexpJlSs4teJieTI
6HpIwKk++VlyHCK35p6On7OiooHR/Q3Zkp0Vlpjn/uWq16nyGWfUi+y/o2nPvBWQIy
TdICN7VaV/yljNo2ct3b1BgiZurgDPqq5KKtV4oEJzk+IRHiCeN1bN8VUAWALNt9Xb
/N1nzkQsyoRj5p6g4EE7MA+iuv0TbMBt5NmTPnM/Ea7JJsSV7tNTV+ZtVT/bWCqTjb
vMk+Ox6qSiAA+SP2298arFuwVB6CjkDAFh3ayljQMKBLDBOzdQpFceyNQ4hHR4WhTn
wyAl6zqGzk4Pw==
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <XrV3nIrTZfdzTb7tsbwX5xP4COd6pXCA076lWzbXvbhnn7bx6kThL5JzeCxwoimCXKmpux5Gbjycj7t6X8ncYBWx5-HMi2voDuKZm27_h00=@protonmail.com>
In-Reply-To: <CAJ4-pECnAebQGN2=22ifGga9rtO2svdxY1bX96_VEW-wpjEpWw@mail.gmail.com>
References: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet>
<CAJ4-pEBnprd-SdXMZeDsJ37=SiGbQEnaFfpvBzryR21Wbqc1Ew@mail.gmail.com>
<vmZt7irtItdhrsha-cHM0-HgzhCQ6GlWdJXr6mKzEHXmoNz5ypuQLR9eKsltreHb0O2kMfcr_VRkZ1hmoJ9RAp5DaMZorhG1JsRSclhin6s=@protonmail.com>
<CAJ4-pECnAebQGN2=22ifGga9rtO2svdxY1bX96_VEW-wpjEpWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
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: Fri, 25 Feb 2022 03:19:45 -0000
Good morning Zac,
> Hi=C2=A0ZmnSCPxj,
>
> Any benefits of my proposal depend on my presumption that using a standar=
d transaction for storing data must be inefficient. Presumably a transactio=
n takes up significantly more on-chain space than the data it carries withi=
n its OP_RETURN. Therefore, not requiring a standard transaction for data s=
torage should be more efficient. Facilitating data storage within some spec=
ialized, more space-efficient data structure at marginally lower fee per pa=
yload-byte should enable reducing the footprint of storing data on-chain.
>
> In case storing data through OP_RETURN embedded within a transaction is o=
ptimal in terms of on-chain footprint then my proposal doesn=E2=80=99t seem=
useful.
You need to have some assurance that, if you pay a fee, this data gets on t=
he blockchain.
And you also need to pay a fee for the blockchain space.
In order to do that, you need to indicate an existing UTXO, and of course y=
ou have to provably authorize the spend of that UTXO.
But that is already an existing transaction structure, the transaction inpu=
t.
If you are not going to pay an entire UTXO for it, you need a transaction o=
utput as well to store the change.
Your signature needs to cover the data being published, and it is more effi=
cient to have a single signature that covers the transaction input, the tra=
nsaction output, and the data being published.
We already have a structure for that, the transaction.
So an `OP_RETURN` transaction output is added and you put published data th=
ere, and existing constructions make everything Just Work (TM).
Now I admit we can shave off some bytes.
Pure published data does not need an amount, and using a transaction output=
means there is always an amount field.
We do not want the `OP_RETURN` opcode itself, though if the data is variabl=
e-size we do need an equivalent to the `OP_PUSH` opcode (which has many var=
iants depending on the size of the data).
But that is not really a lot of bytes, and adding a separate field to the t=
ransaction would require a hardfork.
We cannot use the SegWit technique of just adding a new field that is not s=
erialized for `txid` and `wtxid` calculations, but is committed in a new id=
, let us call it `dtxid`, and a new Merkle Tree added to the coinbase.
If we *could*, then a separate field for data publication would be softfork=
able, but the technique does not apply here.
The reason we cannot use that technique is that we want to save bytes by ha=
ving the signature cover the data to be published, and signatures need to b=
e validated by pre-softfork nodes looking at just the data committed to in =
`wtxid`.
If you have a separate signature that is in the `dtxid`, then you spend mor=
e actual bytes to save a few bytes.
Saving a few bytes for an application that is arguably not the "job" of Bit=
coin (Bitcoin is supposed to be for value transfer, not data archiving) is =
not enough to justify a **hard**fork.
And any softfork seems likely to spend more bytes than what it could save.
Regards,
ZmnSCPxj
|
