From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 18 Jul 2025 15:24:37 -0700 Received: from mail-yb1-f192.google.com ([209.85.219.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uctVM-0007no-NO for bitcoindev@gnusha.org; Fri, 18 Jul 2025 15:24:37 -0700 Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e81285a0958sf2788861276.0 for ; Fri, 18 Jul 2025 15:24:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752877471; cv=pass; d=google.com; s=arc-20240605; b=M/n6MAbOiVDNlmovyO3wcJTl9kxoIy8pkGJ3FA06Qpwxc7nkBFB0yAKwVLawggnPdk OWZ60h+XHt4ZPUcmnvc786Y3Thgce8vNpEBDor/uFviGpBT8G3SZzVbjtV2Z9urRBe3p yfPxsKX49w+h6O2i6epW2MXH1bzTr3j3A81L2eqyymbrXpRqMN/ZBsQaJa79AO6XLf6d vFY3QbBOcqtSMHHb0w9oGg8tx+iTE26n00XJ6k56aNprbHuMuzFu/KRctfD7QVirEaiS Gchw/5LZUHu/PS5Y41rGmwW6xlAXVMAKRu1T8FCxH4rQi5SbyhxS8ZUMmf9Gk4B9FsGR NRGw== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=+cH/ydSitV7bWMUu8Qe2jzgwBhRYMENk3jROiRXjRPc=; fh=phTfBLy198+kLgMV6ts6D04sJjibcIFY5kefjyrhMeM=; b=Fo90M5KWD0kV33fttlfJ0pSdZAD1iF3BRxV66RYEa2FxtPt2eKRoQbP1ae2LHFj+gI L8x43hzptDCd/uNCuHtzH8xRwdoNlss5zRKe/rHIW5/C2Fb2WcpKtDlHkNZZwXrGg5MW J3X8XaVUToJdOCR1QrNoJcYcR7Ey9ciPPHhuuWUvpLkEAVJPLNRAE8s72o8WaJsNmPor aZOiqURlI2l0cFM7Y+CQr5kltu/q0eEBIbCj3gWKBtm1j+voYSh4SonmOKa5HWWtqja6 ZGw5F7TlxjAaWkM72EYy4tdG7OUmOrkQQgEyLBCTdPh8FegoCW5ORHhIMzW57IOd7WhC aHrQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fWEyN3YS; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=gmaxwell@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=1752877471; x=1753482271; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=+cH/ydSitV7bWMUu8Qe2jzgwBhRYMENk3jROiRXjRPc=; b=XfzOKh0CDdt49xb0cgfpvIlJWT7xDA768d1Up5+eWx0nGcfNCbDknwqwhrPrhdmqWq wmCL7XrKJqWZ8YzvBzOmb5XnLPEHzYgt4UOFqms5CD1U5qQjBoVonUfz35PjsHogmV1I 7mjo4hJKpj+JMES5GHzU8W4hZBlFke3nMLJItqr2j5zLOI3TL/jDkd+tsvECpN4PBwEm pchzPdjjkuMEuWjR3AMKe8/KE+FIMHJ8vTaK2W7L1aAryA4jQrvJ10yxZPeX3tBH4iEG I91KGL1C62njdq+ZEpuEuhMAz2fHZ4RD9J9O5EcjbL2NWouJ60IV4W+HrtY0BpGmp4Lk bH7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752877471; x=1753482271; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+cH/ydSitV7bWMUu8Qe2jzgwBhRYMENk3jROiRXjRPc=; b=YNlK7/4cFw4JJyf/6xucOjhhDtw5yc4uAjevfcCW5s5eLRNKAXtOnjWDG7+WUQ74ZB 4sqn1P89OzHN/BUHmtg7UNb3OymEXiClz+gQgNXZziMzqlyqlsyCCyWJqRoM1EGa6F8h X5TrXk9fRTYwlna9KiXY1j8gTUkyD1qc/iTUuOGCazjo33sehnuf78UetnIuPEt7qjGe JM1cCFS6N9JEYT/gMuouCks/jxIZfMPq5lbmF6w+HgO3bN1IOsEuJ7WFAiLNdnJjz2Wg YSqVxpKT7qcb2xVExB1/sz0dM7YKSuNUkSLQ1/Qc1mycYpwVae7h+3VzsGdc9W3YKQ2q vjfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752877471; x=1753482271; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc: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=+cH/ydSitV7bWMUu8Qe2jzgwBhRYMENk3jROiRXjRPc=; b=u8ekKuHx8lBDr40BxfPRWAPs7RDXC25q38+ufgk+GR6qiJWmhIkppKx7sQb12x/xB3 GjmLlr+Jzzrr0Zz+P20YwGHbG6x0eg6I3M53QhlZ/d8nG/DtgyVt6TUP6X7cl4yRjDd3 Lvr/CfOHJvPLkcKhXJwNkUlduopaIyH2tWnshCXdC2D1aMMYw9iSabrOkyXfZkNYaSGz c6xxwtDL5LKF6eHObs4IC8QCGEAdkstgd6tHttCrr0HGtFnZirbhVZLFcx4PhkPlWizR 3GR3Td8TOEzI8tAXNBLQU9xnY+KgUZTxISFXfEj/yZ3OB7hCTgkq8PiL2JaVTW97m5TT IA6Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXufdnFbJqP33vFETi5u+x7l/afbkcuL3bzctvTbfXH2gSG/ys7bNXQWNbqE8n4RGaCg4vaEauCOGFM@gnusha.org X-Gm-Message-State: AOJu0YzIvwF0T5HGy9TBhOSVhWLN9c01vxDXV7rzP0IMjVUWTGYitNqt 5XB3pT6jsBgYL8/bzSQVdqZevE/+gte6Si1ffk6zfz+CObChGBXWGrsL X-Google-Smtp-Source: AGHT+IGDon7tloukVjLxXa5fxy/kqqRiXN6jaFTKo6z46N6204+Hbw3cGTjdtUw5qdBzp0VUiiDlVA== X-Received: by 2002:a05:6902:909:b0:e89:6f2b:c50e with SMTP id 3f1490d57ef6-e8bc2540325mr15147462276.3.1752877470440; Fri, 18 Jul 2025 15:24:30 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfPiMOT/oJk8Y5b6ealzNDlmNogVCryNGHQJhAS4CdpMw== Received: by 2002:a25:2694:0:b0:e7d:c43d:b109 with SMTP id 3f1490d57ef6-e8bd464ae1als2547872276.1.-pod-prod-05-us; Fri, 18 Jul 2025 15:24:26 -0700 (PDT) X-Received: by 2002:a05:690c:350d:b0:718:2154:62df with SMTP id 00721157ae682-71837469c95mr183578907b3.35.1752877466579; Fri, 18 Jul 2025 15:24:26 -0700 (PDT) Received: by 2002:a05:6808:88c7:b0:415:de3:3f05 with SMTP id 5614622812f47-41f76b984fdmsb6e; Fri, 18 Jul 2025 15:19:04 -0700 (PDT) X-Received: by 2002:a17:90b:4985:b0:311:2f5:6b1 with SMTP id 98e67ed59e1d1-31c9f42ea67mr15918190a91.22.1752877142791; Fri, 18 Jul 2025 15:19:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752877142; cv=none; d=google.com; s=arc-20240605; b=YcpkcoaU5QXwSfXu5dSHs+6Uy2fbAiXj+Pr9BetQYcuftqzH37EjYjXnWjKYrm/ALH 7sHb//e4z0vEKKGqBgsxIhh50Zn+yVBQKxdAW+NDRr1kqf2YWeN92Z26Xvu1uDO1yg96 4JB2A3gQl3c4hlKSCXGm5ypPyu5OH/bn1O3p3iNkUEnPemgM9p5z87oqfGjU8mNhcNro wwDFkE3RqQE27dLxerGAGjbXvQbkbEQTF3N0jBY0GqlwDfk9TymI7cO6zLV76eDTD9Gx WrDj1ycf7DXpAtOQaHlhAH40XbxLLD9C9swTl+gt2jWlNm9itVB/uus75CuMLJ9KOIyf pH2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=VeJsKtFKxCt5q/MFFY0RxHopAYRWrk/NDqmLppLVkiY=; fh=MhNL3lrwfbsRO5DJHn9ZZ/LeA3+mAuX0vCziGEghh6s=; b=YgtFeUkt2DaZOcs+3LIXnwx+YfvohGW/gHOu9iTmK8hObJJTeveaFzfI1ofeIkLniU F2CRVtxAXjO1g8I/EyUu12gY1LYGBPuqVZn9EEBZXLJrXxZR5FEAFZEFJE0kYrvXYe3+ My3AEFL9NYJS8UIeULyEuKoGMC3AvOaV2evnTv5yY/heNXwMv93bUb5SND+6pnyNiMNq 07iNRM+bFsWcAUEyEVtrIpDuyrylZadzWlW7AX7Ov0ibRhRkBKh9Q8J+e9a0rdpPHOCp RjW+yLCB8P1eFL8INzsuDB3zS1gn1L66ZX56y14A569gjeWQt2BSp3y3UYus0FA+iDMm 2jYA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fWEyN3YS; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com. [2607:f8b0:4864:20::102e]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-31cc3ec5231si124197a91.2.2025.07.18.15.19.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Jul 2025 15:19:02 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) client-ip=2607:f8b0:4864:20::102e; Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-311d5fdf1f0so2203982a91.1 for ; Fri, 18 Jul 2025 15:19:02 -0700 (PDT) X-Gm-Gg: ASbGncstW89NQpHnXcdfXxs80tTAG2PPB3D0NZmexnkcbK0g+m5xVACxfnfr0QfnYB4 cYPkrKGWK676/hptiql+s/uy7A2aLlW1UXa+1U//y+5chopP9CKerwZFFhEdH7/tUgZ49WP5ccj Uc8FtR1EUIPS9ieMV/JBuRa9VQzUBA1V2Yh20i1SsIupccKgm4bII/HPOZdSioIR+OQH9PheQSr 405SS0= X-Received: by 2002:a17:90b:3c06:b0:311:b0ec:135f with SMTP id 98e67ed59e1d1-31c9f459f8bmr16024050a91.30.1752877142136; Fri, 18 Jul 2025 15:19:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Maxwell Date: Fri, 18 Jul 2025 22:18:50 +0000 X-Gm-Features: Ac12FXxGTmD3mlVTrpEVVi5SoYamOtnnPvNd9pwtiVBJ9W9bzbN2SzfKKbXdzDU Message-ID: Subject: Re: [bitcoindev] Human meaningful witness versioning To: Ethan Heilman Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000646083063a3b8341" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fWEyN3YS; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --000000000000646083063a3b8341 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's an unfortunate side effect of the system's operation that this field is even legible in addresses, as doing so means funds senders think they need to police which ones are used which has a side effect of practically inhibiting users from self-selecting the rules that govern their own coins. It also presumes that different 'use types' map to different witness versions-- akin to the false belief that "3" addresses were multisig--, but this is a wrong assumption as the witness version is the product of technical minutia and not the user's application. It also creates needless competition for a limited resource. Why wouldn't *every* type be as compressed as reasonably possible? Why would there be only one kind of "resistant" address? It also presumes inflexible single use application-- but that isn't even inherent in the current limited functionality PQ schemes. For example, a hash tree signature scheme could easily be created that had a hidden branch in it that was "surprise, this branch is secretly a script commitment, and we're going to spend using the script!" in order to support taproot like "key-happy-path or script-fallback" that is revealed if the fallback is used. So I think this is undesirable and undermines the motivations of the existing design. On Fri, Jul 18, 2025 at 10:00=E2=80=AFPM Ethan Heilman w= rote: > I want to propose a new criteria for allocating Witness versions based on > human meaningfulness and see if there is support for this approach or if > the community is highly allergic to this idea. > > Bech32 (BIP-0173 > ) was > designed such that the Witness version is the first character in an addre= ss > after the =E2=80=9Cbc1=E2=80=9D address prefix > > Witness Version 0: bc1q=E2=80=A6 > Witness Version 1: bc1p=E2=80=A6 > > Witness version 2: bc1z=E2=80=A6 > > Witness version 3: bc1r=E2=80=A6 > > Witness version 4: bc1y=E2=80=A6 > Witness version 5: bc19=E2=80=A6 > > Witness version 6: bc1x=E2=80=A6 > > Witness version 7: bc18=E2=80=A6 > > Witness version 8: bc1g=E2=80=A6 > > =E2=80=A6 > > So far we have been allocating Witness Versions in incrementing numeric > order (0,1,...). I want to suggest we allocate Witness Versions mnemonic = to > make it easier to look at an address and determine the output type. > > This originally came up over the question of if BIP-360 should use Witnes= s > Version 3 to get bc1r=E2=80=A6 for P2QRH (r for resistant) or the next nu= merically > available 2, but I want to see how the community feels about it as a > general pattern for future softforks (z for compressed/zipped output, y f= or > yield outputs, etc=E2=80=A6). > > Making it easier for users to understand the output type associated is > likely to grow in importance over time as we retire output types, add > policy restricting the relay of certain output types or output types beco= me > insecure due to cryptanalytic breaks. While wallet software should flag > dangerous output types, some wallets may not invest in such functionality > or the user may be using a paper wallet. This is the same argument as > prefixing addresses with =E2=80=9Cbc=E2=80=9D for mainnet and =E2=80=9Ctc= =E2=80=9D for testnet. > > Note: the Witness version is sometimes called the SegWit version. > > Thanks, > Ethan > > -- > 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/CAEM%3Dy%2BWkLOVJ787jjr5zZgK= sAHxHkgdZjANqGycEh4K7ZSddSA%40mail.gmail.com > > . > --=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/= CAAS2fgTyRT9%2BECvhWvHR5niWSZkD0NgEW4kZLm1nPc8J5KezUg%40mail.gmail.com. --000000000000646083063a3b8341 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's an unfortunate side effect of the system'= ;s operation that this field is even legible in addresses, as doing so mean= s funds senders think they need to police which ones are used which has a s= ide effect of practically=C2=A0inhibiting users from self-selecting the rul= es that govern their own coins.=C2=A0 =C2=A0It also presumes that different= 'use types' map to different witness versions-- akin to the false = belief that "3" addresses were multisig--,=C2=A0 but this is a wr= ong assumption as the witness=C2=A0version is the product of technical minu= tia and not the user's application.

It also cr= eates needless competition for a limited resource. Why wouldn't *every*= type be as compressed=C2=A0as reasonably possible? Why would there be only= one kind of "resistant" address?

It als= o presumes inflexible single use application-- but that isn't even inhe= rent in the current limited functionality PQ schemes.=C2=A0 =C2=A0For examp= le, a hash tree signature scheme could easily be created that had a hidden = branch in it that was "surprise, this branch is secretly a script comm= itment, and we're going to spend using the script!"=C2=A0 in order= to support taproot like "key-happy-path or script-fallback" that= is revealed if the fallback is used.

So I think t= his is undesirable and undermines the motivations of the existing design.






On Fri, Jul 18, 2025 at 10:00=E2=80=AFPM Ethan He= ilman <eth3rs@gmail.com> wrot= e:

I want to propose a new criteria for allocating Witnes= s versions based on human meaningfulness and see if there is support for th= is approach or if the community is highly allergic to this idea.

<= /span>

Bech32 (<= span style=3D"font-size:11pt;font-family:Arial,sans-serif;background-color:= transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font= -variant-alternates:normal;text-decoration-line:underline;vertical-align:ba= seline">BIP-0173) was designed such that the Witness version is the f= irst character in an address after the =E2=80=9Cbc1=E2=80=9D address prefix=

Witness Version 0: bc1q=E2=80=A6
Witness Version 1: = bc1p=E2=80=A6

Witness version 2: bc1z=E2=80=A6

Witness version = 3: bc1r=E2=80=A6

Witness version 4: bc1y=E2=80=A6
Witness versi= on 5: bc19=E2=80=A6

Witness version 6: bc1x=E2=80=A6

Witness ver= sion 7: bc18=E2=80=A6

Witness version 8: bc1g=E2=80=A6

=E2=80=A6<= /span>


So far we have been allocating Witness Versions in incrementing nu= meric order (0,1,...). I want to suggest we allocate Witness Versions mnemo= nic to make it easier to look at an address and determine the output type.<= /span>


This originally came up over the question of if BIP-360 should use= Witness Version 3 to get bc1r=E2=80=A6 for P2QRH (r for resistant) or the = next numerically available 2, but I want to see how the community feels abo= ut it as a general pattern for future softforks (z for compressed/zipped ou= tput, y for yield outputs, etc=E2=80=A6).


Making it easier for use= rs to understand the output type associated is likely to grow in importance= over time as we retire output types, add policy restricting the relay of c= ertain output types or output types become insecure due to cryptanalytic br= eaks. While wallet software should flag dangerous output types, some wallet= s may not invest in such functionality or the user may be using a paper wal= let. This is the same argument as prefixing addresses with =E2=80=9Cbc=E2= =80=9D for mainnet and =E2=80=9Ctc=E2=80=9D for testnet.


Note: the= Witness version is sometimes called the SegWit version.

Than= ks,
Ethan

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit http= s://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWkLOVJ787jjr5zZgKsAHxHk= gdZjANqGycEh4K7ZSddSA%40mail.gmail.com.

--
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.google.com/d/= msgid/bitcoindev/CAAS2fgTyRT9%2BECvhWvHR5niWSZkD0NgEW4kZLm1nPc8J5KezUg%40ma= il.gmail.com.
--000000000000646083063a3b8341--