When I said BIP39 I was talking about the initial step which is only a simple encoding of binary into words and has nothing to do with key derivation:

00001100 001 = 97 = armor
01000 111111 = 575 = element
and so on.

NATO phonetic alphabet is only useful when you want to spell something out, otherwise for writing things down (such as the case with printing a private key as paper wallet/cold storage) they have no advantage. If words is desired instead of a private key, the raw bytes of a key could simply be converted to a mnemonic phrase using a similar approach as BIP39.

As for the rest of your idea (error detection/correction), I suggest you check out the Bech32 encoding that is already in use for SegWit addresses, if you haven't already. The usage of BCH codes improves error detection of this encoding. Although it is not yet used for private keys, it could be.

This is a very odd decision in my opinion. Wtxids are not used anywhere (so it shouldn't be pre-computed already) and they are more expensive to compute, since the purpose is "optimization" using them seems to add to the overall time.

Imagine the simplest SegWit transaction, one that is spending 1x P2WPKH and creates 2x new outputs. To compute txid you'd have to compute 2x SHA256 of ~116 bytes but for computing wtxid you'd have to compute 2x SHA256 of ~225 bytes. The first round of these two require: 2 blocks and 4 blocks respectively. So the speed of computing txid in this case is nearly twice the speed of computing wtxid for a simple tx.
If the number of inputs were higher or if this was a longer witness (eg. spending a P2WSH of a 2of3 multisig scheme) the difference would be drastically more.

As you may know there are many numeric values used in the bitcoin blockchain, each representing a different thing: version, script lengths, locktime,... and since a block is just a sequence of octets (bytes) that is transferred between nodes and stored on disk, we have to convert these integer values into octet strings (byte arrays) and back.
But what you may not have ever noticed is that in bitcoin, depending on what that integer represents a different approach is chosen for its conversion to bytes, resulting in 6 different ways of encoding integers!

The following is an example transaction from BIP-143 containing 5 out of 6 methods listed below with each one highlighted according their type:

01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f
00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e
5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01
eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000
0000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d59
88ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247
304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a022057
3a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e831
88368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000

---

1. Fixed length little endian
This is the easiest and most common way. It is used for block/transaction version, block time, block target, block nonce, TxIn.Outpoint.Index, TxIn.Sequence and TxOut.Amount and locktime.
The integer will be converted to a little endian byte array of fixed 4 bytes length, with the exception of TxOut.Amount which is 8 bytes.

2. Variable length big endian
This is only used for bigger values in signatures (R and S) using signed notation (most significant bit indicates sign) and public keys (X and Y coordinate). They are always preceded by their length using StackInt (scripts) or CompactInt (witnesses) format.

3. CompactInt
This is a special format used in bitcoin only that can encode from 0 to 2⁶⁴-1 values. It is used for script lengths, input/output count, witness item count and witness item length.

4. DerInt
(Not an official name) This method is used in DER encoding and can encode from 0 to 2¹⁰⁰⁸ length integers. This is only used for encoding signatures (only uses up to 33 bytes lengths). It indicates the length part in DER's Tag-Length-Value encoding scheme.

5. StackInt
(Not an official name) This method is used in bitcoin only to indicate length of the data that is supposed to be pushed onto the stack. It can encode from 0 to 2³²-1 values.

6. Short form integers inside scripts
In bitcoin script language, the stack is an array of bytes. Sometimes these bytes could be interpreted as integers, or an integer could be pushed to the stack. To do that a special format is used:
if there is an OP code for the value (OP_0, OP_NegativeOne,...) that single byte is used.
if there is no OP code, integer is converted to byte array in little endian order in shortest form (no extra zeros) and sign is determined based on most significant bit.

Example: How does 254 (0b11111110) look like in each encoding?
Spoiler (select/highlight to see text):
1. 0xfe000000
3. 0xfdfe00
4. 0x81fe
5. 0x4cfe
6. 0xfe00

This would make derivation exponentially hard. Right now if you want to get your i^th key you perform 1 hash: HMACSHA512(data || i) so if you want 100^th key you still do 1 hash. If you change that, in order to get the 100^th key you have to do 100 hashes.


I suppose there are two easy ways of implementing this:
1. Giving the user the option to set an integer as the "starting point" of his key derivation and start getting keys from that int and discard everything (keys and tx history) before that. You could always get them back by lowering that int and you can always discard more by increasing it.

2. Going to another "branch". That could also help with "hiding the history" that you are looking for. For instance the starting point of the wallet could be m/1'/0'/0' and after reaching 100 keys the user switches to another path: m/1'/0'/1' so the first 100 keys would be at m/1'/0'/0'/0, m/1'/0'/0'/1,... branch and the second 100 would be at m/1'/0'/1'/0, m/1'/0'/1'/1, ... branch. This way you still use the same seed and start from 0 each time but have a hidden history that could only be accessed if the correct derivation path was given, the range of which is from 0 to 2³²-1 so hiding the "branches" is easy too.

Are you sure you are looking at correct values?
Here is an example transaction link on block explorer

The raw bytes of this transaction is:
You can use this online tool to compute SHA256 of hexadecimal input: https://cryptii.com/pipes/hash-function click on the drop down dots and select duplicate to compute it twice. It should look like this: https://i.imgur.com/LWXpRIA.jpg
As you can see the result is going to be:
Now if you look at that link from block explorer you can see that the txid is:
that is the hash result in reverse.

edit: Of course I forgot about SegWit, if the transaction has any witness, it has to be stripped off before hashing it as @achow101 pointed out.

"Hash" is the result that you get from the hash function (double SHA256) and transaction ID is the hexadecimal representation of the that but in bitcoin we reverse it first and then encode it using base-16. So they are not exactly the same although they both represent the same value.
For example if your hash is { 1, 2, 3 } your txid is going to be 0x030201 (3 bytes is chosen for brevity otherwise length is 32 bytes).

I still have to check Monero "under the hood" but I think the similarities are more than you think.

That is also what I was thinking. Is there any coin in particular that you think is more interesting than others? Also do you have any links to their documentation?

Considering the code and implementation of the blockchain technology, which altcoin do you think has the most differences compared to bitcoin? Please explain these differences and include a link to the "documentation" of the coin if possible. I'll try to research the coin and reply back with my findings.

Things I don't exactly consider as differences: Using different hash function, mining algorithm, asymmetric cryptography (different curve, different signature scheme), and obviously: different supply, block time, block size,...

It doesn't matter when you are verifying a signed message (eg. proof of ownership), that would be a 1 time call to recover function. So that function being slow doesn't affect anything.
But when you are verifying transaction signatures, most of the times you are doing it hundreds of thousands of times (eg. a new block that contains 2000-3000 transactions or syncing your node and downloading ~600k blocks). In this case the slowness of that function is very important. And it is indeed quite slow:
2x square root (which a ModPow for secp256k1 curve with 256 bit numbers)
6x check point on curve
4x modular multiplicative inverse
6x point multiplication
2x point addition

In comparison the signature verification is:
1x modular multiplicative inverse
2x point multiplication
1x point addition
2x simple integer multiplication

I'm trying to figure out how numbers are interpreted inside scripts. Could someone check if the following test cases are correct?
"bytes" is only the data part, I'm skipping the size part which would be 0x01, 0x02 and 0x03 for 1, 2 and 3 byte data respectively.

This is not related to bitcoin protocol, this is a standard scheme used in Elliptic Curve Cryptography. Since the private/public key pairs used in bitcoin are EC key pairs, ECIES scheme could be used with them.

All the current SegWit scripts are created using only the compressed public key, if you use the uncompressed one your funds will be lost.

Usually when randomness is involved in an algorithm, the first step is random not the subsequent ones, and there is a relationship between these steps. There is also a chance of failure in such algorithms which means you have to go back to first step and choose another random first step. Example: Pollard's kangaroo algorithm, you "hop" around based on the first random entry point.
I am not familiar with how Vanitygen works but most probably the only reason for choosing a random key for its starting point is because the final result must be random and if it starts from anything not-random, the result could be reproduced and that makes the whole thing useless. Besides, that code is looking for collision in a very small space which is not more than a couple of bytes depending on the number of characters you chose so you have many possible results. But here we are looking for a single needle in a haystack.

What you said, could work if and only if there were some rules for going from key1 (the random key) to key2 apart from iteration (+=1) which means the only way of implementing something like this is to randomize the entry point and do the same thing from there. Anything other than that (eg. choosing a random combination each step) has the potential of increasing the chance of not finding the result ever since you'd be shooting in the dark.

Hint: the trick in optimization of something like this is going through all cases but not-repeating things you have already done. A simple loop over 656 mil+ would have taken about 20 minutes.

Recently I started working on a new project called The FinderOuter¹ and whenever I implement an algorithm, I go around comparing it with others to see how others have tackled it compared to my approach. Unfortunately in this case I could only find 2 solution (1 & 2) and both are simple loops, not exactly the best approach.

So if you know of any code that could recover something like the following, please post it here:
Example is from bitcoin wiki

Alternatively if you have done this in the past and have any benchmark (the time it took to find the correct key) please post your time here for comparison.

Sneak peek of what I'm building in pure c# (1.25 million/sec is with core i3 CPU):



1. Name is inspired by the TV show called Futurama

Generally the speed is about the Digital Signature Algorithm (DSA) not the curve itself. This means in case of Curve25519, Edwards variant of DSA (or EDDSA) is used which is fast and makes the whole thing faster. Similarly using a curve like Secp256k1 with EC-DSA (what bitcoin has been using so far) is slower than using it with ECS-DSA (Schnorr algorithm).
Although I believe in case of these curves (Edwards curves) the form of the curve is contributing to the speed ups.


Public key recovery is not something that we really need to perform. All transactions include the public key so there is no need to recover it. The only time such functions are called is for message signature verification, and such operation is only performed once so it doesn't matter if it takes 1 milisecond or 10!
Also remember that public key recovery is not possible on EDDSA in first place, I only mentioned it above as a hypothetical example for ECDSA case with h>1.

Note that the formula is longer than that, you are missing the first steps for calculating x¹. For secp256k1 curve (and all the Koblitz curves over F_p defined by SEC-2) since the cofactor of the curve (or h) is equal to 1, you may only recover up to 4 possible public keys from the ECDSA signature. But cofactor of other curves may not be the same. For instance curve25519 cofactor is 8 and if you were doing ECDSA on this curve² then the number of possible recovered public keys would have been 16.

¹. Refer to page 47 of Standards for Efficient Cryptography 1, section 4.1.6 Public Key Recovery Operation https://www.secg.org/sec1-v2.pdf
². Technically you could implement ECDSA algorithm on edwards curve but it is not going to be the standard defined by ANSI X9.62

Address is a concept created to make things user friendly so addresses represent the most common and straight forward scripts. As long as you don't go out of your way to create a script that is not common or you don't understand, there is no problem with spending coins as long as you have the private key.

Things like that are not considered high priority and as a developer you are sometimes busy with other things that may be more important, so sometimes certain requests go at the bottom of your TODO list.

P2PKH and P2SH aren't keys, they are script types, and Hash160 is a hash function or rather combination of two (SHA256 and RIPEMD160).

In bitcoin when you send coins to someone else, you are lock those coins up by creating a "condition" that only when you fulfill requirements of that condition you could "unlock" or "spend" those coins. Some of these "common" conditions have special names.
For example P2PKH is one of the most common public scripts. The condition says that the owner must first provide a public key that when hashed using HASH160 function would produce a digest equal to the 20 bytes that is included inside the script and the signature alongside the public key provided would be a valid ECDSA signature for the provided transactions.

We have so many different types because we have so many different needs.
You might want to pay to one public key so you use P2PKH, you may want to add a specific time to the condition where coins could not be spent before that deadline is reached in which case you use CheckLockTimeVerify script type, you may want to create a complicated condition (such as paying multiple public keys aka multisig) and only reveal the hash of it so you use P2SH (of course P2SH isn't limited to multisig), and so on.
There is also new features such as Segregated Witness which defines new public script types. P2WPKH or P2WSH and some more are among them.

More on scripts: https://en.bitcoin.it/wiki/Script