I made slight modification to the BIP, dropping the 0x80 jump to 0x10:
I will make the corresponding changes to the reference implementation shortly.
If there are no objections I would also like to
I took the liberty of turning this into a BIP proposal -- the
formatted version can be seen here:
Title: Typed Private Keys
Author: Karl-Johan Alm
Bech32 and WIF payload format are mostly orthogonal issues. You can design a
new wallet import format now and later switch it to Bech32.
> On Sep 17, 2017, at 7:42 AM, AJ West via bitcoin-dev
> Hi I have a small interjection about the point on
Hi I have a small interjection about the point on error correction (excuse
me if it seems elementary). Isn't there an argument to be made where a
wallet software should never attempt to figure out the 'correct' address,
or in this case private key? I don't think it's crazy to suggest somebody
On 17.09.2017 04:29, Pieter Wuille wrote:
> This has been a low-priority thing for me, though, and the computation work
> to find a good checksum is significant.
Thanks for the info. I guess this means that a bech32 format for private
keys is not going to happen soon. Even if such a format
On Sep 15, 2017 01:56, "Thomas Voegtlin via bitcoin-dev" <
Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.
I've been working on
The Wallet Import Format (WIF) currently appends a 0x01 byte after the
raw private key, when that key needs to be used in conjunction with a
compressed public key. This allows wallets to associate a single Bitcoin
address to a WIF key.
It would be useful to extend the semantics of that byte, to