MIME-Version: 1.0
In-Reply-To: <CAAS2fgQT33QhZrSoGvi=_i0pREuqU+A82zSekFkC1M8av+ufRA@mail.gmail.com>
References: <201801041423.05959.luke@dashjr.org>
	<CAAS2fgQT33QhZrSoGvi=_i0pREuqU+A82zSekFkC1M8av+ufRA@mail.gmail.com>
From: Adam Ritter <aritter@gmail.com>
Date: Sat, 6 Jan 2018 08:05:11 -0200
Message-ID: <CAKuKjyV9aFzVY0__N=P1U4+_zbidZruRFsnD1H9W0aAZhOwsQg@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113eff4e6bb062056218b3bb"
Subject: Re: [bitcoin-dev] =?utf-8?q?Bech32_and_P2SH=C2=B2?=
Precedence: list

--001a113eff4e6bb062056218b3bb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The question that I didn't see answered in the Bech32 proposal is why
something like the BIP39 mnemoic format is not used for addresses as well.
There was a lot of math involved in creating it, but I'm not sure how much
user experience testing.

I realized how much harder it is to copy random letters and numbers than
simple words only when I copied an addresses and a private keys by hand,
and even after I knew that I made a mistake, it took significant effort to
find the place of the mistake.

In contrast with BIP39 seeds I never made a mistake when writing down
(although I have seen a case where somebody made a mistake because a word
was twice in the same seed, but this is something that could be fixed).


On Fri, Jan 5, 2018 at 10:44 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> P2SH^2 wasn't a serious proposal-- I just suggested it as a thought
> experiment. I don't think it offers much useful in the context of
> Bitcoin today. Particularly since weight calculations have made output
> space relatively more expensive and fees are at quite non-negligible
> rates interest in "storing data" in outputs should at least not be
> increasing.
>
> Moreover, unfortunately, people already rushed bech32 to market in
> advance of practically any public review-- regrettable but it is what
> it is... I don't think adding more address diversity at this time
> wouldn't be good for the ecosystem.
>
> What we might want to do is consider working on an address-next
> proposal that has an explicit timeframe of N years out, and very loud
> don't deploy this--- layered hashing is just one very minor slightly
> nice to have... things like coded expiration times, abilities to have
> amounts under checksum, etc. are probably more worth consideration.
>
>
>
> On Thu, Jan 4, 2018 at 2:23 PM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I know I'm super-late to bring this up, but was there a reason Bech32
> omitted
> > the previously-discussed P2SH=C2=B2 improvements? Since deployment isn'=
t too
> > widespread yet, maybe it'd be worth a quick revision to add this?
> >
> > For those unfamiliar with the concept, the idea is to have the address
> include
> > the *single* SHA256 hash of the public key or script, rather than
> > RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would
> then
> > perform the second hash to produce the output. Doing this would in the
> future
> > enable relaying the "middle-hash" as a way to prove the final hash is i=
n
> fact
> > a hash itself, thereby proving it is not embedded data spam.
> >
> > Bech32 seems like a huge missed opportunity to add this, since everyone
> will
> > probably be upgrading to it at some point.
> >
> > Luke
> > _______________________________________________
> > 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
>

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

<div dir=3D"ltr">The question that I didn&#39;t see answered in the Bech32 =
proposal is why something like the BIP39 mnemoic format is not used for add=
resses as well. There was a lot of math involved in creating it, but I&#39;=
m not sure how much user experience testing.<div><br><div>I realized how mu=
ch harder it is to copy random letters and numbers than simple words only w=
hen I copied an addresses and a private keys by hand, and even after I knew=
 that I made a mistake, it took significant effort to find the place of the=
 mistake.</div><div><br></div><div>In contrast with BIP39 seeds I never mad=
e a mistake when writing down (although I have seen a case where somebody m=
ade a mistake because a word was twice in the same seed, but this is someth=
ing that could be fixed).</div><div><br></div></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Fri, Jan 5, 2018 at 10:44 PM, G=
regory Maxwell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">P2S=
H^2 wasn&#39;t a serious proposal-- I just suggested it as a thought<br>
experiment. I don&#39;t think it offers much useful in the context of<br>
Bitcoin today. Particularly since weight calculations have made output<br>
space relatively more expensive and fees are at quite non-negligible<br>
rates interest in &quot;storing data&quot; in outputs should at least not b=
e<br>
increasing.<br>
<br>
Moreover, unfortunately, people already rushed bech32 to market in<br>
advance of practically any public review-- regrettable but it is what<br>
it is... I don&#39;t think adding more address diversity at this time<br>
wouldn&#39;t be good for the ecosystem.<br>
<br>
What we might want to do is consider working on an address-next<br>
proposal that has an explicit timeframe of N years out, and very loud<br>
don&#39;t deploy this--- layered hashing is just one very minor slightly<br=
>
nice to have... things like coded expiration times, abilities to have<br>
amounts under checksum, etc. are probably more worth consideration.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On Thu, Jan 4, 2018 at 2:23 PM, Luke Dashjr via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; I know I&#39;m super-late to bring this up, but was there a reason Bec=
h32 omitted<br>
&gt; the previously-discussed P2SH=C2=B2 improvements? Since deployment isn=
&#39;t too<br>
&gt; widespread yet, maybe it&#39;d be worth a quick revision to add this?<=
br>
&gt;<br>
&gt; For those unfamiliar with the concept, the idea is to have the address=
 include<br>
&gt; the *single* SHA256 hash of the public key or script, rather than<br>
&gt; RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would =
then<br>
&gt; perform the second hash to produce the output. Doing this would in the=
 future<br>
&gt; enable relaying the &quot;middle-hash&quot; as a way to prove the fina=
l hash is in fact<br>
&gt; a hash itself, thereby proving it is not embedded data spam.<br>
&gt;<br>
&gt; Bech32 seems like a huge missed opportunity to add this, since everyon=
e will<br>
&gt; probably be upgrading to it at some point.<br>
&gt;<br>
&gt; Luke<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--001a113eff4e6bb062056218b3bb--