From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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: <-k1KNMwmXrdmMxpxMeJHAOYuKpMfeUpx7rqfIkta_NC6f7MtzlOYEdXbAhi-SztejTidNysh40ask8j9JNrzxoh1sUCH4F9tKV6tarkrWrc=@proton.me> In-Reply-To: From: Ethan Heilman Date: Mon, 21 Jul 2025 13:01:44 -0400 X-Gm-Features: Ac12FXwroZDKfm2UEdCG7JXyrimSzHh95M0ubtdcFw9M-sZhRYKgCA34Ou0GCdc Message-ID: Subject: Re: [bitcoindev] Human meaningful witness versioning To: Bitcoin Development Mailing List , Gregory Maxwell 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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 wrote: > >> On Sun, Jul 20, 2025 at 9:35=E2=80=AFPM Ethan Heilman = 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
It was pointed out to me off-list,=C2=A0I 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 W= itness version 2.

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

On S= un, Jul 20, 2025 at 9:44=E2=80=AFPM Ethan Heilman <eth3rs@gmail.com> wrote:
When I was trying to understand BIP 0173, I came up with five wa= ys to do it:

1.=C2=A0 Don't treat the Witnes= s version as a special part of the address. Just encode the ScriptPubkey.
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.

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.

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.

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.

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?

Option 5 and dropping OP_PUS= H32 seems best to avoid address confusion.

> 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.

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`?

On Sun, Jul 20, 2025, 18:38 Greg Maxwell = <gmaxwell@gmail.com> wrote:
<= /div>
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=C2=A0way? It might be useful to do= cument here for future discussions on address encoding.

=
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.

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.

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.
=

(and I believe so far this has proved to be successful,= copies have changed the HRP)



<= /div>





<= /div>

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/CAEM%3Dy%2BUkL6_hvrBW2S2%3DzymGZ1%2BCFVQ60aZ%3DzLD= iJa7tiF7zcw%40mail.gmail.com.
--0000000000004f0140063a737096--