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² 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 in
> 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
>