From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3395AC0881 for ; Thu, 26 Dec 2019 05:18:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 1D1BB81F72 for ; Thu, 26 Dec 2019 05:18:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9GVrpd4o8Sz for ; Thu, 26 Dec 2019 05:18:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by whitealder.osuosl.org (Postfix) with ESMTPS id 4B45D81F63 for ; Thu, 26 Dec 2019 05:18:08 +0000 (UTC) Date: Thu, 26 Dec 2019 05:18:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1577337484; bh=hJtcOzDWhzm4+zfCpqTkCElT1yUaEsfs2dXHHShSnLM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=hAdh04+CtvDwuzFH/IRuHBNPt4g82hzO+A3V/4kmY95bu+RUUbFgFcBxdRC9o4xxr SVkLljoEzhaz1HlKrKvp/dC9EVmNjboMQtWhS1+06T8/vMlCcGUrVKyu/4jaSreQvT hpt4BFyKVERemV49PfoVqcKZVVhzFJ9UnlZFJhuc= To: William Casarin , Spencer Dupre` , Chris Belcher , Trey Del Bonis , Pavol Rusnak From: Andrew Chow Reply-To: Andrew Chow Message-ID: <60e86243-8aa7-8b67-1547-9114d6f1f1cd@achow101.com> In-Reply-To: <87sgl8mijl.fsf@jb55.com> References: <87sgl8mijl.fsf@jb55.com> Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Base64-encoded descriptors 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, 26 Dec 2019 05:18:11 -0000 Hi All, Just a few comments about choosing an encoding and why this is even being proposed. On Wednesday, December 25, 2019 12:17 PM, William Casarin via bitcoin-dev wrote: > I don't think encoding descriptors is a good idea. Encoding makes more > sense if it's non-human-readable binary data that you want transfer > over > a plaintext channel. > > Descriptors aren't binary data, and have a wealth of useful > information > that you can view at a glance. Obfuscating this information just to > gain > the ability to copy-paste doesn't seem like a good idea. The main reasons this was proposed in the first place is because of concerns that users will be unwilling to use or be confused by descriptors. There is a concern that users will not understand the commas, parentheses, brackets, etc. syntax of descriptors and thus only copy part of it. There is also the concern that users will see this code-like syntax and be intimidated by it so they will not want to handle them. So my (offhanded) suggestion was to encode it in some way to just make it look like some magic string that they need to handle as one unit. > so I'm a bit sad that base64 was > chosen. base64 isn't really good for double-click copy-pasting, it > contains characters such as +/=3D which aren't always included when > double-clicking. I prefer bech32, base58 or base62. On Tuesday, December 24, 2019 2:09 PM, Spencer Dupre` via bitcoin-dev wrote: > Sounds like a good UX improvement, but do we really need to introduce a new encoding? Perhaps bech32 could be used instead. On Tuesday, December 24, 2019 2:25 PM, Pavol Rusnak via bitcoin-dev wrote: > I'd rather see something using Base58 or even better Bech32. Base64 is not URL/QR code friendly. A different encoding scheme could certainly be used. Base64 was suggested in my comments to Chris and others as it is a well known encoding scheme that doesn't already define its own checksum as Base58 and Bech32 do. This is an important detail because descriptors *also* have their own checksum scheme. While other encoding methods could be used, I do want to point out that it would be nice to stick to things that already exist. We could use a bech32-like encoding, just with the different BCH code that descriptors use instead of the bech32 code, but calling that bech32 would be a bit confusing. And I don't think we should use Base58 at all. On Tuesday, December 24, 2019 8:02 PM, Trey Del Bonis via bitcoin-dev wrote: > Part of the aversion to using bech32 may be that the BCH code used in > bech32 for error detection doesn't hold up for messages longer than > some length (that I can't remember off the top of my head). It still > encodes and decodes perfectly well but a decoder won't be guaranteed > to detect potential errors, so that's somewhat wasted there. Maybe > someone should define a derivatives of bech32 that retains error > detection properties for longer message lengths, such as those used in > lightning invoices. Descriptors already have their own BCH code for descriptor checksums optimized for their length and character rset. This can be repurposed to be used with whatever encoding scheme is chosen so long as the encoding's character set is covered by the descriptor checksum character set. The checksum's character set is fairly large and covers all(?) characters on a standard keyboard so that descriptors could be expanded with other features in the future. Thus it should cover any encoding scheme that is suggested. More information about the descriptor checksum can be found at https://github.com/bitcoin/bitcoin/blob/master/src/script/descriptor.cpp#L2= 6