summaryrefslogtreecommitdiff
path: root/a7/466ed9fd1c36a4b293afeea55c92865d5b883e
blob: 15e1c24ee5e800ec7eecb0ecbabfa9f1fa6f60b8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
Return-Path: <nullius@nym.zone>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 582449C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 25 Dec 2017 21:28:57 +0000 (UTC)
X-Greylist: delayed 00:06:35 by SQLgrey-1.7.6
Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 210983CA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 25 Dec 2017 21:28:56 +0000 (UTC)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx2.mailbox.org (Postfix) with ESMTPS id A361F4CA43
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 25 Dec 2017 22:22:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241])
	by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de
	[80.241.56.117]) (amavisd-new, port 10030) with ESMTP id Ms-4euXOqCUQ
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 25 Dec 2017 22:22:13 +0100 (CET)
Date: Mon, 25 Dec 2017 21:21:57 +0000
From: nullius <nullius@nym.zone>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <9b39902347ba7cd03974f6068f025c98@nym.zone>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="pvnxewz54n5wjxgj"
Content-Disposition: inline
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 25 Dec 2017 21:33:23 +0000
Subject: [bitcoin-dev] Bravo Charlie One: Branding Bech32
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Mon, 25 Dec 2017 21:28:57 -0000


--pvnxewz54n5wjxgj
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I here record for the devs a thought I had a few days ago on the Bitcoin=20
Forum about BIP 173 Bech32 addresses.  I=E2=80=99ve heard Greg Maxwell say =
that=20
=E2=80=9CBech32 is designed for human use and basically nothing else=E2=80=
=9D; so I hope=20
I be not untoward in considering the following human-friendliness=20
enhancement to entwine with the technical ambit of this list.  This MAY=20
be suitable for mention in an informative specification, or informative=20
section thereof.

To help gain user familiarity with and acceptance of the=20
error-correcting, case-insensitive Bitcoin addresses of the future, I=20
propose a need for what I think marketers call =E2=80=9Cbranding=E2=80=9D. =
 The best=20
branding is that which derives naturally from some intrinsic quality of=20
a thing; wherefore I look to what may perhaps be a bit of serendipity in=20
the specification.

I expect that in practical use, one of the great advantages of Bech32=20
addresses will be the relative ease of communicating them=20
aloud=E2=80=94especially over the phone.  In similar circumstances, when tr=
ying=20
to convey unusual names or pseudorandom strings, I=E2=80=99ve found radio=
=20
alphabets to work well at their intended purpose.  And when reading=20
Bech32 Bitcoin addresses in the most popular radio alphabet, they will=20
always start with a catchy phrase:  =E2=80=9CBravo Charlie One=E2=80=9D.

That=E2=80=99s memorable, $SEARCH-able, and yet also one of those unique,=
=20
otherwise meaningless phrases which gets marketers excited.  Keeping to=20
a word triplet, I hereby submit for consideration as the official=20
nickname for Bech32 Bitcoin use:  =E2=80=9CBravo Charlie Addresses=E2=80=9D=
=2E  These are=20
the Bitcoin addresses with the magic words, suitable for a motto: =20
=E2=80=9CBravo Charlie One means money.=E2=80=9D  Add a logo =C3=A0 la Segw=
it=E2=80=99s, and raise=20
user awareness of this exciting new technology!

Beyond the branding issue, recommendations for Bitcoin spelling-alphabet=20
use in English and other languages may perhaps be a suitable matter for=20
such standardization as would facilitate coherent user documentation.  I=20
invite discussion.

Of course, this branding only applies directly to Bitcoin Bech32=20
addresses.  The BIP 173 authors were gracious to make the standard=20
generally adaptable; and it has already seen some uptake amongst=20
altcoins.  I myself am now contemplating how Bech32 would be a superior=20
human-facing format for key fingerprints for PGP, SSH, and even TLS,=20
with HRPs of =E2=80=9Cpgp=E2=80=9D, =E2=80=9Cssh=E2=80=9D, =E2=80=9Ctls=E2=
=80=9D, etc. and some appropriate means of=20
embedding the key type just as =E2=80=9Cbc=E2=80=9D embeds the witness vers=
ion.  There=20
is an urgent general need for a specification which reduces the inherent=20
pain of wetware in handling pseudorandom strings; and I do think that=20
anything which familiarizes users with Bech32 in a specific use will be=20
beneficial to Bech32 adoption generally.

To celebrate, as seen in my sig, I created for myself a new Bravo=20
Charlie Address which expresses that I am pleased:  Now, I have an=20
error-correcting, case-insensitive address which can receive only=20
genuine Bitcoin cash money.  Because =E2=80=9CBravo Charlie One means money=
=2E=E2=80=9D

Here=E2=80=99s to the Bitcoin address format of the future!

--=20
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have noth=
ing to hide.=E2=80=99
No!  Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80=94=
 nullius

--pvnxewz54n5wjxgj
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWkFr9AAKCRDEJ5MVn575
STbpAP0YZsBEpzqP3KmvwiVTajQ2J6er22qusINdLRhgw0eq3gD/ZEd/4EtGQ/Ep
S4qF6ll/R0SeZ1bFQ6aaHZ4F5i2UyQQ=
=hXoa
-----END PGP SIGNATURE-----

--pvnxewz54n5wjxgj--