public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Bech32 and P2SH²
@ 2018-01-04 14:23 Luke Dashjr
  2018-01-06  0:26 ` Luke Dashjr
  2018-01-06  0:44 ` Gregory Maxwell
  0 siblings, 2 replies; 4+ messages in thread
From: Luke Dashjr @ 2018-01-04 14:23 UTC (permalink / raw)
  To: 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


^ permalink raw reply	[flat|nested] 4+ messages in thread

• * Re: [bitcoin-dev] Bech32 and P2SH²
    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
    1 sibling, 0 replies; 4+ messages in thread
  From: Luke Dashjr @ 2018-01-06  0:26 UTC (permalink / raw)
    To: 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
  
  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@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  
  
  ^ permalink raw reply	[flat|nested] 4+ messages in thread

• * Re: [bitcoin-dev] Bech32 and P2SH²
    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
    1 sibling, 1 reply; 4+ messages in thread
  From: Gregory Maxwell @ 2018-01-06  0:44 UTC (permalink / raw)
    To: Luke Dashjr, Bitcoin Protocol Discussion
  
  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
  
  
  ^ permalink raw reply	[flat|nested] 4+ messages in thread

• • * Re: [bitcoin-dev] Bech32 and P2SH²
      2018-01-06  0:44 ` Gregory Maxwell
    @ 2018-01-06 10:05   ` Adam Ritter
      0 siblings, 0 replies; 4+ messages in thread
    From: Adam Ritter @ 2018-01-06 10:05 UTC (permalink / raw)
      To: Gregory Maxwell, Bitcoin Protocol Discussion
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-01-06 10:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox