📅 Original date posted:2018-01-06
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180106/db3386a6/attachment.html>;
Adam Ritter [ARCHIVE] /
npub1dw…r3e7q
2023-06-07 18:09:14
in reply to nevent1q…2jzg
Author Public Key
npub1dw9jxy0p6fyd6gxcxsqgp2uhslas47tam2y36kwjyzlryq3tuvtsvr3e7qSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:09:14Event JSON
{
"id": "3ab81263df9ff9e8cdffdb652c2aeffd04b3ff2aa27282c31126c3308f6b623e",
"pubkey": "6b8b2311e1d248dd20d8340080ab9787fb0af97dda891d59d220be32022be317",
"created_at": 1686161354,
"kind": 1,
"tags": [
[
"e",
"45c82b414730d6087d141656cdec1e9fa3d3c7df8a0406cc87e780bba7d95c10",
"",
"root"
],
[
"e",
"08cef7af4c1ae204b551c533afcb63d41f4c6649069109c3ac158fac1936e51a",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-01-06\n📝 Original message:The question that I didn't see answered in the Bech32 proposal is why\nsomething like the BIP39 mnemoic format is not used for addresses as well.\nThere was a lot of math involved in creating it, but I'm not sure how much\nuser experience testing.\n\nI realized how much harder it is to copy random letters and numbers than\nsimple words only when I copied an addresses and a private keys by hand,\nand even after I knew that I made a mistake, it took significant effort to\nfind the place of the mistake.\n\nIn contrast with BIP39 seeds I never made a mistake when writing down\n(although I have seen a case where somebody made a mistake because a word\nwas twice in the same seed, but this is something that could be fixed).\n\n\nOn Fri, Jan 5, 2018 at 10:44 PM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e P2SH^2 wasn't a serious proposal-- I just suggested it as a thought\n\u003e experiment. I don't think it offers much useful in the context of\n\u003e Bitcoin today. Particularly since weight calculations have made output\n\u003e space relatively more expensive and fees are at quite non-negligible\n\u003e rates interest in \"storing data\" in outputs should at least not be\n\u003e increasing.\n\u003e\n\u003e Moreover, unfortunately, people already rushed bech32 to market in\n\u003e advance of practically any public review-- regrettable but it is what\n\u003e it is... I don't think adding more address diversity at this time\n\u003e wouldn't be good for the ecosystem.\n\u003e\n\u003e What we might want to do is consider working on an address-next\n\u003e proposal that has an explicit timeframe of N years out, and very loud\n\u003e don't deploy this--- layered hashing is just one very minor slightly\n\u003e nice to have... things like coded expiration times, abilities to have\n\u003e amounts under checksum, etc. are probably more worth consideration.\n\u003e\n\u003e\n\u003e\n\u003e On Thu, Jan 4, 2018 at 2:23 PM, Luke Dashjr via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e I know I'm super-late to bring this up, but was there a reason Bech32\n\u003e omitted\n\u003e \u003e the previously-discussed P2SH² improvements? Since deployment isn't too\n\u003e \u003e widespread yet, maybe it'd be worth a quick revision to add this?\n\u003e \u003e\n\u003e \u003e For those unfamiliar with the concept, the idea is to have the address\n\u003e include\n\u003e \u003e the *single* SHA256 hash of the public key or script, rather than\n\u003e \u003e RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would\n\u003e then\n\u003e \u003e perform the second hash to produce the output. Doing this would in the\n\u003e future\n\u003e \u003e enable relaying the \"middle-hash\" as a way to prove the final hash is in\n\u003e fact\n\u003e \u003e a hash itself, thereby proving it is not embedded data spam.\n\u003e \u003e\n\u003e \u003e Bech32 seems like a huge missed opportunity to add this, since everyone\n\u003e will\n\u003e \u003e probably be upgrading to it at some point.\n\u003e \u003e\n\u003e \u003e Luke\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180106/db3386a6/attachment.html\u003e",
"sig": "4485cd6b4a7bbee8ee7470bc2ae37395a0ab3d63663430a84f0353f285aeb9c3cd020add1b5115d79fcd2c7f57c9b5c793f177d1b989def047c999aa7f5068ba"
}