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
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
|
Delivery-date: Sun, 20 Jul 2025 18:50:57 -0700
Received: from mail-ot1-f55.google.com ([209.85.210.55])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDSJ7DXSQ4PRB5NZ63BQMGQED6DCJBA@googlegroups.com>)
id 1udfg9-00057g-5H
for bitcoindev@gnusha.org; Sun, 20 Jul 2025 18:50:57 -0700
Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-73c88fe25a6sf1598638a34.3
for <bitcoindev@gnusha.org>; Sun, 20 Jul 2025 18:50:56 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1753062651; cv=pass;
d=google.com; s=arc-20240605;
b=lrYeiVe4Gnx7jS3OS7UR/fMwcxKAV2m4XxS04IK+IS5WTi1eIYXAadK6UoHF0RG2k9
zVfpV2VI+fbH2fhNtyAA/tzAzp+xs7RGPzprwQm3/XoBSFAYQB2NXhm1Zi3pM8WlVOeR
m9uOWrsiwMb0BnyLCuFLMNSO+y1hf871y1xd/O4mYqvKwyLQ+9hW0FQwulLGDKd+bda5
+NP1KyohsmbIL0CMQwicnDY4UAXMVjW3TIIP3mZ3zEnP75PaclyAyfQaYk3I9IovPLt1
VOHvvlvVDUG7fPds2hR5bn4FD+HDBYHgzkn6gO2vI+Bs5EI/oa82fuY5kV1YgjA9RMKl
B+bA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:to:subject:message-id:date:from
:in-reply-to:references:mime-version:sender:dkim-signature
:dkim-signature;
bh=VQTI0LbPyr9fU3dMS6dyTPsc7cPBD8rmzicydgZrvJE=;
fh=I2EBkRpHDgyaeEKfmwlP/mNP/C0haL0ylnH6PAwj12I=;
b=WVKGEo3SyDch6BTRVSLpnPAxFLUdYVKXyUgcGqVvoHf+vAUjJ8hDcvUlG32mS4Iamw
K3wXWZodWZ93H8a2E9wSqWEoVQGkrdco4cwpS4+mz5nV/o0BHpYjJaWq96xM/EE6N+/d
UV8yLtumf/6p5hTZTj9p5Prc8x7cphSGkULhTdRd1mY0Xn3idq6IQnv3Q2clrZA/7hFT
sm25v/Fc3wZ5Zqgrvw+G2bS5a2z2/gnC+OwNAS3Dp0j5OypZ2lLwlI2OscFvX4aH1l4a
V07wuUkwG5kRcK2Q/D3yB1iMxPXETr5ZkzGEcBm53/vrRwu9wBmTpPkv2fW+PfSqDM+J
ec2Q==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=N07O8Anr;
spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=eth3rs@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1753062651; x=1753667451; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:to:subject:message-id:date:from:in-reply-to
:references:mime-version:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=VQTI0LbPyr9fU3dMS6dyTPsc7cPBD8rmzicydgZrvJE=;
b=D9A58tP1YouEtX+fC8NPD3//5Aeof5sEegSHx3QnSreMlF5DpuKHlDHeOpaaDMXYkv
SWzVMts4WwaH1WVbQDdd1rwyMSQ+XpEkvPUDmL4GMNYS8KbwJd1PKjbnviPWiChGGKzJ
6q/CzBFvSGNrmQOgWuMjRjbLlL4h7BCwGQcSf2sVb8YA6PerQtDEqc5L9ZNuZ08Bc5X7
T6EKev8WL6yOYXMZC0E3Jvi4mC8TVzfS8SVIcGeDcc6SXHw6+uxD0vePdUy2ispxaiam
Ae65j52vRrEEWVDGC4P4iN9Uz1eWrcXOngYx4UJJ4ZbumIpORyaoezKaGcRUrY34Jues
eZCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1753062651; x=1753667451; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:to:subject:message-id:date:from:in-reply-to
:references:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=VQTI0LbPyr9fU3dMS6dyTPsc7cPBD8rmzicydgZrvJE=;
b=YtNCs+C1jCw7jdzRck4CCLAbKF2ZSXYwTG3/Qk0ssObYNRUwbrEfBpku0+GQB40Yzx
kR8cnMD3XI8Zzo4eNoDnTozBH9RaYFnNjg4fwQEJ1E7/66Qa8pcqhxNGF2l1GMVS71N9
BBpHhv4P3lA56EwBXN5OHWM7QpvjoEmVIEBBZhq1cJ7bM7dnDMn4vShvAyf/nG9jIcEf
5xvsfTmdIJUYj3pzhMIeBxamS86tTeGPTfgYY3OMwEokBKeyIynaYQTVkVQKtR2s87CZ
d1E9LqhfARyGjvPxA5x2fws6AkYwhcitFAxlCvMut1WSDpoJouv+OG1AmbcrBVA7w1jj
U7AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1753062651; x=1753667451;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:to:subject:message-id:date:from:in-reply-to
:references:mime-version:x-beenthere:x-gm-message-state:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=VQTI0LbPyr9fU3dMS6dyTPsc7cPBD8rmzicydgZrvJE=;
b=T7axAn64OSxB+AMWOlSzJx9sb7+idz14KnQclxc4wJgE4D/kJpsk9V1eLnfLwpBrN+
zMKJC8SwJQhS+3KMKCWLNxVfnqnDSEHgGKhKaxy6tAgcqxJ60qw6Xs9XMj6HtVdBEVV+
D1bPb6z/o1tdH47MrFKYoDbDgjieyqqTsIyF7Dh6o2Wu1J5nMKA7L5Gz5ogbzU3c6j2y
Ev7Qti19BtoQS3brGOr5Sdj4oI04oErZ1oi5/2xWPkvaL67JH4MOo5pURWEW8ol3ECfn
v8wjMT/NjOPHqe7ehrCqiJ9d4G3yhmIIOxZEDd3Xt3L+IQOVv6NdhRplKf4NJtoLKu3A
FdJA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUsR56H5qrvCJr2tkqWN7didBBM8dWsMzMk3Svd0WoshXGRBUTBpkTfnz3AjvCiPRIns2M9TEx10+nF@gnusha.org
X-Gm-Message-State: AOJu0YzT+5QIk1G0Z0Ur5F5CjebSKsV4fUc/V2Pqk0ajKP5+slcdaSP+
lQ7zrm2ZNOOPj1nOyNRdQorDhKLgug3x9+wzC2/nbDSTWRYNFHqZvU8u
X-Google-Smtp-Source: AGHT+IFqCRLDZ27/9YidTWARkvowBszcNmIgvmwCD2rgXEvfbSisEUQX+Tg2X88kAB4h1oGAbRTluw==
X-Received: by 2002:a05:6870:56ac:b0:2ff:a3d0:e404 with SMTP id 586e51a60fabf-300e8c5de35mr6517465fac.2.1753062650565;
Sun, 20 Jul 2025 18:50:50 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeS3s/Rj5F+fK1fbkPdOrpUoUn2ivoLIxX1B2kZuaMdMA==
Received: by 2002:a05:6870:343:b0:2ef:3864:284c with SMTP id
586e51a60fabf-2ffca945753ls1494371fac.1.-pod-prod-04-us; Sun, 20 Jul 2025
18:50:45 -0700 (PDT)
X-Received: by 2002:a05:6808:2209:b0:41c:5859:e7ae with SMTP id 5614622812f47-41f972893cfmr8344139b6e.16.1753062645549;
Sun, 20 Jul 2025 18:50:45 -0700 (PDT)
Received: by 2002:a05:6504:40d6:b0:2b1:97ca:fe9d with SMTP id a1c4a302cd1d6-2bae89a2159msc7a;
Sun, 20 Jul 2025 18:44:43 -0700 (PDT)
X-Received: by 2002:a05:651c:3cf:b0:32b:8e4a:5710 with SMTP id 38308e7fff4ca-3309a5ad22bmr35197541fa.34.1753062281388;
Sun, 20 Jul 2025 18:44:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1753062281; cv=none;
d=google.com; s=arc-20240605;
b=jLl4012hcnlFlNCkg051J/pCMxTyQ1d6RvuKfNqhz2FqcLkNtcHCKEsISjG6SYNWm+
NayhvsitZvq6bqSzeoGdhowo+i80pRRgJzcLzGywgpBDn1v6zxBG3WloNFb/LneuARy7
bHV7UnkKs7wz/INaligTXKZGPiZnXgZekETpNLsXxys+i5NTnaJC8QmEhHJrLon9SDnR
h5khlXcMe5zcWUwLHLSmjB6qvA8BLXulowv7HbSuyN04vKgvVX27hcUmXfgNZPHmrFJy
0k8/Coe7t+17e5yRwisSnMnvtPesX2RIl2K8UxClVu1CORFuhq4cvMJbJSS2+GkG/h1c
JVow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:dkim-signature;
bh=4DpI+lmN3Jf/2yhJ9weUhcsKWD7aBIef5gDo88RH6X4=;
fh=/SQqOftgQlaxYAuzqasQAR2hakFW6YnLPSFjK3E+dbQ=;
b=LoGSSGplDUrinr6JrzvUcOkK1upGIJBs3zfgyKMHO87YBFHC915QECyJf2KJpiGj3j
BtnGd41CztN/OVXTcPiLHozN5+uBkEKL0Swa3OjM9GMKe8Me/jotimAHvMa8mafvgpMX
ZMVJJCq9AFAzGt9QwADQiwN+YQ7cy8YTd40AgioDBtDBAEX5RDXohHISa9xBofHat/2i
yr+yppHgZrhdvNvCcKIV9p2LcKZn7S5opOP0p539fpq0LIO96kDYmKp2Thtjv3O/bbQz
wk5lUYCeys48dkF0S3amjDkr13lhxZS3FwJsKdkzzFDsVEoPp+gS6FUeCZjZWbyVgZbt
wr/A==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=N07O8Anr;
spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=eth3rs@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
dara=pass header.i=@googlegroups.com
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com. [2a00:1450:4864:20::531])
by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-330a918d7dcsi1035451fa.4.2025.07.20.18.44.41
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 20 Jul 2025 18:44:41 -0700 (PDT)
Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) client-ip=2a00:1450:4864:20::531;
Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-607cf70b00aso6915790a12.2
for <bitcoindev@googlegroups.com>; Sun, 20 Jul 2025 18:44:41 -0700 (PDT)
X-Gm-Gg: ASbGncup3+bfONoP6m3H+jfSOhL1IX5oyLkJbFst9z9xP/2NhzOm4k3ahXNtlPflKi7
iJiknyo7/SiIBZ3h2gSjWi54zrfhHYjgudZ/vmU1U/K2my6eZ+2DicSOVQVlfjp/e+o03vvWnsE
Eq04hCqVPMr8pFqAmTCrEVJ2haj+w9lOn9DYWWAdEIsCSKLI5ok8LvU/iPotbHHnKa/UDasGtte
ZE7Fia0WFvy6JOvWchxMOHASBA+f+W519XL9r56
X-Received: by 2002:a05:6402:2554:b0:60c:3f77:3f4a with SMTP id
4fb4d7f45d1cf-612a4d160bfmr12862215a12.4.1753062280181; Sun, 20 Jul 2025
18:44:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAEM=y+WkLOVJ787jjr5zZgKsAHxHkgdZjANqGycEh4K7ZSddSA@mail.gmail.com>
<-k1KNMwmXrdmMxpxMeJHAOYuKpMfeUpx7rqfIkta_NC6f7MtzlOYEdXbAhi-SztejTidNysh40ask8j9JNrzxoh1sUCH4F9tKV6tarkrWrc=@proton.me>
<CAEM=y+WUpbzJBU6nYyM5Lj3ByD199Fxubvc50uqkv8uEd7GJtA@mail.gmail.com> <CAAS2fgR+XccLeZqt0GXP=b-cu9ya=-pVZred_q6xGCrNKMLy9g@mail.gmail.com>
In-Reply-To: <CAAS2fgR+XccLeZqt0GXP=b-cu9ya=-pVZred_q6xGCrNKMLy9g@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Sun, 20 Jul 2025 21:44:03 -0400
X-Gm-Features: Ac12FXzeAnJljpFwwPBQ7ZjJTrT3kdcMJdL0geXHoNaWNDJWcTs50S1_HTA2ZkU
Message-ID: <CAEM=y+UJJ9R5ACxNg=B2HcnBZMxf+KoWtkvH1yFgRcU56hms8g@mail.gmail.com>
Subject: Re: [bitcoindev] Human meaningful witness versioning
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>, Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007abd83063a669ed4"
X-Original-Sender: eth3rs@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@gmail.com header.s=20230601 header.b=N07O8Anr; spf=pass
(google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::531 as
permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE
sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/)
--0000000000007abd83063a669ed4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
When I was trying to understand BIP 0173, I came up with five ways to do it=
:
1. Don't treat the Witness version as a special part of the address. Just
encode the ScriptPubkey.
2. (Bech32 approach) allocate the first 5-bits to Witness version. This
lets you do versions 0 to 31 before the Witness version spills into the
next character. As you note this saves 3-bits, because you are compressing
the 8-bit opcode into 5-bits.
3. You could take the Bech32 approach a little further and save an
additional 8-bits by not including the OP_PUSH32 and just inferring it from
address length. Granted this length inference would present issues if we
want to do more complex things in the ScriptPubkey, but we could handle
these cases with Witness versions like we do with bech32 and bech32m.
4. Allocate first 4-bits to Witness version. This lets you do 0 to 15
before the Witness version spills into the next character.
5. Put checksum as the first character after bc1 so the Witness version
isn't the next character after the human readable component of the address.
This would discourage people viewing the Witness version as part of the
human readable component.
1,4,5 obscures the witness version. 3, does not obscure the witness version
but saves at least one character. Why compress the Witness version to fit
into 5-bits but not the OP_PUSH32 (or OP_PUSH20)? My assumption until today
was that the original reason for 2 was to make the Witness version human
readable, but since that isn't the case and it was just about the number of
characters, why not drop the OP_PUSH?
Option 5 and dropping OP_PUSH32 seems best to avoid address confusion.
> The reason it's 5 bits is just to avoid needlessly inflating the length
of addresses.. as additional versioning, if someday required could be
achieved by additional words in the payload.
How would we encode the Witness version beyond 16, `OP_16, OP_0, OP_PUSH32,
32 bytes` or `OP_PUSH0, 0x00, OP_PUSH32, 32 bytes`?
On Sun, Jul 20, 2025, 18:38 Greg Maxwell <gmaxwell@gmail.com> wrote:
> On Sun, Jul 20, 2025 at 9:35=E2=80=AFPM Ethan Heilman <eth3rs@gmail.com> =
wrote:
>
>> Does anyone remember why BIP-0173 added a special rule to make Witness
>> Versions legible in this way? It might be useful to document here for
>> future discussions on address encoding.
>>
>
> I'm not sure what you're referring to there -- there needed to be an
> _encoded_ version for the purpose of consensus rules. 1xxx addresses hav=
e
> one, for example (which results in them beginning with 1). The reason it=
's
> 5 bits is just to avoid needlessly inflating the length of addresses.. as
> additional versioning, if someday required could be achieved by additiona=
l
> words in the payload.
>
> There is a _human readable_ part, but that refers to the "bc" prefix
> identifying the currency/network, not any of the technical minutia about
> how the system works. The reason for the human readable part was that
> there has been instances of funds loss caused by fork coins / altcoins th=
at
> copied bitcoin wholesale and used the same addresses and we'd hoped that =
a
> prefix that was easy to change an unambiguously associated with bitcoin
> would have a chance of reducing that risk in the future.
>
> or to restate: A recipient's script is fundamentally none of the sender's
> business (except for multiparty contracts or other special cases) -- and =
so
> generally we want the sender to be as oblivious of the details of the
> script as reasonably possible. If the sender has paid to the output the
> receiver has specified then they've done their part. Any further issues
> are the recipient's responsibility. If the sender hasn't-- e.g. say they
> took apart some address and made some custom script without the receivers
> consent, like turning a taproot pubkey into a legacy address-- then they
> haven't made a payment to the recipient and they still owe the
> recipient funds. But this also requires that the payment be on the right
> network, and while they could be informed outside of the address since it
> was a frequent cause of errors we thought it critical to embed it. The
> reason for making the embedding legible was primarily so that altcoins
> wouldn't just copy the prefix as they had frequently done with the versio=
n
> numbers.
>
> (and I believe so far this has proved to be successful, copies have
> changed the HRP)
>
>
>
>
>
>
>
>
>
>
--=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/=
CAEM%3Dy%2BUJJ9R5ACxNg%3DB2HcnBZMxf%2BKoWtkvH1yFgRcU56hms8g%40mail.gmail.co=
m.
--0000000000007abd83063a669ed4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto">When I was trying to u=
nderstand BIP 0173, I came up with five ways to do it:</div><div dir=3D"aut=
o"><br>1.=C2=A0 Don't treat the Witness version as a special part of th=
e address. Just encode the ScriptPubkey.<br><br></div><div dir=3D"auto">2. =
(Bech32 approach) allocate the first 5-bits to Witness version. This lets y=
ou do versions 0 to 31 before the Witness version spills into the next char=
acter.=C2=A0
As you note this saves 3-bits, because you are compressing the 8-bit opcode=
into 5-bits.<br><br>3. You could take the Bech32 approach a little further=
and save an additional 8-bits by not including the OP_PUSH32 and just infe=
rring=C2=A0it from address length. Granted this length inference would pres=
ent=C2=A0issues if we want to do more complex things in the ScriptPubkey, b=
ut we could handle these cases with Witness versions like we do with bech32=
and bech32m.</div><div dir=3D"auto"><br></div><div dir=3D"auto">4. Allocat=
e first 4-bits to Witness version. This lets you do 0 to 15 before the Witn=
ess version spills into the next character.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">5. Put checksum as the first character=C2=A0after bc1 s=
o the Witness version isn't the next character after the human readable=
component of the address. This would discourage people viewing the Witness=
version as part of the human readable component.<br><br>1,4,5 obscures=C2=
=A0the witness version. 3, does not obscure=C2=A0the witness version but sa=
ves at least one character. Why compress the Witness=C2=A0version to fit in=
to 5-bits but not the OP_PUSH32 (or OP_PUSH20)? My assumption until today w=
as that the original reason for 2 was to make the Witness version human rea=
dable, but since that isn't the case and it was just about the number o=
f characters, why not drop the OP_PUSH?<br><br>Option 5 and dropping OP_PUS=
H32 seems best to avoid address confusion.<br><br>> The reason it's =
5 bits is just to avoid needlessly inflating the length of addresses.. as a=
dditional versioning, if someday required could be achieved by additional w=
ords in the payload.<br><br>How would we encode the Witness version beyond =
16, `OP_16, OP_0, OP_PUSH32, 32 bytes` or `OP_PUSH0, 0x00, OP_PUSH32, 32 by=
tes`?</div><div dir=3D"auto"><br></div><div><div class=3D"gmail_quote"><div=
dir=3D"ltr" class=3D"gmail_attr">On Sun, Jul 20, 2025, 18:38 Greg Maxwell =
<<a href=3D"mailto:gmaxwell@gmail.com" rel=3D"noreferrer noreferrer nore=
ferrer noreferrer" target=3D"_blank">gmaxwell@gmail.com</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v dir=3D"ltr">On Sun, Jul 20, 2025 at 9:35=E2=80=AFPM Ethan Heilman <<a =
href=3D"mailto:eth3rs@gmail.com" rel=3D"noreferrer noreferrer noreferrer no=
referrer noreferrer" target=3D"_blank">eth3rs@gmail.com</a>> wrote:</div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr">Does anyone remember why BIP-0173 added a special rule =
to make Witness Versions legible in this=C2=A0way? It might be useful to do=
cument here for future discussions on address encoding.<span style=3D"font-=
family:Arial,sans-serif;font-size:14px"></span></div></blockquote><div><br>=
</div><div>I'm not sure what you're referring to there -- there nee=
ded to be an _encoded_ version for the purpose of consensus rules.=C2=A0 1x=
xx addresses have one, for example (which results in them beginning with 1)=
.=C2=A0 The reason it's 5 bits is just to avoid needlessly inflating th=
e length of addresses.. as additional versioning, if someday required could=
be achieved by additional words in the payload.</div><div><br></div><div>T=
here is a _human readable_ part, but that refers to the "bc" pref=
ix identifying the currency/network,=C2=A0 not any of the technical minutia=
about how the system works.=C2=A0 The reason for the human readable part w=
as that there has been instances of funds loss caused by fork coins / altco=
ins that copied bitcoin wholesale and used the same addresses and we'd =
hoped that a prefix that was easy to change an unambiguously=C2=A0associate=
d with bitcoin would have a chance of reducing that risk in the future.</di=
v><div><br></div><div>or to restate: A recipient's script is fundamenta=
lly none of the sender's business (except for multiparty contracts or o=
ther special cases) -- and so generally we want the sender to be as oblivio=
us of=C2=A0the details of the script as reasonably possible.=C2=A0 If the s=
ender has paid to the output the receiver=C2=A0has specified then they'=
ve done their part.=C2=A0 Any further issues are the recipient's=C2=A0r=
esponsibility.=C2=A0 If the sender hasn't-- e.g. say they took apart so=
me address and made some custom script without the receivers consent, like =
turning a taproot pubkey into a legacy address-- then they haven't made=
a payment to the recipient and they still owe the recipient=C2=A0funds.=C2=
=A0 But this also requires that the payment be on the right network, and wh=
ile they could be informed outside of the address since it was a frequent c=
ause of errors we thought it critical to embed it.=C2=A0 The reason for mak=
ing the embedding legible was primarily so that altcoins wouldn't just =
copy the prefix as they had frequently done with the version numbers.</div>=
<div><br></div><div>(and I believe so far this has proved to be successful,=
copies have changed the HRP)</div><div><br></div><div><br></div><div><br><=
/div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><=
/div><div><br></div></div></div>
</blockquote></div></div></div>
</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/CAEM%3Dy%2BUJJ9R5ACxNg%3DB2HcnBZMxf%2BKoWtkvH1yFgRcU56hms8g%40ma=
il.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/d/msgid/bitcoindev/CAEM%3Dy%2BUJJ9R5ACxNg%3DB2HcnBZMxf%2BKoWtkvH1yFgRcU=
56hms8g%40mail.gmail.com</a>.<br />
--0000000000007abd83063a669ed4--
|