summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTrey Del Bonis <j.delbonis.3@gmail.com>2019-12-24 20:02:09 -0500
committerbitcoindev <bitcoindev@gnusha.org>2019-12-25 01:02:24 +0000
commit5d66ba714251fc54bf8f0ef276c6ed54b36d20e6 (patch)
tree3ac49ea12701c18ed6c223a23f07b310a38ab5e8
parent3a08dd4a5a1d983b932c0d59626726dbfa601311 (diff)
downloadpi-bitcoindev-5d66ba714251fc54bf8f0ef276c6ed54b36d20e6.tar.gz
pi-bitcoindev-5d66ba714251fc54bf8f0ef276c6ed54b36d20e6.zip
Re: [bitcoin-dev] Base64-encoded descriptors
Diffstat
-rw-r--r--03/49caa9b7799a455a310e5822ee03cf6dbd9d19215
1 files changed, 215 insertions, 0 deletions
diff --git a/03/49caa9b7799a455a310e5822ee03cf6dbd9d19 b/03/49caa9b7799a455a310e5822ee03cf6dbd9d19
new file mode 100644
index 000000000..c0d90f16b
--- /dev/null
+++ b/03/49caa9b7799a455a310e5822ee03cf6dbd9d19
@@ -0,0 +1,215 @@
+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--
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-17 14:17:31 +0000