path: root/fe/8178c31591cea4106f5fd44ec682554997a910

Delivery-date: Tue, 15 Jul 2025 04:36:25 -0700
Received: from mail-yw1-f183.google.com ([209.85.128.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC4PBDNG2YCRBLP23DBQMGQELZN3VTY@googlegroups.com>)
	id 1ubdxQ-0002ec-1W
	for bitcoindev@gnusha.org; Tue, 15 Jul 2025 04:36:25 -0700
Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-7151c64e0a2sf86324237b3.3
        for <bitcoindev@gnusha.org>; Tue, 15 Jul 2025 04:36:23 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1752579377; cv=pass;
        d=google.com; s=arc-20240605;
        b=JiOC8X54yod5c3yK7zy7GTUC/TDn8gHKn6L9HC6PbnHdEKK8e/AbqhI6Turm535Ka0
         W04unmijW+0gHAsI5mvU4fTO1+MMMyhArbJ0TCmCP1yaZrwwNvXx8aF1b1Z9pxysmStI
         gXuC680k94sgqQi3FyvXkOaU+cRfOSIoWaEeL9oTH8n/G1DHR87vvCuh/+hxdEAfWHbn
         QQYQzn/olWKOnL4tgymf9riHeTymEIPeoow4LlueyAqxagkjIjlGCbWy+4r2F7nhkgLK
         uzuv+a/uXP8wpG6mGTNgNc07zP5U5dx70ehzHleyQIHLXMctJ7d2VYFfTxkdvch6oVUF
         +lNQ==
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:reply-to:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:dkim-signature;
        bh=uHrBDQDKCApxR6Zg9ymAOsu/TeSDQWP3lwNuT1IPUow=;
        fh=8k7tXey6J5blD80fd522IbpiyZkhFYLEg5SArXAGsX8=;
        b=AnrqDjKzXXeq6Amdp3e0Gusc1UjlmwB7sqa1Xe9I3VPa2rmzezXkVfB05dKQU0srHP
         /O/3K0Jsi4gZzLlwqDatHvgEx++PNwLpBGi19VPbBMEy7O2XGaHDC114d8BVdlIRHgh1
         LX5A4N6HXW+bmcloJE38RxsBI6iUWNqCwaZg3sdru54+C80Rp0Zprfw4Vur6CyTSlbFk
         27sJitrj6eYzBo/ejzDg7v93Wcn12/EXMTeVs1MxWKlIYdeIQZuuMRGAVZnniU2w3lfj
         cQPxuLOiw0WFL/sxhLwq9piQVPkR7cBhfY4T5mbZzNPCYfgnRC17oE9vIR5qoRI7Gr3E
         yxtw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@blockstream.com header.s=google header.b=MYp6e+FK;
       spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::102a as permitted sender) smtp.mailfrom=roconnor@blockstream.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752579377; x=1753184177; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :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=uHrBDQDKCApxR6Zg9ymAOsu/TeSDQWP3lwNuT1IPUow=;
        b=Kr04uUPOK8e/zIGo8BiEPiOrcUb7EnUDPeNC2EOJibnlRpraGjVA4Bv/IvbfRS44V8
         TaUXbLE0sygSQz7boaK9W5NYIWb14V8cIbV3eshyQdHePgjoaKhhAq4MGpESUDOHLkQf
         G2AFVeAyMiddJzLWORTVCY9t4Vy7B65gLlWqw7vZIgzRQetoL8xTtrk8Qnryqk+6KF3J
         xtXR7LqZOxNUL0rPFjsNisgVa4VCQ50TFlPtwCCfZmzmcV/oDXP9tVltkokAxZ51Apc+
         j4FOrYGmY+oYW0GufwahLlmCrlBgAgDBcivEEkks69HvYxu4M04i/SMS5TOX+F7tA1bZ
         450A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752579377; x=1753184177;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :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:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uHrBDQDKCApxR6Zg9ymAOsu/TeSDQWP3lwNuT1IPUow=;
        b=Cc+SXTxcEl1foRaxJ7cb69IdWqKyTQXi8LY66iFraenLihxUN8R2FyCbnS33XcR3xI
         y59D+gZZP93paPdKrWZSE9s+SgAJ79p3zySbkc2/2+ytjG9o4d7OEE57PfflWv4VELoy
         mqK3kRQsA3PR2tBc5TitaKPIFwjtmi3lpWnPiw8S1hFIyw5uVZKlSeJyFeOBztOTaA5/
         STz5xfhK4WOq7jJpEbEeBRlp6vxmD57W4oKHUjxrUlV15G7mHbZUKlVLrI+IRUmnUDAk
         lXJRWlHxntCYgYnCTYxV7eKBY16d+ERWNZlV7rZnKU/snSeez6uIddJPfLZ5VRYAld+a
         HiDw==
X-Forwarded-Encrypted: i=2; AJvYcCXvJu71soy4emz/Ao3b+2LT7G+2UuXLje6ZQOa+3v7WXvgniBhOQicyVhiEuvyVXVI1VQIu1EDdJ5QA@gnusha.org
X-Gm-Message-State: AOJu0YyMS4Vd5zMZWtO/+UcNAr4LYFb+Bs7XfUtS/ifqPAcOpVyHdOQ0
	LfSCxL66TnmTEogc1zFl3TPSuTGd+mGVqh+EyCCUQhOTWGAWE8imPQ06
X-Google-Smtp-Source: AGHT+IGyMmk+iIsS/PWDw8ZZ5p5sQnuBCZiOx9U5G3JiLwlklJyzjziwX5J/UNScj0QN3RwIpeCWvw==
X-Received: by 2002:a05:690c:3385:b0:712:c55c:4e48 with SMTP id 00721157ae682-717d78615d3mr218837337b3.8.1752579377269;
        Tue, 15 Jul 2025 04:36:17 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZen9GQPBSZCdunH3E5g1+x0uLsV0LNuLcP1h/GZZFRNog==
Received: by 2002:a25:3f01:0:b0:e84:d706:629f with SMTP id 3f1490d57ef6-e8b779532e3ls5974531276.1.-pod-prod-09-us;
 Tue, 15 Jul 2025 04:36:13 -0700 (PDT)
X-Received: by 2002:a05:690c:890:b0:70f:253d:f278 with SMTP id 00721157ae682-717d78c14femr252703697b3.15.1752579373115;
        Tue, 15 Jul 2025 04:36:13 -0700 (PDT)
Received: by 2002:a05:620a:4592:b0:7c5:50d5:7703 with SMTP id af79cd13be357-7e338e29531ms85a;
        Mon, 14 Jul 2025 13:48:31 -0700 (PDT)
X-Received: by 2002:a05:620a:4416:b0:7d3:b8eb:b32f with SMTP id af79cd13be357-7de06bbb8ffmr2007457185a.37.1752526110611;
        Mon, 14 Jul 2025 13:48:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1752526110; cv=none;
        d=google.com; s=arc-20240605;
        b=ArpAVCNqGIcGWaMfy/V3zZd4bXrnjZzY5PHxsmpzVOPij9/2hqJZb6az2m+ofxQSpd
         jpNx3UxTlg9WgbRHcAM23TNagcL+CoKKofJJX9bGafqXVdFGTHloXqHwWwJWS+OefKXc
         fo0KRjsNeTok55aWzorKqdolmzHlcwNlysfbmI9uC0ZaCkOPv3PZYDKBVBqHYphdX2Qg
         Z7sKVMhDDOXvrWSJK59lZMZh6VXK1VRTVLBoY7wZH0nPIk4RnXjuDNp5UMvfwbHjgas1
         cIhKz2klDXRzliONtoWPGfWAPWok5QWKW49o8yT26XRzamfIt3oZzXvFrgNglG3tdngO
         It/g==
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=pXuBLXmn+wJzPysOJ0evry4PoGKPW4z13CpJp6KDBLA=;
        fh=20A3HTZD1sEkem3bxg4+pZ/Ky7dBHGOiMRl4dPvaLBo=;
        b=NFvuYKNiw0oz6sijq3+r4l4FsyOIgZz7SG2Y4BfKc/TXhtLYiXkfZiGmNPbPQTdkBr
         4tgvDed+zbJmESli8YIol8xSDxappvH09BIaaoMxp3fCsyXiSC9EdCTpNbQMU/v8BTQj
         nEw0DwCOYQR9r5SDYNj5au8X5eRQhASwVwY3lGvxQiugh12iMRcx87pVnBeyxPqvguKa
         5MzTOUYFyqkk2X7C3iXYQuqT/mL/ujyvwKDVNjQF3Il4dGN0XxLNbMf6pdFPzcywFUr6
         iC9jue4TXM+8TDP6WKOSunmd2eVjawDTEhI13lPPntTZZKhNf6ku/X9qP26TLcyrstK1
         /N1g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@blockstream.com header.s=google header.b=MYp6e+FK;
       spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::102a as permitted sender) smtp.mailfrom=roconnor@blockstream.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com. [2607:f8b0:4864:20::102a])
        by gmr-mx.google.com with ESMTPS id af79cd13be357-7e0f10ae52asi25394085a.4.2025.07.14.13.48.30
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 14 Jul 2025 13:48:30 -0700 (PDT)
Received-SPF: pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::102a as permitted sender) client-ip=2607:f8b0:4864:20::102a;
Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-313f68bc519so3658465a91.0
        for <bitcoindev@googlegroups.com>; Mon, 14 Jul 2025 13:48:30 -0700 (PDT)
X-Gm-Gg: ASbGncuELHAKygLAQRJjiNbIfT5vgYMg9MYKs7YbaXRHOjJCTCuXXwCAm8jF0jw0OXs
	7tbRcO4+qjBvN84hNNKRSYU9vSbwb7FnLrVDdGcSs6H8qh3LfMTFup4dI62q6aoMMGXFebugb31
	tjJXC1rUd0wnfdrP4siafP9izEzAzXOnGSfJffSoGqMe/FnHuxsx+F1BV5yy+CLpQj1c+gzCchL
	s+Vbvg=
X-Received: by 2002:a17:90b:5144:b0:313:db0b:75d7 with SMTP id
 98e67ed59e1d1-31c4f54a12amr21493331a91.27.1752526109236; Mon, 14 Jul 2025
 13:48:29 -0700 (PDT)
MIME-Version: 1.0
References: <1da0467a-9cc6-4448-85b9-a9b01ef1aca7n@googlegroups.com>
In-Reply-To: <1da0467a-9cc6-4448-85b9-a9b01ef1aca7n@googlegroups.com>
From: "'Russell O'Connor' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Date: Mon, 14 Jul 2025 16:48:18 -0400
X-Gm-Features: Ac12FXxHNdr4uruM46FPzTi4b5v4F9_E1HLvpM_O4lpYq01Y43DXfzesZD847hI
Message-ID: <CAMZUoKkUwb36TJjXOG7ev-aLW1N68Xoz8qq=pmSwNL45+A+w1g@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Compressed Base58 Encoding for BIP-39
 Mnemonics with Multisig Extensions
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Zach <corneliusamadeusacts10@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000033772a0639e9c8bf"
X-Original-Sender: roconnor@blockstream.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@blockstream.com header.s=google header.b=MYp6e+FK;       spf=pass
 (google.com: domain of roconnor@blockstream.com designates
 2607:f8b0:4864:20::102a as permitted sender) smtp.mailfrom=roconnor@blockstream.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com;
       dara=pass header.i=@googlegroups.com
X-Original-From: "Russell O'Connor" <roconnor@blockstream.com>
Reply-To: "Russell O'Connor" <roconnor@blockstream.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.9 (/)

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

IMHO, this use case is already solved more generally using descriptors
(BIP-38x), which already come with their own checksum.

In particular, I'd personally be inclined to use a fully public descriptor
with all 3 xpubs/key paths and then keep one's own master secret in codex32
form (BIP-93) along with it.

After first loading one's master secret into a wallet, when you load the
public descriptor into the wallet, the wallet ought to be able to recognize
that it knows the secret key corresponding to some of the xpubs (by
leveraging the BIP-380 key origin information).

I personally believe it is more sensible to store the public descriptor
data differently from the data of the xpriv or master secret, as they have
storage requirements.  The master secret is typically compact and super
secret, for which a proper error-correcting checksum is desired, optionally
with secret sharing in order to safely distribute backup copies (e.g. in
sealed metal capsules).  Whereas the descriptor data is sensitive, but not
super secret, and the data could be arbitrarily large.  Thus for
descriptors, error-correcting codes are somewhat more problematic, and
given that descriptors are only sensitive but not secret, they can perhaps
be backed up by more normal means.

I've been working towards this goal for Bitcoin Core in <
https://github.com/bitcoin/bitcoin/pull/32652>, but it is still a work in
progress.

On Mon, Jul 14, 2025 at 3:06=E2=80=AFPM Zach <corneliusamadeusacts10@gmail.=
com>
wrote:

> Dear Bitcoin-Dev Community,
>
> My name is Zach and I'm a Bitcoin enthusiast interested in improving
> wallet usability and security. I'm writing to propose a new Bitcoin
> Improvement Proposal (BIP) and seek initial feedback before submitting a
> formal draft via GitHub pull request.
>
> The proposal builds on BIP-39 by introducing a compressed representation
> of mnemonic phrases using Base58 encoding, reducing a 12-word mnemonic to
> 24 characters. It also includes an optional extension for multisig setups
> (e.g., 2-of-3), where each participant's storage combines their compresse=
d
> mnemonic with foreign xpubs and a checksum into a ~252-character Base58
> string. This aims to facilitate secure, distributed storage in
> space-constrained scenarios like physical backups or QR codes.
>
> Below is a draft of the BIP in plain text format for review. I've followe=
d
> the structure from BIP-2 but haven't assigned a number yet. If the
> community finds this idea promising, I'll convert it to MediaWiki and
> submit it to the bitcoin/bips repo.
> ------------------------------
> *Bitcoin Improvement Proposal: BIP-XXXX (Compressed Base58 Mnemonic
> Encoding with Multisig Extensions)*
>
> *Preamble *
>
>    - BIP#: XXXX (to be assigned)
>    - Title: Compressed Base58 Encoding for BIP-39 Mnemonics with Multisig
>    Storage Format
>    - Author: Zach corneliusamadeusacts10@gmail.com
>    - Status: Draft
>    - Type: Standards Track
>    - Created: 2025-07-14
>    - License: BSD-2-Clause
>
> *Abstract*
>
>
> This BIP proposes a method to compress BIP-39 mnemonic phrases by mapping
> each word in the standard 2048-word English wordlist to a unique
> two-character string using Base58 encoding. This reduces a typical 12-wor=
d
> mnemonic (approximately 59 characters including spaces) to a compact
> 24-character string without spaces. The encoding is deterministic,
> reversible, and leverages the existing BIP-39 word indices, ensuring
> compatibility with current seed generation practices.
>
> Additionally, this BIP introduces an optional extension for
> multi-signature (multisig) setups, particularly m-of-n schemes like 2-of-=
3.
> In such scenarios, each participant's location stores their local
> compressed mnemonic alongside the extended public keys (xpubs) from the
> other participants. These components are concatenated into a single Base5=
8
> string with a checksum for integrity, resulting in a ~252-character strin=
g
> per location. This facilitates secure, distributed storage while enabling
> independent address derivation at each site.
>
> This can aid in easier storage, transmission, and input of mnemonics and
> multisig data in space-constrained environments, such as physical etching=
s
> or QR codes, while maintaining security.
> *Motivation*
>
> BIP-39 mnemonics are human-readable but verbose. Compressing them to 24
> characters for 12 words reduces overhead significantly. In multisig
> contexts, such as a 2-of-3 scheme with geographically distributed
> participants, each location must store foreign xpubs to derive shared
> addresses, but private mnemonics remain isolated. Concatenating the
> compressed mnemonic with xpubs and a checksum creates a compact, verifiab=
le
> dataset (~252 characters), and supports error detection during
> transcription or recovery.
>
> This does not replace BIP-39 or existing multisig standards (e.g., BIP-45
> for derivation paths) but provides an optional compressed representation
> and storage format.
> *Specification*
>
> Base58 Alphabet
>
> 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
>
> Word Index Mapping and Encoding/Decoding
>
> The BIP-39 English wordlist is sorted alphabetically, assigning indices
> from 0 ("abandon") to 2047 ("zoo"). The full wordlist is defined in BIP-3=
9
> and remains unchanged.
>
> For a word with index i (0 =E2=89=A4 i =E2=89=A4 2047):
>
>    1. Compute high =3D i // 58 (integer division, range 0-35 for i =E2=89=
=A4 2047)
>    2. Compute low =3D i % 58 (range 0-57)
>    3. The two-character code is alphabet[high] + alphabet[low]
>    (big-endian order, higher digit first)
>
> Examples:
>
>    - i=3D0 ("abandon"): "11"
>    - i=3D2047 ("zoo"): "PJ"
>
> Compressing a mnemonic: Look up indices, encode each to 2 chars,
> concatenate (24 chars for 12 words).
>
> Decompressing: Split into 2-char chunks, decode indices, look up words,
> verify checksum.
>
> Multisig Storage Format (Extension)
>
> Assumes 12-word mnemonics, 111-char xpubs.
>
> Structure: Compressed mnemonic (24 chars) + Sorted foreign xpub1 (111) +
> xpub2 (111) + Checksum (6 chars) =3D 252 chars.
>
> Checksum: Double-SHA256 of decoded data bytes, first 4 bytes encoded to
> Base58, padded to 6 chars with '1's.
>
> Verification: Extract parts, recompute checksum, validate.
>
> Usage in 2-of-3: Each location stores local compressed + 2 foreign xpubs =
+
> checksum.
>
> *Rationale*
>
>    - 58^2 =3D 3364 > 2048 for unique codes.
>    - Concatenation leverages Base58 for compactness.
>    - Fixed lengths for easy parsing.
>
> *Backwards Compatibility*
>
> Fully compatible; optional extension.
>
> *Reference Implementation *
>
> Full Python reference implementation available upon request or in the
> formal submission.
>
> *Test Vectors *
>
>    - Compressed mnemonic: "1112131415161718191A1B1C" (first 6 words,
>    extend to 24 chars for full).
>    - xpub1:
>    "xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJ=
oCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8"
>    (111 chars).
>    - xpub2:
>    "xpub68Gmy5EdvgibQVbouHdFqKg4ZP5oVjJeJUP7yKS4xEM2it2c8EL3MEN8WC4PTEiGK=
8oFUaKUV4ndBKSp53Q6fFi8DwhsBS1Lxf4H9fwnK2"
>    (111 chars).
>    - Sorted: xpub1, xpub2 (assuming lex order).
>    - Data str: "1112131415161718191A1B1C" + xpub1 + xpub2 (246 chars, but
>    use full 24-char compressed in practice).
>    - Checksum: Compute as per code (will be 6 chars, e.g., "2AbCdE").
>    - Full storage: Data str + checksum (252 chars).
>
> *Acknowledgements*
>
>    - BIP-39 authors for the foundational wordlist.
>    - Bitcoin community for Base58 standards.
>    - Multisig distribution insights.
>
> ------------------------------
>
> I'd appreciate any feedback on this draft: Is the concept sound? Are ther=
e
> similar existing proposals I'm unaware of? Suggestions for improvements,
> such as in the checksum method or generalization to other word counts/m-n
> schemes?
>
> If there's interest, I'll proceed with the GitHub submission after
> incorporating comments.
>
> Thank you very much for your attention to this matter and any insights!
>
> Best regards, Zach corneliusamadeusacts10@gmail.com
>
> --
> 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/1da0467a-9cc6-4448-85b9-a9b0=
1ef1aca7n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/1da0467a-9cc6-4448-85b9-a9b=
01ef1aca7n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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/=
CAMZUoKkUwb36TJjXOG7ev-aLW1N68Xoz8qq%3DpmSwNL45%2BA%2Bw1g%40mail.gmail.com.

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

<div dir=3D"ltr"><div>IMHO, this use case is already solved more generally =
using descriptors (BIP-38x), which already come with their own checksum.</d=
iv><div><br></div><div>In particular, I&#39;d personally be inclined to use=
 a fully public descriptor with all 3 xpubs/key paths and then keep one&#39=
;s own master secret in codex32 form (BIP-93) along with it.</div><div><br>=
</div><div>After first loading one&#39;s master secret into a wallet, when =
you load the public descriptor into the wallet, the wallet ought to be able=
 to recognize that it knows the secret key corresponding to some of the xpu=
bs (by leveraging the BIP-380 key origin information).</div><div><br></div>=
<div>I personally believe it is more sensible to store the public descripto=
r data differently from the data of the xpriv or master secret, as they hav=
e storage requirements.=C2=A0 The master secret is typically compact and su=
per secret, for which a proper error-correcting checksum is desired, option=
ally with secret sharing in order to safely distribute backup copies (e.g. =
in sealed metal capsules).=C2=A0 Whereas the descriptor data is sensitive, =
but not super secret, and the data could be arbitrarily large.=C2=A0 Thus f=
or descriptors, error-correcting codes are somewhat more problematic, and g=
iven that descriptors are only sensitive but not secret, they can perhaps b=
e backed up by more normal means.</div><div><br></div><div>I&#39;ve been wo=
rking towards this goal for Bitcoin Core in &lt;<a href=3D"https://github.c=
om/bitcoin/bitcoin/pull/32652">https://github.com/bitcoin/bitcoin/pull/3265=
2</a>&gt;, but it is still a work in progress.</div><div><br></div><div cla=
ss=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Mon, Jul 14, 2025 at 3:06=E2=80=AFPM Zach &lt;<a href=3D"mailto:corn=
eliusamadeusacts10@gmail.com">corneliusamadeusacts10@gmail.com</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir=3D"aut=
o">Dear Bitcoin-Dev Community,</p>
<p dir=3D"auto">My name is Zach and I&#39;m a Bitcoin enthusiast interested=
 in improving wallet usability and security. I&#39;m writing to propose a n=
ew Bitcoin Improvement Proposal (BIP) and seek initial feedback before subm=
itting a formal draft via GitHub pull request.</p>
<p dir=3D"auto">The proposal builds on BIP-39 by introducing a compressed r=
epresentation of mnemonic phrases using Base58 encoding, reducing a 12-word=
 mnemonic to 24 characters. It also includes an optional extension for mult=
isig setups (e.g., 2-of-3), where each participant&#39;s storage combines t=
heir compressed mnemonic with foreign xpubs and a checksum into a ~252-char=
acter Base58 string. This aims to facilitate secure, distributed storage in=
 space-constrained scenarios like physical backups or QR codes.</p>
<p dir=3D"auto">Below is a draft of the BIP in plain text format for review=
. I&#39;ve followed the structure from BIP-2 but haven&#39;t assigned a num=
ber yet. If the community finds this idea promising, I&#39;ll convert it to=
 MediaWiki and submit it to the bitcoin/bips repo.</p>
<hr>
<span dir=3D"auto"><b>Bitcoin Improvement Proposal: BIP-XXXX (Compressed Ba=
se58 Mnemonic Encoding with Multisig Extensions)</b></span>=C2=A0<div><span=
 dir=3D"auto"><br></span></div><div><b><span dir=3D"auto">Preamble</span>
</b><ul dir=3D"auto">
<li>BIP#: XXXX (to be assigned)</li>
<li>Title: Compressed Base58 Encoding for BIP-39 Mnemonics with Multisig St=
orage Format</li>
<li>Author: Zach <a href=3D"mailto:corneliusamadeusacts10@gmail.com" target=
=3D"_blank">corneliusamadeusacts10@gmail.com</a></li>
<li>Status: Draft</li><li>Type: Standards Track</li><li>Created: 2025-07-14=
</li><li>License: BSD-2-Clause</li></ul><b><span dir=3D"auto">Abstract</spa=
n></b><br><p dir=3D"auto" style=3D"display:inline"><br></p></div><div><p di=
r=3D"auto" style=3D"display:inline">This BIP proposes a method to compress =
BIP-39 mnemonic phrases by mapping each word in the standard 2048-word Engl=
ish wordlist to a unique two-character string using Base58 encoding. This r=
educes a typical 12-word mnemonic (approximately 59 characters including sp=
aces) to a compact 24-character string without spaces. The encoding is dete=
rministic, reversible, and leverages the existing BIP-39 word indices, ensu=
ring compatibility with current seed generation practices.</p><p dir=3D"aut=
o">Additionally, this BIP introduces an optional extension for multi-signat=
ure (multisig) setups, particularly m-of-n schemes like 2-of-3. In such sce=
narios, each participant&#39;s location stores their local compressed mnemo=
nic alongside the extended public keys (xpubs) from the other participants.=
 These components are concatenated into a single Base58 string with a check=
sum for integrity, resulting in a ~252-character string per location. This =
facilitates secure, distributed storage while enabling independent address =
derivation at each site.</p><p dir=3D"auto">This can aid in easier storage,=
 transmission, and input of mnemonics and multisig data in space-constraine=
d environments, such as physical etchings or QR codes, while maintaining se=
curity.</p><span dir=3D"auto"><b>Motivation</b></span>
<p dir=3D"auto">BIP-39 mnemonics are human-readable but verbose. Compressin=
g them to 24 characters for 12 words reduces overhead significantly. In mul=
tisig contexts, such as a 2-of-3 scheme with geographically distributed par=
ticipants, each location must store foreign xpubs to derive shared addresse=
s, but private mnemonics remain isolated. Concatenating the compressed mnem=
onic with xpubs and a checksum creates a compact, verifiable dataset (~252 =
characters), and supports error detection during transcription or recovery.=
</p><p dir=3D"auto">This does not replace BIP-39 or existing multisig stand=
ards (e.g., BIP-45 for derivation paths) but provides an optional compresse=
d representation and storage format.</p><span dir=3D"auto"><b>Specification=
</b></span></div><div><span dir=3D"auto"><p dir=3D"auto">Base58 Alphabet</p=
><p dir=3D"auto">123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz=
</p><p dir=3D"auto"><span dir=3D"auto">Word Index Mapping and Encoding/Deco=
ding</span>
</p><p dir=3D"auto">The BIP-39 English wordlist is sorted alphabetically, a=
ssigning indices from 0 (&quot;abandon&quot;) to 2047 (&quot;zoo&quot;). Th=
e full wordlist is defined in BIP-39 and remains unchanged.</p><p dir=3D"au=
to">For a word with index i (0 =E2=89=A4 i =E2=89=A4 2047):</p><ol dir=3D"a=
uto"><li>Compute high =3D i // 58 (integer division, range 0-35 for i =E2=
=89=A4 2047)</li>
<li>Compute low =3D i % 58 (range 0-57)</li>
<li>The two-character code is alphabet[high] + alphabet[low] (big-endian or=
der, higher digit first)</li>
</ol><p dir=3D"auto">Examples:</p><ul dir=3D"auto"><li>i=3D0 (&quot;abandon=
&quot;): &quot;11&quot;</li>
<li>i=3D2047 (&quot;zoo&quot;): &quot;PJ&quot;</li>
</ul><p dir=3D"auto">Compressing a mnemonic: Look up indices, encode each t=
o 2 chars, concatenate (24 chars for 12 words).</p><p dir=3D"auto">Decompre=
ssing: Split into 2-char chunks, decode indices, look up words, verify chec=
ksum.</p><p dir=3D"auto"><span dir=3D"auto">Multisig Storage Format (Extens=
ion)</span>
</p><p dir=3D"auto">Assumes 12-word mnemonics, 111-char xpubs.</p><p dir=3D=
"auto">Structure: Compressed mnemonic (24 chars) + Sorted foreign xpub1 (11=
1) + xpub2 (111) + Checksum (6 chars) =3D 252 chars.</p><p dir=3D"auto">Che=
cksum: Double-SHA256 of decoded data bytes, first 4 bytes encoded to Base58=
, padded to 6 chars with &#39;1&#39;s.</p><p dir=3D"auto">Verification: Ext=
ract parts, recompute checksum, validate.</p><p dir=3D"auto">Usage in 2-of-=
3: Each location stores local compressed + 2 foreign xpubs + checksum.</p><=
p dir=3D"auto"><span dir=3D"auto"><b>Rationale</b></span>
</p><ul dir=3D"auto">
<li>58^2 =3D 3364 &gt; 2048 for unique codes.</li>
<li>Concatenation leverages Base58 for compactness.</li>
<li>Fixed lengths for easy parsing.</li></ul><p dir=3D"auto"><span dir=3D"a=
uto"><b>Backwards Compatibility</b></span>
</p><p dir=3D"auto">Fully compatible; optional extension.</p><p dir=3D"auto=
"><b><span dir=3D"auto">Reference Implementation</span>
</b></p><p dir=3D"auto">Full Python reference implementation available upon=
 request or in the formal submission.</p><p dir=3D"auto"><b><span dir=3D"au=
to">Test Vectors</span>
</b></p><ul dir=3D"auto">
<li>Compressed mnemonic: &quot;1112131415161718191A1B1C&quot; (first 6 word=
s, extend to 24 chars for full).</li>
<li>xpub1: &quot;xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY=
2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8&quot; (111 chars).</l=
i>
<li>xpub2: &quot;xpub68Gmy5EdvgibQVbouHdFqKg4ZP5oVjJeJUP7yKS4xEM2it2c8EL3ME=
N8WC4PTEiGK8oFUaKUV4ndBKSp53Q6fFi8DwhsBS1Lxf4H9fwnK2&quot; (111 chars).</li=
>
<li>Sorted: xpub1, xpub2 (assuming lex order).</li>
<li>Data str: &quot;1112131415161718191A1B1C&quot; + xpub1 + xpub2 (246 cha=
rs, but use full 24-char compressed in practice).</li>
<li>Checksum: Compute as per code (will be 6 chars, e.g., &quot;2AbCdE&quot=
;).</li>
<li>Full storage: Data str + checksum (252 chars).</li></ul><p dir=3D"auto"=
><span dir=3D"auto"><b>Acknowledgements</b></span>
</p><ul dir=3D"auto">
<li>BIP-39 authors for the foundational wordlist.</li>
<li>Bitcoin community for Base58 standards.</li><li>Multisig distribution i=
nsights.</li></ul><hr><p dir=3D"auto">I&#39;d appreciate any feedback on th=
is draft: Is the concept sound? Are there similar existing proposals I&#39;=
m unaware of? Suggestions for improvements, such as in the checksum method =
or generalization to other word counts/m-n schemes?</p><p dir=3D"auto">If t=
here&#39;s interest, I&#39;ll proceed with the GitHub submission after inco=
rporating comments.</p><p dir=3D"auto">Thank you very much for your attenti=
on to this matter and any insights!</p><p dir=3D"auto">Best regards,
Zach
<a href=3D"mailto:corneliusamadeusacts10@gmail.com" target=3D"_blank">corne=
liusamadeusacts10@gmail.com</a></p></span></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" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/1da0467a-9cc6-4448-85b9-a9b01ef1aca7n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/1da0467a-9cc6-4448-85b9-a9b01ef1aca7n%40googlegrou=
ps.com</a>.<br>
</blockquote></div></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/CAMZUoKkUwb36TJjXOG7ev-aLW1N68Xoz8qq%3DpmSwNL45%2BA%2Bw1g%40mail=
.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.co=
m/d/msgid/bitcoindev/CAMZUoKkUwb36TJjXOG7ev-aLW1N68Xoz8qq%3DpmSwNL45%2BA%2B=
w1g%40mail.gmail.com</a>.<br />

--00000000000033772a0639e9c8bf--