path: root/6b/6bc571ed542c1a8bc40405d6ea7508f2c5d472

Delivery-date: Mon, 21 Jul 2025 10:27:52 -0700
Received: from mail-oo1-f64.google.com ([209.85.161.64])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDSJ7DXSQ4PRBDXR7HBQMGQEPXHWF4I@googlegroups.com>)
	id 1uduIp-0004py-Rq
	for bitcoindev@gnusha.org; Mon, 21 Jul 2025 10:27:52 -0700
Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-615b36d92e9sf2740682eaf.3
        for <bitcoindev@gnusha.org>; Mon, 21 Jul 2025 10:27:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1753118865; cv=pass;
        d=google.com; s=arc-20240605;
        b=Q80VuN+d8t7X1cy6pB+4LWcMM8tnnZtjPgvusNP9gxrn0ID+OCObzp6/GVCCyAEts3
         Tkfs/4pOBDR+KiyEkdlYIxUBoerbMRFvVbi5nwSP6pjvpfy/fCrlns/+ViWXGKWFv4Mq
         AZzkA//BvoPyuyr3WESEPBLPObGtlBU5ANaxBaBDDkEEUgu1xvfJ8Ru8qytIQDqSu5YW
         fYpgBc/1BMnrsSq5t/8H4BtBBGxUw5cPKCJ9mJbJK9hKQ464St7ol/9FzXn7Lbkcmu3p
         kIaUqfx6BxCxW5FVEN2CYXc+Gvhkb0AjVZvRm71TYbgO1jnH8qnNP/nhkeCJqjKN6hku
         cFgA==
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=otp/EhkCvAdn8Jge9kAcrmISOkf3n44Fiz4zJ6xfRc0=;
        fh=0P2Jx5qNW5RNVKgh5cZa8ze193Q3W7izKHka8wdceMs=;
        b=kWc6y1eEl2i5u22F0ncHmD9rIb05iDwpG0ZFmIX0hfGnXQt085rf3vGnGy43KgDVC5
         ThQQA/wIF0CrdZu5HDPQyjrgNR6rUV2kCQCztNHZmzUCp5q7jdjFGhiLv5LVIZLh8wBV
         W3tG0CEprdNRcesoNv5nHzbOWRVwDjua0qK6a93MVoEdCKrA2gfUzMkQqtqaWTkUiPQv
         6oUPUGWB1UQnWaIhtSpg0t2uz4mlBYgt3XdL1PFA6aaweeda3zOhpizn1SD9sz6X2mGR
         q0xJICy8qipdS5LBrDWexqxyXh7j8Iv2Lkk5Zi9uSHcNmsiYla26iQMbSiQM+mAYe2S4
         z5GA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=l0bcWyx7;
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52b 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=1753118865; x=1753723665; 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=otp/EhkCvAdn8Jge9kAcrmISOkf3n44Fiz4zJ6xfRc0=;
        b=uiPLSOw9UA4QBlHWqdOQuCbnNBG21uZuY1Lr5yGkkThdAqtGrmGeQwNeYqXqKb/QAE
         wSOrMsJxscImgOBbmuMNmr8rJWRlP7qv5ZrUGZEqYdoc1cJ/WbUpMB1myxY6EiyyFtlt
         4QRdJe4tB/W5wL93mAtwkwv4RrIoj2zHr8mJ0dcsRdY/Wffduvd9+T9z/AKn4+2diA2/
         Fx/vMHBMThRWbS/Qtt3rOr6ZvrIaYrNzXtqxdfF+OAJbMtnDaVXdFm1hbF235xa1pz0G
         +NSXLzDtOtLkd/TIvjDE2iAVC2q/AIYTkXvFC0OU6NPGI8dSPQP1pchGExtkubXaGyFh
         CwWw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1753118865; x=1753723665; 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=otp/EhkCvAdn8Jge9kAcrmISOkf3n44Fiz4zJ6xfRc0=;
        b=IqoC7MKpJxKhcpXKBb8O0Kq4gfck+B/DT1RDUMZNV4rM4ChRdfsWvh7bscunbwgnHK
         btNp1P5vLqgiVpYcZK3Sv/Zgg3HCvbkgSoxThYss4kBahZUqNsYWXn5H6yZTT+TIs+KY
         WYUJhhF4fbf1CUWRxyLYj30deXnCLRmccZJLoC34RRpZiTluPctqQBmiaWoNfV0j8kcG
         cAiNvYvcKou4MwqrgANC7Q7fJW42HGAzNa8bmLYGUqgic/4Bz0P4L8stHkw/PAbMsTmk
         J+62M8T47Kjb4ypnQkOb3tk8/EOp9CScGQYsiNLYdIA2sNrlLjVTO518qSGFp5419JZx
         WMIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1753118865; x=1753723665;
        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=otp/EhkCvAdn8Jge9kAcrmISOkf3n44Fiz4zJ6xfRc0=;
        b=HujlwFKGm3WyOr5qXGZUjOgoc52MFC6laGCxf1ARPd2YC19ksCDmWE0SHCtM5R4ad5
         LMs2gH19+3NW3eVRXKSh/bNtMgCkFzY6FcVJN+tvjQOht+Dq5Fh1XR8G5dwQHtoyvxKF
         plPwnSOBvgIZ9I07T94nQ7SLWE+XQjkaSmE76Oy2V3fko/rLUsZqlgjoKO/xR2cSVveL
         8uABrFUG6RwZXDIBTj27K7sgmPBZbOhkgyXXacMTOR+LuFiEJLGOiKAQWmWMPnFSnK50
         FBiiQjvSt6x8FU4MUkXJt5g97ANmY1oE+XbRhxEoS9CUFdkV9zr5Ixjwkkr4/RSs/Naj
         kpeA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUMmpqdvOfNB8F2VBW3rxCg9pYlU6wSXvzEcGJMPDbu2/lNO4mxYirDKQkXK4Z09HxBHugpAIue65S0@gnusha.org
X-Gm-Message-State: AOJu0Yxl8Ogog2I/U8yobtxXO7XKT8ttUCofQGIQAht9XBEDFmwP1otG
	NuIsBJFYUQsRwzMM0Eiv4me5iIpgZYd/YMaUKHJIkuUDChZ5AxCpY//+
X-Google-Smtp-Source: AGHT+IFrbAcQyv8W3BoEjRuMyHCh46uFtvAyLD9Ci7zh67RZ5M6ejnLMIarN+7LSvY3G08HVYWA8rg==
X-Received: by 2002:a05:6870:a926:b0:2e9:93c6:6e4a with SMTP id 586e51a60fabf-2ffb253dcf1mr14800576fac.38.1753118865106;
        Mon, 21 Jul 2025 10:27:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe8oZrnaiPZ3TB8tAjRgmTy5TS2DX6ifv0tDUHO36Gi4g==
Received: by 2002:a05:6870:5b26:b0:29f:aff3:65c8 with SMTP id
 586e51a60fabf-2ffca9d04f1ls2676228fac.2.-pod-prod-08-us; Mon, 21 Jul 2025
 10:27:42 -0700 (PDT)
X-Received: by 2002:a05:6808:81c7:b0:41f:79f9:1b6b with SMTP id 5614622812f47-41f79f9201emr7808474b6e.34.1753118862447;
        Mon, 21 Jul 2025 10:27:42 -0700 (PDT)
Received: by 2002:a05:600c:8587:b0:456:ce4:c44e with SMTP id 5b1f17b1804b1-4563a998fb3ms5e9;
        Mon, 21 Jul 2025 10:02:23 -0700 (PDT)
X-Received: by 2002:a05:600c:1ca7:b0:456:58e:3192 with SMTP id 5b1f17b1804b1-4563b4e2d77mr99251595e9.1.1753117341316;
        Mon, 21 Jul 2025 10:02:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1753117341; cv=none;
        d=google.com; s=arc-20240605;
        b=Sjm8gnx11yrm9Dibf/NfVDIMIsekjiXjGAU81rpnDOv/nPYSEFOh7lKHpB6kXJ/AnC
         jAzkz3NEor4rtzKb3WjIC/hzJPNz3pls/YB0m6RvsK0ObuS5Ka+1i6QIkxchoNi2OHe1
         q3L+/OYObVBEVuRcwHV8l02f80NmzMQ8oqYUd1Isc33dooSkDq+bdSeIFh29qH/En950
         waJTQeCcIbmvJnuCFbUsnQht/eOZE5IfVAPXjLq8j7IAHnIjHDaetMLBd02v1Zy50adr
         3v4iYlEifDMjorYwiHOIha5MsF7NQKs5m4fjVUopMHXo0eXZ1a8YXGXtqsHYsusMFNi+
         3D8g==
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=yp9zRvAhEIU+vmpScd/h2nxDH1WnUA92Z0FqQSp6Vd0=;
        fh=/SQqOftgQlaxYAuzqasQAR2hakFW6YnLPSFjK3E+dbQ=;
        b=VqVOESt9rsXxHJgVvOZaBfBVcWJNCJQ3IIH4rgr2RAHf8gLlrfqruxc4Lktgn30ENG
         CZn4UWhfigSVckuhGGzXreN95thhfxZVY5P4ieGkjoxjQKMc8JH/NUcsmsVli9mCY0GC
         /b4U7hQ9qtx5ketJYQPVPx3NJEPnSdXUJYZTVsfHXIjyqmv+T8dpua+OJXCWmPvvK6EJ
         1pvKtEMOae2QpWPmNMs6szyV/iSK1fMaVXQbuQTU2ynKv05KNDaziRIbXp4d50oZucG1
         eD/As77LWzJ25d9F+fV3D+ScckuecsT3VsvoRpilAvePFIWob3R5PePb5lw4BL0Vi90f
         ul/g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=l0bcWyx7;
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52b 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-x52b.google.com (mail-ed1-x52b.google.com. [2a00:1450:4864:20::52b])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3b61ca4b2c1si224189f8f.7.2025.07.21.10.02.21
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 21 Jul 2025 10:02:21 -0700 (PDT)
Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) client-ip=2a00:1450:4864:20::52b;
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-612bc52ac2bso7478099a12.2
        for <bitcoindev@googlegroups.com>; Mon, 21 Jul 2025 10:02:21 -0700 (PDT)
X-Gm-Gg: ASbGnctaNBF8hee9naV5cXAPmF0Rxf/swAlRY6KfhvgjAuLo8YKFgn1cVe5B95jqkUq
	gNSphq7X5r4C6JGPVI9y6B/yMPxvSqFy7sPGykfUlWal8sg9eOP0oNt2aAQElEC2+uF/KUlpRBM
	w+Qqq6OuWOtYObMj8K/S5iQMXvM/WloSdOkscZ+WnrwF2wq8mDl8alrSyWkkH5twvThFLPzm/Mr
	c29YnZEnppuBrCOQDFl//frNJuCyDsymdaYEfkA+w==
X-Received: by 2002:a05:6402:13d2:b0:612:c810:6b8f with SMTP id
 4fb4d7f45d1cf-612c8106fbcmr11238701a12.31.1753117340138; Mon, 21 Jul 2025
 10:02:20 -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> <CAEM=y+UJJ9R5ACxNg=B2HcnBZMxf+KoWtkvH1yFgRcU56hms8g@mail.gmail.com>
In-Reply-To: <CAEM=y+UJJ9R5ACxNg=B2HcnBZMxf+KoWtkvH1yFgRcU56hms8g@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Mon, 21 Jul 2025 13:01:44 -0400
X-Gm-Features: Ac12FXwroZDKfm2UEdCG7JXyrimSzHh95M0ubtdcFw9M-sZhRYKgCA34Ou0GCdc
Message-ID: <CAEM=y+UkL6_hvrBW2S2=zymGZ1+CFVQ60aZ=zLDiJa7tiF7zcw@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="0000000000004f0140063a737096"
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=l0bcWyx7;       spf=pass
 (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52b 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 (/)

--0000000000004f0140063a737096
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It was pointed out to me off-list, I misread BIP 173 and bech32 does drop
the OP_PUSH32. This answers my question.

As an outcome of this conversation BIP 360 no longer uses Witness version 3
but Witness version 2.

https://github.com/bitcoin/bips/pull/1670

On Sun, Jul 20, 2025 at 9:44=E2=80=AFPM Ethan Heilman <eth3rs@gmail.com> wr=
ote:

> 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. Jus=
t
> 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 compressi=
ng
> 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 fr=
om
> 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 addres=
s.
> 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 versio=
n
> 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 abo=
ut
> 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 ha=
ve
>> one, for example (which results in them beginning with 1).  The reason i=
t's
>> 5 bits is just to avoid needlessly inflating the length of addresses.. a=
s
>> additional versioning, if someday required could be achieved by addition=
al
>> 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 abou=
t
>> 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 t=
hat
>> 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 the=
y
>> took apart some address and made some custom script without the receiver=
s
>> 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 righ=
t
>> network, and while they could be informed outside of the address since i=
t
>> 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 versi=
on
>> 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%2BUkL6_hvrBW2S2%3DzymGZ1%2BCFVQ60aZ%3DzLDiJa7tiF7zcw%40mail.gmail.=
com.

--0000000000004f0140063a737096
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It was pointed out to me off-list,=C2=A0I misread BIP 173 =
and bech32 does drop the OP_PUSH32. This answers my question.<br><br>As an =
outcome of this conversation BIP 360 no longer uses Witness version 3 but W=
itness version 2.<br><br><a href=3D"https://github.com/bitcoin/bips/pull/16=
70">https://github.com/bitcoin/bips/pull/1670</a></div><br><div class=3D"gm=
ail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On S=
un, Jul 20, 2025 at 9:44=E2=80=AFPM Ethan Heilman &lt;<a href=3D"mailto:eth=
3rs@gmail.com">eth3rs@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"auto"><div di=
r=3D"auto">When I was trying to understand BIP 0173, I came up with five wa=
ys to do it:</div><div dir=3D"auto"><br>1.=C2=A0 Don&#39;t treat the Witnes=
s version as a special part of the address. Just encode the ScriptPubkey.<b=
r><br></div><div dir=3D"auto">2. (Bech32 approach) allocate the first 5-bit=
s to Witness version. This lets you do versions 0 to 31 before the Witness =
version spills into the next character.=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&#39;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&#39;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>&gt; The reason it&#39;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 =
&lt;<a href=3D"mailto:gmaxwell@gmail.com" rel=3D"noreferrer noreferrer nore=
ferrer noreferrer" target=3D"_blank">gmaxwell@gmail.com</a>&gt; 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 &lt;<a =
href=3D"mailto:eth3rs@gmail.com" rel=3D"noreferrer noreferrer noreferrer no=
referrer noreferrer" target=3D"_blank">eth3rs@gmail.com</a>&gt; 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&#39;m not sure what you&#39;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&#39;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 &quot;bc&quot; 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&#39;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&#39;s script is fundamenta=
lly none of the sender&#39;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&#39;=
ve done their part.=C2=A0 Any further issues are the recipient&#39;s=C2=A0r=
esponsibility.=C2=A0 If the sender hasn&#39;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&#39;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&#39;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>
</blockquote></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/CAEM%3Dy%2BUkL6_hvrBW2S2%3DzymGZ1%2BCFVQ60aZ%3DzLDiJa7tiF7zcw%40=
mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/d/msgid/bitcoindev/CAEM%3Dy%2BUkL6_hvrBW2S2%3DzymGZ1%2BCFVQ60aZ%3DzLD=
iJa7tiF7zcw%40mail.gmail.com</a>.<br />

--0000000000004f0140063a737096--