The first one is replacing Base-58 with Bech-32 encoding
Direct link to the code: https://github.com/Autarkysoft/Denovo/blob/master/Src/Autarkysoft.Bitcoin/Experimental/Bech32PrivateKey.cs
Here is an example with a random key:
Code:
Original WIF (Base-58):
L28Peud5cQcijrtMthAdUS8FynpM8PKZtnoUZb1VAio9WxKoebHt
Key bytes (Base-16):
92734fe879f662ff8ee4eb87dd019425e2ee73ff3edd0c4dc3def2f71e1a6a69
Version byte (ie. the script type): 0x02 or P2WPKH
Date UTC: 5/4/2020 7:11:05 AM
H.R.P.: bprv
New encoding (versioned Bech-32):
bprv1zjfe5l6re7e30lrhyawra6qv5yh3wuull8mwscnwrmme0w8s6df5sns90tcqqzyen4e
L28Peud5cQcijrtMthAdUS8FynpM8PKZtnoUZb1VAio9WxKoebHt
Key bytes (Base-16):
92734fe879f662ff8ee4eb87dd019425e2ee73ff3edd0c4dc3def2f71e1a6a69
Version byte (ie. the script type): 0x02 or P2WPKH
Date UTC: 5/4/2020 7:11:05 AM
H.R.P.: bprv
New encoding (versioned Bech-32):
bprv1zjfe5l6re7e30lrhyawra6qv5yh3wuull8mwscnwrmme0w8s6df5sns90tcqqzyen4e
Note that key is encoded the same way an address would be encoded (version byte is added separately as a 5-bit value instead of 8-bit).
If you know of any work done similar to this idea please post it here.
I'm addressing some of the problems with current encoding of private keys:
1) Using Bech32 encoding instead of Base58
While writing a private key recovery tool I've felt how hard it is to come up with an optimized algorithm to recover a key that is missing a couple of characters (eg. a damaged paper wallet). That is not true with Bech32 being a multiply of base-2 algorithm is inherently faster, and the checksum is not a bottleneck since it is not a hash algorithm. Bech32 also has the benefit of having error detection.
2) Script (address) type
Currently when a user imports/sweeps a private key in a wallet client, that client either has to explicitly ask user for the script type (like Electrum) which means user is exposed to complications and has to be familiar with script types; or the wallet has to construct all script types and scan the blockchain for all of them (like bitcoin core) which adds more burden on the client.
If the encoding included a script type that becomes so much easier.
3) Locktime!
Another burden on both clients and users (specially full node users) is the time consuming need for a re-scan of the entire blockchain to find the historical transactions that belong to an imported key.
A timestamp can make that process a lot shorter.
Using locktime (similar to last 4 bytes of any transaction) the key string (aka WIF) could include either a block height or a date-time value of when the key was created.