Re: [bitcoin-dev] Bech32 and P2SH²

From: Adam Ritter <aritter@gmail•com>
To: Gregory Maxwell <greg@xiph•org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bech32 and P2SH²
Date: Sat, 6 Jan 2018 08:05:11 -0200	[thread overview]
Message-ID: <CAKuKjyV9aFzVY0__N=P1U4+_zbidZruRFsnD1H9W0aAZhOwsQg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQT33QhZrSoGvi=_i0pREuqU+A82zSekFkC1M8av+ufRA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4252 bytes --]