From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9565AC002B for ; Thu, 16 Feb 2023 13:49:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 6EFC641825 for ; Thu, 16 Feb 2023 13:49:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6EFC641825 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=mail.wpsoftware.net header.i=@mail.wpsoftware.net header.a=rsa-sha256 header.s=default header.b=m1nxArJp X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCSzA7KxBPiI for ; Thu, 16 Feb 2023 13:49:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 087D44180F Received: from mail.wpsoftware.net (unknown [66.183.0.205]) by smtp4.osuosl.org (Postfix) with ESMTP id 087D44180F for ; Thu, 16 Feb 2023 13:49:54 +0000 (UTC) Received: from camus (camus-andrew.lan [192.168.0.190]) by mail.wpsoftware.net (Postfix) with ESMTPSA id 489954020A; Thu, 16 Feb 2023 13:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net; s=default; t=1676555394; bh=o9i+J5FAOW76ctw1I5CRvCQ8yWKRkgJCV39w9TUEGXY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=m1nxArJpCe1xEAzhWbmFVkz/hbzeasDUYnP/2sFChNWRPla2/Nzdmce4pC3YrC6Bl vhyYYlJ0dfixurzUgDCEm//+sNZGMBp7C6MNoWg0E919BJmZj4WSU7ScYq+4GGo4JQ 62SsEOt0JMLtVmxT2Gqrb8WPaLrfIwAP8QkU+hr2DjJNvEO6RpmOYOSLLuSWXfJDTJ oWtLHbtc+H3T8NUbioqPgAS3tjWqSfohhDF1ur3ojgotD3xA0xDBEl2gnHVQZ2ei7f igBUco9cjNRtMchP1JJYSpMT2drRmDMkXB8n8SYkfAQsZ3y9ublBD8zNh4Ng5I2XmU e9V8eaDy2TRDg== Date: Thu, 16 Feb 2023 13:49:53 +0000 From: Andrew Poelstra To: Pavol Rusnak , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bOTHs6MaIIwLvf7w" Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Codex32 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2023 13:49:56 -0000 --bOTHs6MaIIwLvf7w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2023 at 12:50:12PM +0100, Pavol Rusnak via bitcoin-dev wrot= e: > Hi! >=20 > The BIP states that its only advantage over SLIP-0039, which has been used > in production for nearly three years (in at at least 3 SW/HW wallet > implementations), is that it aims to be simple enough for hand computatio= n. > However, the BIP also indicates that "details of hand computation are > outside the scope of this standard, and implementers do not need to be > concerned with this possibility." Therefore, I am curious about how > significant this advantage over SLIP-0039 really is. If hand computation = is > not straightforward and there are no other substantial advantages over > SLIP-0039, I cannot help but feel that this BIP is simply a result of > not-invented-here syndrome, but please correct me if I am wrong. > In my view, the hand computation is actually the main benefit of this scheme. The process *is* straightforward, but tedious enough (and the security benefits obscure enough, though they really shouldn't be... "computers are opaque and untrustworthy" should be a common sentiment) that it's hard to expect more than a small absolute number of users to actually do it. But for the purpose of the *standard*, what is important is that it is possible to implement and use this within a normal hww workflow. This is important for hand-computing users who know that their coins will not die with them (since the 'standard' has fallen into obscurity), and important for "normal" users who have the option to seamlessly switch over to hand computation as the BTC price goes up or the world becomes scarier. For what it's worth, the draft lists several benefits over SLIP-0039. I agree that none of them are particularly strong [1], and even together they probably wouldn't meet the threshold to take the time to write a standard, but I assure you the motivation was not NIH :). > Keep in mind that the encoded shares in SLIP-0039 consist of exactly 200 = or > 330 bits, both of which are divisible by 5. This makes it straightforward > to encode them as Bech32 strings. >=20 This is true! And very convenient for people who may want to simply "layer on" the codex32 checksum/splitting logic onto their SLIP39 words. They can use a lookup table to do the conversion, spend years or whataever doing hand-computation on them, and then use a lookup table to go back. [1] One listed reason is that "a SLIP is not a BIP". I have heard people speculate that this is one reason SLIP-0039 is not nearly as widespread as BIP-0039, even though it is objectively a far better standard. I'm unsure whether I believe this, but "there is no other BIP" does seem like a good reason for BIP-0039's continued dominance. At the very least, it means that on BIP-0039 itself we have nothing that we could say "supercedes" or "is recommended instead of" the BIP. See https://github.com/bitcoin/bips/pull/1413 So it's something of an aside, but I think it would probably be good for the ecosystem (though maybe bad for this BIP's prospects :)) if you would request a BIP number for SLIP-0039. --=20 Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster --bOTHs6MaIIwLvf7w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmPuNH8ACgkQxYjWPOQb l8G9dgf9E4X4TGfkxuWvzVWyorJ1K47E0oNLf5sGu6dr3+ajiKLDqlz/yELit2Hz /yV4Ph9ZDycrVnCEMuIGNpLrHAJSd/PPecaECfAuScWSCp4rUndJgdfcXdVcaZJf 7EHTqGTkyQJCUAzXvmxP+p7u9t9x0EfBVE8DIZnP+QOGiqThpjrZQMZ7GQ4fBKV8 Bl4Gk2UP+MefITcLIuLJErGTyn8g92lnuazM5UywsgzKMM2RocHqBQMgbfWpYXUB typvuNBxjRTd3xqbUX+Z7jM82ndnmjXrZsMauLkM/SQdZBXIt+seG8BNrvHjbfzV ePVeC5gMLGZkhYXsQz2XuDi7Ty+xPA== =f9Tk -----END PGP SIGNATURE----- --bOTHs6MaIIwLvf7w--