path: root/03/49caa9b7799a455a310e5822ee03cf6dbd9d19

Return-Path: <j.delbonis.3@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 43CEDC0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Dec 2019 01:02:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id C635981BA0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Dec 2019 01:02:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id F-8sUaem0nAI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Dec 2019 01:02:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com
 [209.85.219.53])
 by hemlock.osuosl.org (Postfix) with ESMTPS id D52DB86D41
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Dec 2019 01:02:22 +0000 (UTC)
Received: by mail-qv1-f53.google.com with SMTP id dc14so7902679qvb.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Dec 2019 17:02:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=6f8Hqffc3lwfPBI6VTdc95+qfhdvmwIIvx0f4gqXp3M=;
 b=jalGhWZpusbnXL12+DEdvj4pj2VDiOzAh9oGYj0clSHH8ZxnZRHkvYIxb9zSc/6bhD
 nkx9ZdmGHa4hySy2FF+TaFf0xJ4d4xmZe7sUixe25hw/ZU+BU3+lz03Au/Ku2mSIA7Jg
 5SCmlRzzZuAP7TgspuPisbBUD+6cGfD7zvrDxvI7Ki4IpH6ynKHRDeHe8PFC1OzBiKn7
 Q4xmeuwt9hNWvLmJX7kVtXb9wD2PefrUbXM9vyLwNFtmV/E8/GQN32rXx2qI0WzaQZFF
 e4nSyuM3Ojsvz9slbBPFdSlOaHkjYo/JJbJRPWJv4hK4aHK6j5t4EJZPsIgkVW6EDC9L
 AWCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=6f8Hqffc3lwfPBI6VTdc95+qfhdvmwIIvx0f4gqXp3M=;
 b=cGVi+1LZx9cu5o4b770R0tHJM/1oikF5AQkrXSERTjJiIeWsa2SVmN/y0jlQN5E73z
 FbVK5xuQuncFB31cPKkxrFgfGNTSes7mgQCOGwyvrzpMljBWI1rIvFLFzi6R64D+hKkx
 JOZHEhbW+7LFbY71q1KD7PbJ/XiQ1HFDfO5HpEQPIl1Mt5NSOHfBlS68HjBOQmH79Vgq
 2c5Gmw2be3kgY4XhiqgrmhWgoO4+ZaBm1b2/9beY5b9pMZvdW2J7BDQImF0oLMNaz34F
 5B2Tr0XbttMQsMucJ94UgS6aZ+slaXV3FFPcWr5C9AV1vJm2gk21IiftxSAQ39qmUzOt
 FGbg==
X-Gm-Message-State: APjAAAVcoRS4+3HTylut7Srm0wT4N3V5k/6skbuoiPQWrPW0E+6Y/n8U
 H1uuoCVHBqzA0Jbu9YMRaEsoQlAm0UQd6C1PLqE=
X-Google-Smtp-Source: APXvYqzLp7OgSkfLB+mczTfe70+erze9VTzbKWP05mPs1BysENY0IlmFIRxlxU2g/jbrfR6Sk/eS6XIEsw85TPKaISI=
X-Received: by 2002:a0c:f4c9:: with SMTP id o9mr16680569qvm.157.1577235741750; 
 Tue, 24 Dec 2019 17:02:21 -0800 (PST)
MIME-Version: 1.0
References: <deb1cedd-ae7d-4ef2-6b89-104183b919b4@riseup.net>
 <CAOB=H7qZ55XXncp9ovR8YpXwBwoVMO=WmbPS_aRxdqk0dFoEiQ@mail.gmail.com>
In-Reply-To: <CAOB=H7qZ55XXncp9ovR8YpXwBwoVMO=WmbPS_aRxdqk0dFoEiQ@mail.gmail.com>
From: Trey Del Bonis <j.delbonis.3@gmail.com>
Date: Tue, 24 Dec 2019 20:02:09 -0500
Message-ID: <CAFUsdzp5d=0ErFZPfyB4Lh84HiCpWB+CfuYWRTfsFOfXL0sz4Q@mail.gmail.com>
To: "Spencer Dupre`" <spencer.dupre@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001d3a42059a7cd061"
X-Mailman-Approved-At: Wed, 25 Dec 2019 08:24:38 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Dec 2019 01:02:24 -0000

--0000000000001d3a42059a7cd061
Content-Type: text/plain; charset="UTF-8"

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.

QR codes (as Pavol mentioned) have built-in error detection (using its own
BCH code scheme), somewhat mitigate this when used there.  Although
personally I'm skeptical of how useful payment descriptors are for the
kinds of quick transactions that QR codes work well for.

-Trey

On Tue, Dec 24, 2019, 6:55 PM Spencer Dupre` via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Sounds like a good UX improvement, but do we really need to introduce a
> new encoding? Perhaps bech32 could be used instead.
>
> On Tue, Dec 24, 2019, 12:07 PM Chris Belcher via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I've recently been playing around with descriptors, and they are very
>> nice to work with. They should become the standard for master public
>> keys IMO.
>>
>> One downside is that users cant easily copypaste them to-and-fro to make
>> watch-only wallet. The descriptors contain parenthesis and commas which
>> stop highlighting by double-clicking. Also the syntax might look scary
>> to newbs.
>>
>> An obvious solution is to base64 encode the descriptors. Then users
>> would get a text blog as the master public key without any extra details
>> to bother them, and developers can easily base64 decode for developing
>> with them.
>>
>> A complication might be the descriptor checksum. If there's a typo in
>> the base64 text then that could decode into multiple character errors in
>> the descriptor, which might be problematic for the checksum. Maybe the
>> descriptor could be base64 encoded without the checksum, then attach the
>> checksum to the end of the base64 text.
>>
>> Thoughts?
>>
>> I didn't come up with these ideas, they came from discussions with
>> achow101.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div>Part of the aversion to using bech32 may be that the=
 BCH code used in bech32 for error detection doesn&#39;t hold up for messag=
es longer than some length (that I can&#39;t remember off the top of my hea=
d).=C2=A0 It still encodes and decodes perfectly well but a decoder won&#39=
;t be guaranteed to detect potential errors, so that&#39;s somewhat wasted =
there.=C2=A0 Maybe someone should define a derivatives of bech32 that retai=
ns error detection properties for longer message lengths, such as those use=
d in lightning invoices.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>QR codes (as Pavol mentioned) have built-in error detection (using its own=
 BCH code scheme), somewhat mitigate this when used there.=C2=A0 Although p=
ersonally I&#39;m skeptical of how useful payment descriptors are for the k=
inds of quick transactions that QR codes work well for.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">-Trey<br><br><div class=3D"gmail_quote" dir=
=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 24, 2019, 6:55 =
PM Spencer Dupre` via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"auto">Sounds like a good UX improvement, but do we really need =
to introduce a new encoding? Perhaps bech32 could be used instead.</div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, D=
ec 24, 2019, 12:07 PM Chris Belcher via bitcoin-dev &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer noreferrer" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">I&#39;ve recently been playing around with de=
scriptors, and they are very<br>
nice to work with. They should become the standard for master public<br>
keys IMO.<br>
<br>
One downside is that users cant easily copypaste them to-and-fro to make<br=
>
watch-only wallet. The descriptors contain parenthesis and commas which<br>
stop highlighting by double-clicking. Also the syntax might look scary<br>
to newbs.<br>
<br>
An obvious solution is to base64 encode the descriptors. Then users<br>
would get a text blog as the master public key without any extra details<br=
>
to bother them, and developers can easily base64 decode for developing<br>
with them.<br>
<br>
A complication might be the descriptor checksum. If there&#39;s a typo in<b=
r>
the base64 text then that could decode into multiple character errors in<br=
>
the descriptor, which might be problematic for the checksum. Maybe the<br>
descriptor could be base64 encoded without the checksum, then attach the<br=
>
checksum to the end of the base64 text.<br>
<br>
Thoughts?<br>
<br>
I didn&#39;t come up with these ideas, they came from discussions with acho=
w101.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--0000000000001d3a42059a7cd061--