public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      reply	other threads:[~2018-01-06 10:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-04 14:23 [bitcoin-dev] Bech32 and P2SH² Luke Dashjr
2018-01-06  0:26 ` Luke Dashjr
2018-01-06  0:44 ` Gregory Maxwell
2018-01-06 10:05   ` Adam Ritter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKuKjyV9aFzVY0__N=P1U4+_zbidZruRFsnD1H9W0aAZhOwsQg@mail.gmail.com' \
    --to=aritter@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=greg@xiph.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox