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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
Return-Path: <aymeric@peersm.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5FC3FC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Feb 2023 18:38:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 3AFD141548
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Feb 2023 18:38:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3AFD141548
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id R-7phrOCGeWQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Feb 2023 18:38:04 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2AD4441527
Received: from smtpout3.mo529.mail-out.ovh.net
(smtpout3.mo529.mail-out.ovh.net [46.105.54.81])
by smtp4.osuosl.org (Postfix) with ESMTPS id 2AD4441527
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Feb 2023 18:38:03 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.109.146.15])
by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 2371C20D06;
Sat, 18 Feb 2023 18:38:01 +0000 (UTC)
Received: from peersm.com (37.59.142.103) by DAG6EX2.mxp6.local (172.16.2.52)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Sat, 18 Feb
2023 19:38:00 +0100
Authentication-Results: garm.ovh; auth=pass
(GARM-103G00568c93857-85e7-4e04-9605-a2cb97b87770,
57DB9B9A27D8FE140694BC5FE6D2F54054A63BD2) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.100.114
To: Anthony Towns <aj@erisian.com.au>, Russell O'Connor
<roconnor@blockstream.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
References: <ca8622cb-445e-4258-bbac-b3ee1ce95f4c@protonmail.com>
<57f780b1-f262-9394-036c-70084320e9cf@peersm.com>
<CACrqygCNf3Gv8+VjhyqS4GTb3Epo8qXEKGtQB6sqyR6ib44-fA@mail.gmail.com>
<CABE6yHtM2Dqc63_eURSr7dMirJti5sYnqvHj7vQ_Ab9FC_d04g@mail.gmail.com>
<3d00aacb-585d-f875-784d-34352860d725@peersm.com>
<CACrqygB_FbsRGWYPSUEFTnP15y94Hmo4JtAuv6bH1D3YtbAw9Q@mail.gmail.com>
<b292d887-cbd5-165c-de01-793df2b5e8f3@peersm.com>
<CACrqygAv842ucN7PLYMENXFiSwAZJy2Y+FziJXrWjyCcOXmL3g@mail.gmail.com>
<230265ee-c3f8-dff3-9192-f0c8dc4d913c@peersm.com>
<CAMZUoKkAdQ9TSMm4vPJOrThu_h6VbqwPhOQQR7-Yr+WZ0DMBYw@mail.gmail.com>
<Y+935dALZxEEVMmc@erisian.com.au>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <26619d50-669d-1a7d-82cb-c7de8795dc92@peersm.com>
Date: Sat, 18 Feb 2023 19:38:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <Y+935dALZxEEVMmc@erisian.com.au>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [37.59.142.103]
X-ClientProxiedBy: DAG1EX1.mxp6.local (172.16.2.1) To DAG6EX2.mxp6.local
(172.16.2.52)
X-Ovh-Tracer-GUID: b9920aad-7a1b-4357-b554-bd6144a0a65f
X-Ovh-Tracer-Id: 1948088317038388189
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudejuddgudduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgihesthhqredttdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepheeugefhgeethfeltddvteevveekvdeuiefhueffiefghfetjedthffgffeuheejnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpphgvvghrshhmrdgtohhmpdhlihhnkhgvughinhdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonhdrohhrghdprhhotghonhhnohhrsegslhhotghkshhtrhgvrghmrdgtohhmpdgrjhesvghrihhsihgrnhdrtghomhdrrghupdfovfetjfhoshhtpehmohehvdelpdhmohguvgepshhmthhpohhuth
X-Mailman-Approved-At: Sat, 18 Feb 2023 19:01:11 +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: Sat, 18 Feb 2023 18:38:06 -0000
So with datacarrier we can store data in taproot annex with one tx which
will be data and/or extension of the script validation via PUSH_ANNEX
I looked at your links and plenty of others, but had some hard time to
find the proposal
(https://github.com/bitcoin/bips/blob/9dc3f74b384f143b7f1bdad30dc0fe2529c=
8e63f/bip-annex.mediawiki
I suppose), when do you think datacarrier can happen for real on the
network?
Now I think the OP_RETURN debate remains relevant, it's a quite trivial
modification to do, from my standpoint it is certainly not intended to
store big things (but 80B, what do you want to do with this?), but if
people want to store big things and pay for it... what is the real
issue? (I saw your argument of "partial" block validation and others
like skipping witness data, at the end nodes must validate the whole thin=
g)
Le 17/02/2023 =E0 13:49, Anthony Towns a =E9crit :
> On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-=
dev wrote:
>> Since bytes in the witness are cheaper than bytes in the script pubkey=
,
>> there is a crossover point in data size where it will simply be cheape=
r to
>> use witness data.
> Given today's standardness constraints, that's true (because you first
> need to construct a p2wsh/tapscript output that commits to the data,
> then you have to spend it), but it needn't stay that way. Allowing a da=
ta
> carrier entry in the annex (as contemplated for eltoo [0]) would allow
> you to publish the data with a single transaction, with malleability
> prevented because the annex content is committed to by the signature.
>
> [0] https://github.com/bitcoin-inquisition/bitcoin/pull/22
>
> I think the cost for publishing data via the witness today is roughly:
>
> 115 vb - for the commitment tx
> 115 vb + datalen/4 - for the publication tx
>
> versus
>
> 125 vb + datalen - for a tx with an OP_RETURN output
>
> so the crossover point is at a datalen of about 140 bytes. Perhaps
> slightly more or less depending on how much you can combine these
> inputs/outputs with other txs you would have made anyway.
>
> With a datacarrier in the annex that has similar or higher limits than
> OP_RETURN, I don't think OP_RETURN would ever be cheaper.
>
> The other advantage to using the witness for random data compared to
> OP_RETURN is that the txid commits to OP_RETURN output, so you must
> download all OP_RETURN data to validate a block's merkle tree, whereas
> you can partially validate a block (in particular, you can validate the=
> spendable utxo set) without downloading witness data [1].
>
> [1] https://github.com/bitcoin/bitcoin/pull/27050
>
> Cheers,
> aj
--=20
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ay=
ms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b=
eed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac=
tions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.p=
eersm.com
Peersm : http://www.peersm.com
|
