From: Gregory Maxwell <greg@xiph•org>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bech32 and P2SH²
Date: Sat, 6 Jan 2018 00:44:20 +0000 [thread overview]
Message-ID: <CAAS2fgQT33QhZrSoGvi=_i0pREuqU+A82zSekFkC1M8av+ufRA@mail.gmail.com> (raw)
In-Reply-To: <201801041423.05959.luke@dashjr.org>
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
next prev parent reply other threads:[~2018-01-06 0:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 14:23 Luke Dashjr
2018-01-06 0:26 ` Luke Dashjr
2018-01-06 0:44 ` Gregory Maxwell [this message]
2018-01-06 10:05 ` Adam Ritter
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='CAAS2fgQT33QhZrSoGvi=_i0pREuqU+A82zSekFkC1M8av+ufRA@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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