[bitcoin-dev] Bech32 and P2SH²

[Luke Dashjr via bitcoin-dev]

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

[Luke Dashjr via bitcoin-dev]

I've posted an initial draft of a possible Bech32 revision/replacement here:

https://github.com/luke-jr/bips/blob/new_bech32_p2sh2/bip-bech32-p2sh2.mediawiki

Post by Luke Dashjr via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gregory Maxwell via bitcoin-dev]

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

Post by Luke Dashjr via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Adam Ritter via bitcoin-dev]

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 <

Post by Gregory Maxwell via bitcoin-dev
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

Post by Luke Dashjr via bitcoin-dev
I know I'm super-late to bring this up, but was there a reason Bech32

omitted

Post by Luke Dashjr via bitcoin-dev
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

Post by Luke Dashjr via bitcoin-dev
the *single* SHA256 hash of the public key or script, rather than
RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would

then

Post by Luke Dashjr via bitcoin-dev
perform the second hash to produce the output. Doing this would in the

future

Post by Luke Dashjr via bitcoin-dev
enable relaying the "middle-hash" as a way to prove the final hash is in

fact

Post by Luke Dashjr via bitcoin-dev
a hash itself, thereby proving it is not embedded data spam.
Bech32 seems like a huge missed opportunity to add this, since everyone

will

Post by Luke Dashjr via bitcoin-dev
probably be upgrading to it at some point.
Luke
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev