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
|
Delivery-date: Thu, 02 Oct 2025 09:17:28 -0700
Received: from mail-oo1-f63.google.com ([209.85.161.63])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDI23FE35EIBBCWL7LDAMGQE3X46JIQ@googlegroups.com>)
id 1v4Lzj-0007iD-H6
for bitcoindev@gnusha.org; Thu, 02 Oct 2025 09:17:28 -0700
Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-6448ae9de5bsf1255767eaf.0
for <bitcoindev@gnusha.org>; Thu, 02 Oct 2025 09:17:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1759421841; x=1760026641; 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=ag7Rx93r5D/G+zqPYV224euvTde8KkSo/kfBIrVaYv8=;
b=n5kDyp/+vBSqcHV06j9/ZNW2KBcNiwV/G5YBeETJZEzU0DDaf/RPzEEGQ+7Of//J96
egWUDA6Xubi8EcTIwAVWvpcNxUPGyR2FlhtG0ZKrORW2UD5wsjeWDZxQ8SZvERU9ZIdO
imE0sS3+R5kn0F1i0RCbIDrNn4h2pZ1orkIU0rhM5oBd2TReEtuiMQUmJouxcgG9en0b
Q4AxGLx4XrPMHIZF068zqUdxTA3V9pasTC8zgpPg1+RAo7lSKcAAYF2J+R06od4Y/Z2U
bjZAmQfSmCHPmaEc8qq0kNJPlX39ZPzzwbeNefsPrErhaffsenMxQtUgMMePZW7GTIEf
6ECg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759421841; x=1760026641; 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=ag7Rx93r5D/G+zqPYV224euvTde8KkSo/kfBIrVaYv8=;
b=G7TDhGdJhZkxUQqrtUygdSiPLB1QgR5KxivizLn3Nc7uBd9CMTAEaQ4BPRay4KC0dH
bzzRHQO1Fjjp2UpTLI50ME+q3F1B3d1w3vyBLLJ4JYqqRNZDT+cqTIN50bd2Odx48/Eg
+wQZrMzmlo0eYyueelt5FZdwED2DHxDEKmXXVPQGGJk57QQnmdpEgDh5lxy2viYYfcwc
Z8Ga5xolO2HgC7sdAqInoX4peFpRp3AYves2ZS4NuyJt/5thgeTUdZlQH8CibCtdM+qV
3jyUX41Z68nUYj7rgad+vCFHLLQNwCUGN21qEAgHGCSaDxaQsCitzvTojII1lCFFvNZM
XENg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759421841; x=1760026641;
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=ag7Rx93r5D/G+zqPYV224euvTde8KkSo/kfBIrVaYv8=;
b=iqguje8FrTM7Izyourz3N96AbAnrLcJb0+q7H1KugQLdNM3z8/0dzoPkuYhV+28Yb4
ulDjssfmkPe+ft/j8pKWRyzCDtpZWeipuMoxvS2qkOEUgYIHFUdiFEtndacxIFPezmRF
3NBrF0s9IebzNmcWpQQrTLBFDnkiPeETncvGmwMzJZcEkHMkdfV3qUtsI+BRnTTrbX5B
U07PO3PGS+j9G9rAW4zYxcs9+kUcCJ88hu5MDEv20abFYGPkrTqqAasVXrkPaBtZhY2u
sd29QE8dVk5epR8KGOQ3bAYHzWYf67KpN7Ou9QdVWkZVG3IaeIqmyDnp3tUDKwHEkYvK
ZhHw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUP+kC0mbusKaFu1jZxvyBdPRhg7+2Cp2wdEF+WqtCbUwOG69wxSlfMttwWuJReZdJib1D3vJvX5MRk@gnusha.org
X-Gm-Message-State: AOJu0Yyc9479zY9q+FAwmnMiyTfaJtumQ6jTjlXbOwwkd1Lp+5YQErbB
uQnrJ5nE4nJ1Xu5/xD+CzZt17CGG87n4bWJ+QBzJFfAuO4BwhwRGeuyT
X-Google-Smtp-Source: AGHT+IH3JX3Y+ldjzHNnrLfYYPB943x7LUqbDjFXk6viw5jenm20Tua8JE6aMe1CRB5mAAkKF6pC6Q==
X-Received: by 2002:a05:6870:a18b:b0:356:a211:e445 with SMTP id 586e51a60fabf-3b0f470a2b9mr107281fac.18.1759421840591;
Thu, 02 Oct 2025 09:17:20 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4RaHjZKJ83h67l7NmGpvQexgqa8T5kJWyQViUueeKeGA=="
Received: by 2002:a05:6871:a219:b0:34c:97cf:52e with SMTP id
586e51a60fabf-3ad2826644bls305746fac.2.-pod-prod-02-us; Thu, 02 Oct 2025
09:17:14 -0700 (PDT)
X-Received: by 2002:a05:6808:1710:b0:43f:9c1d:ae82 with SMTP id 5614622812f47-43fa40be4a3mr3573097b6e.2.1759421834778;
Thu, 02 Oct 2025 09:17:14 -0700 (PDT)
Received: by 2002:a05:690c:3383:b0:720:768:1935 with SMTP id 00721157ae682-77f9419d23cms7b3;
Thu, 2 Oct 2025 08:56:02 -0700 (PDT)
X-Received: by 2002:a05:690c:2608:b0:739:b67c:fcc6 with SMTP id 00721157ae682-77f942b14e2mr1201007b3.17.1759420561636;
Thu, 02 Oct 2025 08:56:01 -0700 (PDT)
Date: Thu, 2 Oct 2025 08:56:01 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <cf15c24e-18d0-4221-a3d4-4177c82a6381n@googlegroups.com>
In-Reply-To: <2e366b25-f789-4c9d-acf9-b87149d6a796n@googlegroups.com>
References: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
<CAAS2fgQRz=EJ+Nm2rxrB_SEpqroFbcc+hUhmghJJ1jrJc-WUDA@mail.gmail.com>
<aN21KbXTORgXAVH0@mail.wpsoftware.net>
<2e366b25-f789-4c9d-acf9-b87149d6a796n@googlegroups.com>
Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_295280_39685520.1759420561201"
X-Original-Sender: ekaggata@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_295280_39685520.1759420561201
Content-Type: multipart/alternative;
boundary="----=_Part_295281_1049530429.1759420561201"
------=_Part_295281_1049530429.1759420561201
Content-Type: text/plain; charset="UTF-8"
> > 12% embedding rate
> Where do you get that number from? 33% for embedding 256 bits in (P, R,
s) (but as per this discussion, according to me, at the cost of key
leakage). If we include the other bytes in a (taproot anyway) utxo that's
not much less, I guess 30% ish. I could try to guess but it'd be easier if
you told me :)
Thinking about it again: to publish data, you have to publish a
transaction! I guess the most economical, paying taproot to taproot, is
about 192 bytes with script path plus the posited extra 64 for the (R,s) in
the output, so yeah that'd be 32 out of 256, 12.5%. Isn't the figure a bit
different for key path though, because no control block? Well it hardly
matters, it's some small fraction in that range.
An interesting mechanical detail in this near-absurd scenario is that if
you wanted to repeatedly publish off the same (presumably a few multiples
of dust level) output, you couldn't also do the leak single key thing,
since you'd lose control to re-spend. So that'd place us in the "explicit
multisig" scenario that Greg mentioned, which I think would only make sense
with legacy script? Kind of a different scenario, also it would be really
weird to update legacy script to take into account a new "you must sign the
pubkeys" rule. Though I guess in this fictional scenario, it might happen
like that. If you did do it with legacy, you'd be publishing bare 2 of 2
multisig. If you did it with taproot due to how that works, the script is
not published until the output is spent, so I think that's outside what I
was considering ("data in utxo set"). (I guess you could also use something
like a hash lock which might be more efficient). So anyway if you wanted to
do this repeatedly and minimize cost, for whatever strange reason, you'd be
adding another 50-100 bytes each time bringing that % down to like 10% or
less.
But that all became way too hypothetical to even analyze properly :)
Anyway just to reemphasize I certainly wasn't advocating this sig-attaching
system, but it seems important to know what the result of it would be: we
would still not have changed the obvious reality that embedding data in
witness gives more space for data, and is more economical, and we would
only reduce by a big factor how much can be embedded in outputs (anything
from 8% to 15% embedding rate seems possible depending on the hypothetical
details), while having to screw up much of Bitcoin's functionality in the
process.
Cheers,
AdamISZ/waxwing
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegroups.com.
------=_Part_295281_1049530429.1759420561201
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> >=C2=A0=C2=A012% embedding rate<div>> Where do you get that numb=
er from? 33% for embedding 256 bits in (P, R, s) (but as per this discussio=
n, according to me, at the cost of key leakage). If we include the other by=
tes in a (taproot anyway) utxo that's not much less, I guess 30% ish. I cou=
ld try to guess=C2=A0but it'd be easier if you told me :)</div><div><br /><=
/div><div>Thinking about it again: to publish data, you have to publish a t=
ransaction! I guess the most economical, paying taproot to taproot, is abou=
t 192 bytes with script path plus the posited extra 64 for the (R,s) in the=
output, so yeah that'd be 32 out of 256, 12.5%. Isn't the figure a bit dif=
ferent for key path though, because no control block? Well it hardly matter=
s, it's some small fraction in that range.</div><div><br /></div><div>An in=
teresting mechanical detail in this near-absurd scenario is that if you wan=
ted to repeatedly publish off the same (presumably a few multiples of dust =
level) output, you couldn't also do the leak single key thing, since you'd =
lose control to re-spend. So that'd place us in the "explicit multisig" sce=
nario that Greg mentioned, which I think would only make sense with legacy =
script? Kind of a different scenario, also it would be really weird to upda=
te legacy script to take into account a new "you must sign the pubkeys" rul=
e. Though I guess in this fictional scenario, it might happen like that. If=
you did do it with legacy, you'd be publishing bare 2 of 2 multisig. If yo=
u did it with taproot due to how that works, the script is not published un=
til the output is spent, so I think that's outside what I was considering (=
"data in utxo set"). (I guess you could also use something like a hash lock=
which might be more efficient). So anyway if you wanted to do this repeate=
dly and minimize cost, for whatever strange reason, you'd be adding another=
50-100 bytes each time bringing that % down to like 10% or less.</div><div=
><br /></div><div>But that all became way too hypothetical to even analyze =
properly :)</div><div><br /></div><div>Anyway just to reemphasize I certain=
ly wasn't advocating this sig-attaching system, but it seems important to k=
now what the result of it would be: we would still not have changed the obv=
ious reality that embedding data in witness gives more space for data, and =
is more economical, and we would only reduce by a big factor how much can b=
e embedded in outputs (anything from 8% to 15% embedding rate seems possibl=
e depending on the hypothetical details), while having to screw up much of =
Bitcoin's functionality in the process.</div><div><br /></div><div>Cheers,<=
/div><div>AdamISZ/waxwing</div><div><br /></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" 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/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegroups.com</a>.<br />
------=_Part_295281_1049530429.1759420561201--
------=_Part_295280_39685520.1759420561201--
|
