Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-05 📝 Original message:I've posted an initial ...
📅 Original date posted:2018-01-05
📝 Original message: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
On Thursday 04 January 2018 2:23:05 PM Luke Dashjr via bitcoin-dev 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message: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
On Thursday 04 January 2018 2:23:05 PM Luke Dashjr via bitcoin-dev 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev