I've been banning those with high violation scores and I'm finding more interesting behavior.
There are a bunch of UAs (therealbitcoin.org) with some broken message payloads that violate enough to be banned.
There is 46.101.246.115 or "snoopy" that just gets my version payload and runs away.

And there are these bitnodes.io IPs that echo any block height you give them. Interesting part is that they are incoming transactions (ie. connecting to my listening socket) so they are sending me version message first. I've counted 7 and 5 remain connected with no timeouts. I'm not sure if we can categorize this under Sybil attack.

You should squash your 151 commits into 1.

Sometimes PR on BIPs repo go unnoticed for very long times. Last commit to word-lists was merged by luke-jr, try mentioning their username under your PR.

There are two possibilities that come to mind, they are either running multiple implementation and monitoring their behavior and the bitcoin network through each of those. Or some of them may be trying to both test and avoid user-agent banning (that is where your node disconnects the node that has a certain U.A. right away).

I'm currently postponing looking at source code, thanks for the link though.

Past couple of days have been very interesting, ever since I opened my listening socket to test my code I've been somewhat flooded with many inbound connections some of which seem to be only gathering information and nothing else (what I like to call "hit and run" nodes), a rare malicious node and only a handful of real nodes that behaved normally.

The malicious node was a node that I ended up playing "ping-pong" with until I manually cut it off, which was interesting as it kept sending me ping messages which I obviously replied with a pong to no end!

Another case which doesn't seem malicious but it is not normal either is a fixed IP range that has about 6 different user agents (satoshi:0.15 satpshi:0.18,... bitcoinj and nodesmulti). They only send a getaddr message and disconnect right away just to repeat it again later.
These "hit and run" nodes seem to only care about gathering information and nothing else and there are many of them.

This makes me wonder what are the cases that bitcoin core bans other nodes for "misbehaving" apart from obvious ones such as invalid block/tx/pow/chain?
If you also have any other information regarding P2P network I would love to study it.

Version 0.5.0 released (The Parallelization Update)

This is the parallelism update with tons of optimization from a small 10% speed gain to more than 1800% in some cases.  
- Most of these optimizations are in Base58 recovery option.  
  - Compressed and uncompressed private key recovery uses all available CPU cores for maximum speed and at 100% capacity.
  - Two special cases were added to recover private keys that are missing characters from their end (up to 9 missing for uncompressed and 11 for compressed is the default for now and can be recovered in less than a minute).  
  - Recovery of Base58 addresses and BIP-38 encrypted keys are also optimized the same way.
- Mini private key recovery
  - It uses all available CPU cores
  - It suffers from the known issue #9
  - The extra input has more options like other recovery options to enter different types of addresses or a public key.
- Mnemonic recovery
  - New wordlist added (Czech)
  - There is a simple checkbox now to set the key index itself to be hardened
  - It suffers from the known issue #9 whenever there is EC multiplication involved (private key to public key), otherwise if there weren't any the code will run at maximum efficiency using all cores at 100% (see 5th example in mnemonic recovery)

Other most notable changes:
- Now there is a progress bar at the bottom that will be used when recovering in parallel to show the progress so far. Other times when using single core the recovery process never takes up longer than a minute (usually less than 10 seconds) so progress bar is disabled.  
- Addition of more examples for each recovery option.  
- Various code improvements and bug fixes.

Sometimes the implementations want the option to perform a binary search on their word list which is only possible if the array they are working with (the string[2048] here) is sorted.
This is also suggested in BIP-39 `Wordlist > c) sorted wordlists`

I think you should try to avoid it if possible. It's definitely beneficial to keep all the words as distinct as possible. For example in the case above simply a bad handwriting could cause issues between letter 'c' and 't' in "cable" and "table" and having multiple one of these mistakes in a mnemonic could potentially make recovery impossible.

• The Levenshtein algorithm considers 3 factors: deletion, insertion and substitution
• Damerau–Levenshtein adds transposition to the above 3.
• Meanwhile the Jaro algorithm only considers similarity (characters in common but only in a short distance)
• Jaro-Winkler is the same as Jaro but gives a more favorable result when the characters in common are from the beginning of the string (ie. AAAXYZ and AAAUVW are more similar than XZYAAA and UVWAAA).

I believe the results could pretty much give the same conclusion about the word lists BIP-39 is dealing with. But I think Levenshtein may be better here. For example Jaro-Winkler gives 0.866 for "cable" and "table" (closer to 1 means less similar) while Levenshtein returns 1 which is a much better indication of it being bad.

PS. You can run Jaro-Winkler algorithm here on sharplab just change the s1 and s2 in Main() method.

I just added the code to compute Levenshtein distance for all existing BIP-39 lists to Bitcoin.Net and the first thing I noticed is that the English list contains words such as "able", "cable", "table", "unable", "viable" with very short distances (1 for the first three and 2 for the other two).
Other languages don't seem to be any better. Here are only some of the example words not all:
Italian first word in the list is "abaco" which has a similar one "baco" or "sino", "asino".
French seems better but it has words with distance=2 like "apaiser", "abaisser"
Spanish has "bono", "abono" and "abrazo", "brazo"
Czech has words with distance=2 like "abeceda", "beseda" and "adresa", "agrese"
Japanese has "あいさつ", "かいさつ" and "あきる", "あける"
Korean has "가격", "간격"
Chinese results don't make much sense but since the last 3 are complicated languages I'm not sure if the Levenshtein distance is even valid for them.

Good point, although when I'm talking about bloom filters I have general meaning in mind (the space-efficient probabilistic data structure used to tell if an element is present in a set in a rapid and memory-efficient way)  rather than the BIP-37.

It's hard to say mainly since a bitcoin wallet is security sensitive since it deals with users funds.
I think the easiest way is to decide the type of client you want to create then start going through the source code of similar projects and check their different parts to get the idea. Then start your own work.
You could check out bitcoin.org to get a list of wallets categorized based on their type and features they offer with all their links.
But I like to categorize them this way:

1. A full node.
This would be something like Armory for instance where you build your wallet which could be additional functionality and more advanced UI on top of bitcoin core. A lot of the basic functionalities are already accessible though core's JSON RPC including signing transactions, handling keys, scripts,...
This would probably be easiest to create (less work and knowledge of protocol required) but has only niche usages since it is a full node.
Armory (link found on bitcoin.org).
Bitcoin core. There are lots of good information including RPC commands on [https://developer.bitcoin.org/index.html]developers documentation[/url]

2. SPV client
This requires more knowledge of Bitcoin protocol and the amount of code to write will be a lot more compared to #1 because you'll have to handle everything from key generation and transaction signing to a communication protocol that the wallet has to use.
You'll also have to be familiar with the attack vectors against SPV clients since they do less verification compared to a full node.
I categorize them into two sub groups:
2.A. SPV using bloom filters
This is a bit more decentralized and provides better privacy compared to the other type but it takes more effort and bad implementation of it could lead to privacy leaks.
BitcoinJ library (written in Java) and some of the SPV wallets that use it are using this method.
2.B. SPV using Electrum protocol
This provides less privacy but it is probably easier to work with and is slightly faster. Basically the client connects to an Electrum node that has an indexed blockchain and looks up its history and also opens a socket listening for new incoming blocks or transactions for the addresses it subscribes to.
Electrum (written in Python) is the implementation.


PS. Platform could also be a determining factor, for instance you'll have more restrictions working on a phone compared to PC.

Since I just added this "optimization" to FinderOuter I though I should give an update on this post regarding the 7 characters and the checksum (I can't believe it's been 2 years!).

The key posted in OP (5KMWmYkn5YWkJnUDG4utD9L1HXQv3DBseqqCGsQXmthcEerbA7k) is missing more than just its checksum. In fact there are 515 valid WIFs with the same starting 44 characters. I did a little modification to the code and printed all of them. Interestingly enough the valid key is found on line 122.
https://gist.github.com/Coding-Enthusiast/8339f64c736053107f0d918675c186e0

I ran a lot of tests with different keys before releasing this code and I came up with these numbers representing the number of possible valid keys with the same initial characters in case the missing ones are from the end. In case of compressed keys checksum could be up to 6 chars and only 5 for uncompressed ones.
Here is a non-permanent link to the code (https://github.com/Coding-Enthusiast/FinderOuter/blob/master/Src/FinderOuter/Services/Base58Sevice.cs#L130-L139) which may be updated in the future if I find any new information.

---

While I'm here, is there any wallet or tool (apart from bitaddress.org) that has ever used Base64 encoding for private keys?
Since looking at OP, FinderOuter already has an option to recover everything listed there (Base58 WIFs, Base16, mini keys, BIP38, even addresses and finally mnemonics) but the only things missing right now are Base64, BIP38 password brute force and wallet file recovery which I have plans for implementing the last two after releasing 0.5.0 with all the optimizations but not Base64 and don't know if I should add that to the list or not.

---

PS. your list is missing Version Extended Wallet Import Formats (WIFs) outlined in BIP-178 and has a briefly used alternative different implementation by Electrum.
It is basically the same looking WIFs that when decoded have used either a suffix or prefix (depending on the implementation) to "extend" the key with extra bits to indicate the corresponding pubkey script type derived from that key. Such keys can't be imported in wallets without converting them first.
I also have an implementation of it in Bitcoin.Net with a bunch of test vectors (first 3 WIFs are BIP-178 and the remaining 5 are Electrum specific) which also supports the Electrum script type format (scripttype:wif).

FinderOuter is currently very inefficient for recovering this particular case because it will go through all possible keys which are 2,207,984,167,552 for 7 missing characters which on my PC would take 16 days with version 0.4.1.0 (latest stable release) and about 2 days if you compile using master at latest commit.
Meanwhile I can manually count only 514 valid keys for the example posted in OP with the same starting 44 characters in a second. But I haven't released this code yet because I don't have the mathematical proof for it yet so am not sure about its correctness.

To OP, if you are not in a rush you should wait for version 0.5.0.0 to be released which will include lots of optimization including special cases like this.

Update: This feature was added in c629804 for uncompressed keys and in 81df9b2 for compressed keys.

BIP-85 seems more suitable here.
User can deterministically generate the starting key (step 1 outlined here) at a predefined standard path (m/83696968'/app_no'/index') and finds the vanity address that way.
This avoids any overhead of having any extra steps while adds the possibility of recovering the key from the seed backup by taking the same (time consuming) steps.

Using hardened children it's a single HMACSHA512 and a single modular addition (HMAC can also be optimized to only perform 2 block compressions instead of 4). But yeah it makes no sense to use this method.

You also can't just come up with any domain parameters you like, your G coordinates are not in the interval [0, p−1] (read page 17 of SEC 1: Elliptic Curve Cryptography). In other words your point is not even on curve and multiplication is not even defined, consequently the numbers you posted as pub/private key are random numbers. It is like claiming you have found an integer for x for x²=-1.

You get this error message when the message magic (the starting 4 bytes) are not as expected.
https://github.com/bitcoin/bitcoin/blob/b4d0366b47dd9b8fe29cc9a100dcdf6ca1d3cabf/src/net_processing.cpp#L3861-L3862

You can find all the "chain parameters" in chainparams.cpp file. The magic is called pchMessageStart and is found on lines 286-289

I'm curious about this too. I believe you have to use each node on a different port if they are on the same machine (eg. one on 18444 another on 18445).

Witness is not something separate to be stored separately, it is a part of each transaction like the transaction's version, locktime, outpoint and so on. Each witness of each transaction is stored inside that transaction as a new field right after the last txout and right before the locktime.

That is a mistake, the is NOT block structure. That looks like a half cut off P2P Block message.
The message starts with a magic (byte[] { 0xf9, 0xbe, 0xb4, 0xd9 }), then message name/type (block\0\0\0\0\0\0\0), message data length, checksum, message data.
in this case the "message data" part is a block which has the following structure:
block header, number of transactions, array of transactions

I though Ping message was to check the connection when some time was passed and to check the connection is still alive. But I'm receiving it right at the beginning. The sequence of messages that I receive is this (without delay):
(send Version)
Version Verack
(send Verack)
SendHeaders
SendCmpct (2 times one for each version!)
Ping
Addr
GetHeaders