summaryrefslogtreecommitdiff
path: root/3b/6f85b443ffeaaa3c34d52ccc796edc439ddd17
blob: 6ba8bb8a67a6045d9f6de60df6fc5a3309d71ff7 (plain)
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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
Delivery-date: Mon, 05 May 2025 17:07:14 -0700
Received: from mail-yb1-f189.google.com ([209.85.219.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCJNLJPWXAIBBJ5F4XAAMGQENLBXOCI@googlegroups.com>)
	id 1uC5q5-0002Uc-4o
	for bitcoindev@gnusha.org; Mon, 05 May 2025 17:07:13 -0700
Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e732864473dsf7098847276.0
        for <bitcoindev@gnusha.org>; Mon, 05 May 2025 17:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746490027; x=1747094827; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=JclWrx9nC0DMEpS7+dN1QosUvwv/1juMMcFsYAk6dfU=;
        b=XuOrDnhdh9xbsUyfCEciiaDu6wxoACT2V1+WU6PwJNIFeslJccF06GviFEJ7sLzjDo
         p3VjTLUY5U8qRbRm5JMXts5E89nfu2xRMQ8VNa8E3e6OcaEkfBlGVsQ92XpoYSVO0c3A
         0vF0rFFXVSZVkfVMGhi3BpvzcOJE0cAjHaVDfy2LPLoEb9u/H9NJugXcxfKuGYTNkK6V
         IgJbdE+s3B11meYRGnh9w/bsoFBRbp0nm64xreRUDfVCWlJcrgevBEXypp//phR5orkO
         G0mR+urMxcDc61jW/uEp3dpcMu1n0jpcL6qq6pHcVTa9iXsHolN1ks4aMU63OiH59VKR
         Gumw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746490027; x=1747094827; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=JclWrx9nC0DMEpS7+dN1QosUvwv/1juMMcFsYAk6dfU=;
        b=Y9DNrs7OslWvDSzAbjdCrbNCRqyZNjDz+TqlaQeqV5E0JBSK+vzcLQvbONhTqTrd/1
         P2MlGVvbSAvVVLMi1SrarNPgVWQtk6SU2L++2OA8hESeN3/vLZVpLth7U5gqbVRC5gau
         zyx4/6YQBMGZ3J9kh59LWDH4TeG78BjObxaegMD3ZUTkF2kxepbrJ/rWpPar0N9eydL8
         VSXKyRWUMQu9IfhhUEKIdhzqX83Rt2EIpbCMAxanAxK+FMtm43RAJTdk3tdamNab/aHk
         DY+eBOYkAPbWFyrTaC0Wjmt4mBJWj3nPANa+LI0TOOVEOJ5OM2KH/zt2IvvdyoCZ6iJc
         UPuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746490027; x=1747094827;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=JclWrx9nC0DMEpS7+dN1QosUvwv/1juMMcFsYAk6dfU=;
        b=grscI97TQwwNedkMBAqmROCq4VHLuX9znN3ov8yRvKtop74IkAcJpr20E6tfzjCGGb
         pezjt0OEE3GEqXVtFxmISl7Th2RdXl2NuwKFp+RpX4Sb4VG0DGEtnNcNcB9X9ZeNa1wo
         bXf1iLTenFjcZ9TQryXmf+vb4jmKRpwbMkotS/6Npw9eTSjtN+6Cxrca+YoEj6mIzjyI
         xi645bvyfKwPzfv1/tzw06C4WR2oDnUU6KuyqQeGdlhqi5gk+VJ+zryAfX4Tnl6A73KH
         xwL9WRNKAa8e8B3oOyVM0YqMo7AFL5y5yw5abN2xpG1dh02VnlidMIg+il8+ddAl+scc
         dLMQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWNEFmLignCkEnXRgOeZxMwD3gaeTeK5ipL7elrT8on5TN8yPhPMegdAg2b4Z2UGhcJ3XJJSvj+CUnF@gnusha.org
X-Gm-Message-State: AOJu0Yy/Digt9hKYqfbmwQofWMFSY++8wJcFQWYymNcEM5Lccua0Cndm
	MJPQDpERPWa3QuZmur/2sGxpnYvArAcPNaEaUlRnGxOkTlOU0zJT
X-Google-Smtp-Source: AGHT+IEaLbXJ/ynH07Pr53xufTR35qOE3ELH1AMRwMgcq8EnU4UCeEoTtWGF3xCv45GFWLpYNpykGQ==
X-Received: by 2002:a05:6902:188a:b0:e73:2c64:5666 with SMTP id 3f1490d57ef6-e75656271f6mr17687829276.35.1746490026762;
        Mon, 05 May 2025 17:07:06 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEZXQY3H7MYxnLhnX9xSS2bs8Fn5WRw56jpZ/980yOPFA==
Received: by 2002:a25:aae8:0:b0:e75:60d4:326c with SMTP id 3f1490d57ef6-e7560d43309ls422640276.1.-pod-prod-06-us;
 Mon, 05 May 2025 17:07:03 -0700 (PDT)
X-Received: by 2002:a05:690c:688b:b0:6f9:525d:a096 with SMTP id 00721157ae682-709197aa3a7mr15840187b3.3.1746490022968;
        Mon, 05 May 2025 17:07:02 -0700 (PDT)
Received: by 2002:a81:d448:0:b0:706:b535:945d with SMTP id 00721157ae682-708cfda3e38ms7b3;
        Mon, 5 May 2025 16:55:35 -0700 (PDT)
X-Received: by 2002:a05:690c:4446:b0:6f2:9704:405c with SMTP id 00721157ae682-709197c9862mr18215407b3.15.1746489334669;
        Mon, 05 May 2025 16:55:34 -0700 (PDT)
Date: Mon, 5 May 2025 16:55:34 -0700 (PDT)
From: Greg Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <47079bf1-19de-4354-880d-2d197cecb0a2n@googlegroups.com>
In-Reply-To: <aBkxapFiBxC_TeEy@petertodd.org>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
 <aBUlEOBqqrOIGHWC@petertodd.org>
 <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com>
 <aBkxapFiBxC_TeEy@petertodd.org>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's
 Advocate Position
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_353888_2086395228.1746489334304"
X-Original-Sender: gmaxwell@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_353888_2086395228.1746489334304
Content-Type: multipart/alternative; 
	boundary="----=_Part_353889_1612303690.1746489334304"

------=_Part_353889_1612303690.1746489334304
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, May 5, 2025 at 11:39:02=E2=80=AFPM UTC Peter Todd wrote:

When you originally proposed the scheme that may have been true. But=20
these days you could probably use zero-knowledge-proofs to prove that=20
hash digests are in fact hash digests, without having to include the=20
actual pre-images of those hash digests.=20


The schemes that I'm aware of mostly have huge side-channels in the proof. =
=20
I think I constructed one before that didn't have one for proving bilinear=
=20
keys, and it only proved a pubkey was a pubkey, but at best it's an extra=
=20
constraint.

Goes back to what you're trying to accomplish, like assume network capacity=
=20
to process/forward blocks as a fixed amount. Your concern with NFTs is them=
=20
driving up fees. So now every transaction has to carry a proof its not=20
embedding a jpeg and so the effective throughput of the network is halved=
=20
or reduced by 30% or whatever from the proofs.  Not a win.  And of course=
=20
were then imagining something with more cryptographic complexity than the=
=20
whole of bitcoin just to close high bandwidth channels.  And low bandwidth=
=20
channels on the order of 24 to 32-bits per independently adjustable piece=
=20
of data still exist.


But Amazon doesn't offer a service to store data on S3 forever.


It doesn't my example was an economic analysis that just assumed you bought=
=20
an investment to yield enough to pay for the S3.  If you actually want it=
=20
you can construct it as a legal entity.

Also of course, S3 only offers storage. Not publication. Things like=20
Citrea (and Lightning) specifically need data publication.=20


Right I might have been unclear.  Some people are laboring under a mistaken=
=20
belief that the objective of people putting large amounts of data in the=20
blockchain is just to "store stuff" --- and my point is that it's=20
outrageously uneconomical for that.  While there may be some on the margin,=
=20
the reality is that people storing something believe they're getting some=
=20
benefit out of doing it that they don't get from an actual storage=20
solution.  On reddit I went over a few=20
examples:  https://old.reddit.com/r/Bitcoin/comments/1kea81d/why_is_this_su=
b_quiet_about_the_current_debate/mqi0vfw/

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
47079bf1-19de-4354-880d-2d197cecb0a2n%40googlegroups.com.

------=_Part_353889_1612303690.1746489334304
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">On Monday, May 5, 2025 at 11:39:02=E2=80=AFPM UTC Pe=
ter Todd wrote:<br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">When you ori=
ginally proposed the scheme that may have been true. But
<br />these days you could probably use zero-knowledge-proofs to prove that
<br />hash digests are in fact hash digests, without having to include the
<br />actual pre-images of those hash digests.
<br /></blockquote><div><br /></div><div>The schemes that I'm aware of most=
ly have huge side-channels in the proof.=C2=A0 I think I constructed one be=
fore that didn't have one for proving bilinear keys, and it only proved a p=
ubkey was a pubkey, but at best it's an extra constraint.</div><div><br /><=
/div><div>Goes back to what you're trying to accomplish, like assume networ=
k capacity to process/forward blocks as a fixed amount. Your concern with N=
FTs is them driving up fees. So now every transaction has to carry a proof =
its not embedding a jpeg and so the effective throughput of the network is =
halved or reduced by 30% or whatever from the proofs.=C2=A0 Not a win.=C2=
=A0 And of course were then imagining something with more cryptographic com=
plexity than the whole of bitcoin just to close high bandwidth channels.=C2=
=A0 And low bandwidth channels on the order of 24 to 32-bits per independen=
tly adjustable piece of data still exist.</div><div><br /></div><div><br />=
</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;">But Amazon doesn't offer a servic=
e to store data on S3 forever.</blockquote><div><br /></div><div>It doesn't=
 my example was an economic analysis that just assumed you bought an invest=
ment to yield enough to pay for the S3.=C2=A0 If you actually want it you c=
an construct it as a legal entity.</div><div><br /></div><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;">Also of course, S3 only offers storage. Not publication.=
 Things like
<br />Citrea (and Lightning) specifically need data publication.
<br /></blockquote><div><br /></div><div>Right I might have been unclear.=
=C2=A0 Some people are laboring under a mistaken belief that the objective =
of people putting large amounts of data in the blockchain is just to "store=
 stuff" --- and my point is that it's outrageously uneconomical for that.=
=C2=A0 While there may be some on the margin, the reality is that people st=
oring something believe they're getting some benefit out of doing it that t=
hey don't get from an actual storage solution.=C2=A0 On reddit I went over =
a few examples:=C2=A0=C2=A0https://old.reddit.com/r/Bitcoin/comments/1kea81=
d/why_is_this_sub_quiet_about_the_current_debate/mqi0vfw/</div></div><div><=
br /></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/47079bf1-19de-4354-880d-2d197cecb0a2n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/47079bf1-19de-4354-880d-2d197cecb0a2n%40googlegroups.com</a>.<br />

------=_Part_353889_1612303690.1746489334304--

------=_Part_353888_2086395228.1746489334304--