Version 0.12.0 released
Added the P2P option which allows user to directly connect to bitcoin nodes and broadcast their transaction on both MainNet and TestNet.
This uses the new MinimalClient introduced in Bitcoin.Net 0.17.0.0 which is in beta and may contain bugs.
https://github.com/Coding-Enthusiast/SharpPusher/releases/tag/0.12.0.0

Sorry for a late reply, it's been challenging to find free time lately and I'm working on 5 projects in parallel which is an additional challenge. Thanks everyone for your feedback, I've released the second beta, v0.2.0.0 with the following changes:

• Added a new input type with keyboard which captures keys pressed and treats all keys as 1 except 0, space and escape keys which are treated as 0.
• There are 2 buttons that let you fill all bits with either 0 or 1.
• The result or checksum are not longer dynamically computed. You have to click Finalize button to calculate checksum and get the final result.
• Each view is now cached so even if the options are changed, the bits that are already set will not change

While implementing this I experienced some bugs while capturing mouse event so this option will be postponed for next release.

Yes, that would make the starting point. Although brute forcing it may take a long time itself since it is 10 missing characters so you may need to find the closest thing by manually modifying the characters.

Because the byte you discarded wasn't 0x80.
When you are treating the Base-58 string as an integer ignoring the checksum, etc. you have to be careful not to hit an edge case such as the one in that other topic.

When you are decoding Kw111... you end up with {0x79, 0x76, ...} bytes which is obviously an invalid permutation because of invalid version byte. So you have to increment until you get to 0x80 first and use that as your starting point. Meaning: Kw1111111112 -> Kw1111111113 -> Kw1111111114 -> ... Kw111111111z -> Kw1111111121 -> Kw1111111122 ...
If you don't do that, your "big" value using z's (Kwzzz...) would be {0x80, 0x4c, ...} and since an integer starting with 0x76 is bigger than an integer starting with 0x4c you end up with a bigger start than the end.

Unfortunately I haven't been able to add GPU support to FinderOuter yet.

Keep in mind that this method is significantly slower than to simply test each character permutation.
You see each character at the start of the string (from left) converts to a much bigger integer than any character from the end of the string. So even the difference between 1 char missing becomes huge.
Take the following example:
Ky**DfuvLpt8eSb8EQzhZwDCQeCaycKeAoxJMY8pfPZXmn3uB38R
Even though only 2 characters are missing the difference between Ky11Df... and KyzzDf... as integer is
While the permutations are only 3364.

It is not producing the entropy, the user produces each bit by random (like by flipping a coin) and the program converts the bit-stream to whatever they need.

That is how it is supposed to work. You flip your coin and if it came up heads you click the button once to set it to 1, if it came up tails you click it twice to set it to 0.

You mean something like what bitaddress.org does? I guess I could add a canvas and track mouse movement then combine it with a strong random entropy generated programmatically.

Well, generating entropy by hand is slow. 128 to 256 bits is 128 to 256 coin flips. However I will add an option to use 6-16 sides die to reduce the effort.

You can also check out my project called FinderOuter: https://bitcointalk.org/index.php?topic=5214021.0

Handy Dandy is a tool that helps visualize and work with data in different formats that are used in Bitcoin protocol such as private keys and mnemonics.

A potential use case is offline generation of private keys or mnemonics using a coin flip.
User selects what result they want to generate (eg. a 15-word BIP-39 mnemonic) by selecting the appropriate options on top of the window and the program automatically generates appropriate number of bits to be set. In this example it is 165 bits (160 bit entropy + 5 bit dynamically computed checksum).
Then the user has to flip a coin and set each bit. For example
Heads: 1
Tails: 0
Heads: 1
Heads: 1


As each bit is being set, the respective value is also printed as integer, hexadecimal and BIP-39 word.
After all bits were set the final result will be printed in the result TextBox at the bottom of the page and can be copied.



Source code and compiled binaries can be found here: https://github.com/Coding-Enthusiast/HandyDandy
This project is in beta. Please report any bugs you find here or on GitHub

If You found this tool helpful consider making a donation:
Legacy address: 1Q9swRQuwhTtjZZ2yguFWk7m7pszknkWyk
SegWit address: bc1q3n5t9gv40ayq68nwf0yth49dt5c799wpld376s

The idea for project was influenced by: https://bitcointalk.org/index.php?topic=5187401.0

Wallet file encryption is a bit complicated and I haven't been able to find a good documentation I could use to implement it. So although it is in my todo list I'm not sure when I can actually implement it specially nowadays that I'm very busy, sadly.

It doesn't matter but if you hold your mouse over the textbox you will see a popup showing what characters are accepted. This character will only be used to indicate the missing position and nothing else.

Unfortunately no.

The problem could be in existing characters but as far as the start goes the uncompressed keys start with 5H, 5J or 5K but the rest can be anything.

I haven't seen a Java/Kotlic implementation but apart from the C implementation there is JavaScript and my own C# implementations that are similar languages.

The process is:
"Expand HRP" by converting its N base-256 (8-bit) representation to 2N+1 base-32 (5-bit).
For example bc which is 0x6263 or 0b01100010_01100011 becomes 0x0303000203
In this process for each octet the highest 3 bits are placed in first half of the result and the remaining (low) 5 bits in second half. In the example above:
b=0x62=0b01100010 -> 0x0303000203 and
c=0x63=0b01100011 -> 0x0303000203
The two halves are separated with a zero (the value at the middle is always 0) -> 0x0303000203

Now we can compute checksum of [expanded HRP] | [base32 data] | [6x zeros] (note that "|" is concatenation).
The process is best explained by code

The actual checksum used in encoding is the result of "polymod" XORed with a constant. This constant is 0x01 for Bech32 (BIP-173) encoding just flipping the least significant bit and is 0x2bc830a3 for Bech32m (BIP-350) encoding. The former is used for witness version 0 addresses and the later for 1+. This is basically the only difference that was introduced in BIP-350.

There are two parts to this question, if you want to know how scripts are evaluated then you have to check the code found in interpreter.cpp. Or you look at my code in Script.cs but unlike the c++ code here the evaluation and execution are performed separately.

If you want to know how this is considered P2WPKH, I have to say it is like a contract. We agreed that any script that is between 4 and 42 bytes long and starts with a number OP (like OP_0, OP_5, OP_16, etc.) and is immediately followed by one and only 1 data push is a witness script and that number OP indicates the witness version. For version 0 the data being pushed to the stack (witness program) must either be 20 bytes (ie. P2WPKH) or 32 bytes (ie. P2WSH) and everything else is invalid and rejected.

You can't because this address is defining a "locking mechanism" that can only be "unlocked" by providing a valid signature as its witness the way I explained above. This can not be changed since the public key script aka the lock aka the P2WPKH wrapped in P2SH address is already defined and the balance of it are protected by that "lock".

No, your signature script is actually fine. The problem is the missing witness items, there needs to be 2 items a public key and an ECDSA signature.

The size is not important, what the script is "translated" into is. I'll explain below.

It is but only on first step.

Basically this is what happens:
1. We take the pubkey script from the UTXO (the inputs of the transaction we are evaluating)
2. Evaluate what type this pubkey script has
2.A. If it is not any special types then move to signature script, run that then run pubkey script then move to last step to see if tx is valid (top stack element has to be true)
2.B. If it is a witness script (OP_NUM <singlepush>) then the signature script must be empty and there must be a witness corresponding to this input, continue evaluation based on that (compare the hash, evaluate witnesses, etc).
2.C. If it is P2SH then the signature script must be all data pushes and at least 1 is needed (the last one is interpreted as redeem script). Some initial checks are done (running signature script then pubkey script) Then we start evaluating that redeem script:
2.C.A. If it is not any special type then just execute the script and move to last step
2.C.B. If it is a special type (ie. witness scripts) then continue evaluation based on that type.

In case of your transaction we take the pubkey script
and see that the type is P2SH so we take a look at the signature script
It is a single push. So far everything is OK. Signature script is executed then top stack element is stored somewhere before pubkey script is executed. Stack is checked to see if it is true (essentially checking to see if the HASH160 was correct as you asked above).
Finally that stack element that was stored is evaluated as a script called redeem script.
Evaluating this shows that the type is P2WPKH so the evaluation continues by looking for 2 witness items and fails here because your transaction doesn't have any.

Your assumption is wrong here. It doesn't matter that the output that is being spent was P2SH and looks like legacy, what matters is that what the "S" (script that got hashed) was and since your redeem script was a witness script then the transaction must contain the required witness on top of the program pushed as a redeem script in signature script.

I apologize for the the inconvenience but that project is old and obsolete (I will update its readme for clarification, although it is mentioned in issues).
Try my newer project that fully supports Segregated Witness.
This is where the magic happens: https://github.com/Autarkysoft/Denovo/blob/master/Src/Denovo/ViewModels/VerifyTxViewModel.cs
If you fill the boxes with correct values and set the block height (top right corner) to the imaginary block that would contain this tx (affects consensus rules) you get the following:


That is not the same.
If you look at the redeem script (last and only push in signature script) you realize that the type of it is a simple 1of1 legacy multi-sig whereas your redeem script is a P2WPKH one.

This project is old and kind of obsolete, so I never got around to fixing its bugs and adding the missing parts. However migration of this project is one of those items in my very long to-do list. I recently finished the transaction verification part but haven't started working on the "script playground" part. The migration fixes the bugs and will cover every script that exists in Bitcoin protocol and the software can run on any operating system.
Here is an issue to track this #2.

Do you have the corresponding public key (it starts with G and is 56 chars long)?

Your comment woke some old ideas in me, how about converting the key to human readable words? It is easier to write down, typos occur but are less common and easier to detect, it also has a checksum.
An example can be seen below, the private key's binary form is encoded using the same BIP39 scheme which can be converted back to a WIF using the same scheme in reverse.

I made a new option for it in Denovo, the first two options are for this conversion and the second two are dealing with versioned WIFs (BIP178 and what Electrum briefly used).

The following method contains all the subsequent methods that are called in order to create a private key from an integer of at most bitLen bits, convert to public key and finally get the corresponding address. You can find all those methods in Bitcoin.Net and see what they do.
It goes without saying that a key created this way is a weak key.

Yes. I just haven't decided if I want to dynamically compute it on each click or add a "finalize" button that user has to click which computes the checksum in the end.

Thanks for the suggestion. This is what the new buttons would look like:

I'm also thinking about adding the "math" for each value so that it can be manually verified in an easy way.
That is to show how for example 0b01011001 is equal to 89. Something like 0b01011001=1*2⁰ + 0*2¹ + 0*2² + 1*2³ ...