What makes you think that it is the programming languages that makes Bitcoin unable to scale?

In what way does it not work?

Can you please post the debug.log file.

The blockchain is a data structure, not something that people access over a network. The Great Firewall can block nodes from connecting to each other over the internet but that does not prevent nodes from accessing their own local blockchains. They are blocking access to other nodes, not to the blockchain.

How so? AFAIK TOR is fairly reliable and can easily get around the Great Firewall. Bitcoin Core (and anything based off of it) has support for connecting over TOR and even allowing incoming connections over TOR with automatic hidden service creation.

I don't think the Great Firewall can kill all VPNs. New ones will constantly be made.

They can get the blockchain data and send and receive transactions through non-internet related methods. They could use the blockstream satellite protocol with just normal radio stations on the ground and use that to broadcast out of China. Data could be transmitted over websites and other non-Bitcoin protocol things. The problem is not about China blocking the Bitcoin network; there are always ways around that block even though they will have higher latency. The problem is China banning Bitcoin mining as that will essentially shut down all mining operations in China which consists of a majority of mining on the Bitcoin network.

Blockstream satellite is currently only one way. You can only receive blocks from it. They are working on expanding it so that more of the world is covered and more stations are set up. What could happen is that an uplink station in China is set up and the Chinese miners can send their blocks to that station to be broadcast to the rest of the world. And maybe you could then send transactions to that station to also be broadcast to the rest of the world.

Hashes are not encryption; they cannot be decrypted or reversed. If they could, then the hash function would be broken.

Each of the 4 byte numbers are 32-bit unsigned integers, so they cannot be negative. The addition of these are done modulo 2^32 so the numbers you sum will need to be some multiple of 2^32 in order for E to be 0x00000000.

The Bitcoin Core developers want users to update at their own pace whenever they feel comfortable updating. This is because new versions may contain consensus changes that users may not agree with, possible security considerations that users are not comfortable with, etc. By using an alert system to inform people about new versions, we would be pressuring users to update and we do not want to do that as that violates the principle of letting users upgrade whenever they feel comfortable with the changes.

But that is only one business out of many businesses, even if they are large. Just because a few businesses, a few users, and a few miners support 2x does not mean that it has consensus and is going to happen.

The general principle of how Bitcoin Core operates with updates is that users can and should update at their own pace. The developers should never pressure users to update to a new version of the software. By using such an alert system to inform people of new software versions, we would be pressuring people to update more so than not informing them at all through the client.

No, the alert system is for security events and network breaking events like unintentional hard forks. Intentional planned hard forks should also not be announced via the alert system as that would be pressuring users to upgrade to a new version which we want to avoid.

Because it is not a priority.

No. An alert system should only ever be used to inform users of security problems or forking events. It should never be used to inform users of updates, software improvements, new versions, etc. that are not related to the security of a user's coins. Any sort of intentional fork should never be announced over any alert system.

Open up the registry editor (type regedit.exe in the start menu and run the program) and go to Computer\HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt. Then click File > Export and export those registry keys to a file and post the contents of that file here. Those registry keys correspond to the GUI settings for Bitcoin Core. Then start Bitcoin Core with the -resetguisettings command line option (add it to the target for your shortcut) or add that option to your bitcoin.conf temporarily. This will clear any and all GUI settings that you have, and because it will, I need to see what you had previously to help debug this problem which is why you need to export them first with regedit (I think I know what the problem is, I just want to be sure).

That may be jonasschnelli doing some implementation and testing work for it, but AFAIK there are no pull requests to implement BIP 151 in Bitcoin Core yet.

No, that is incorrect. Segwit requires a soft fork to activate, and in fact, has already activated. What you are thinking of is the Lightning Network or sidechains.

Segwit2x is a (improperly named) proposal to make an additional hard fork to a maximum of 8 million block weight (double that of segwit's 4 million block weight). It currently has very little user and business support and supposedly a majority of miner support. However it is not clear how much of the miner support actually supports segwit2x now and will support it in the future if the vast majority of users and businesses don't support segwit2x.

I am mistaken. Looking through my watchlist with "edit watchlist", I see that none of those threads were actually added to my watchlist. However I certainly saw all of those threads in my watchlist earlier which amounted to ~13 pages of unread messages that I have since cleared with "Mark all as read".

No, that's exactly what you asked, to convert uncompressed pubkey to compressed one. Just look at the last digit of the y value (last 32 bytes of pubkey) and see if that is an even or odd digit. If it is even, the prefix byte is 0x02. If it is odd, the prefix byte is 0x03.

It refers to the position on the y-axis. Specifically 0x02 is used to indicate that the y value is even and 0x03 is used to indicate that it is odd.

Yes, you can. In fact all compressed public keys are actually computed from the uncompressed public key as the uncompressed public key is the one that is actually derived.

What kind of software are you looking for?

I don't understand why you are so fixated on choosing your own private key that is memorable. Why not instead generate random private keys until you generate something that you find memorable. That is far more secure than you choosing something memorable.

It can be stolen the moment you decide to spend the coins and have to enter you private key into some software. Even if you are keeping the coins in long term storage, at some point in the future you will want to move those coins out of storage to do something with them. Whenever you do that, you expose your private key and it can be stolen.

Similarly, the same argument can be made for randomly generating a private key and keeping it on a storage medium that never touches the internet.

There is also still a significant privacy loss even if you are only using that address for receiving. For starters, everyone that sends you money will know how much money you have. Furthermore you are reducing the privacy of everyone that transacts with you because anyone will be able to look at their transactions and immediately know who they were paying and how much.

addwitnessaddress was primarily a shim to facilitate testing of segwit. It was not really meant to be widely used by users for segwit.

Segwit addresses beginning with a '3' are actually P2SH addresses. This means that the address itself is mapped to a script (after all, it is Pay-to-script-hash), not to a private key. From there the parts of the script itself are mapped to a private key. However dumpprivkey does not go that deep, it only takes things that are mapped directly to a private key, which are P2PKH addresses and public keys. Segwit addresses are not mapped to a private key because they are really just P2SH addresses. So using dumpprivkey with segwit addresses will return an error (as will using any other P2SH address).

To get the private key of the address, you need to take the address that you used addwitnessaddress on originally and call dumpprivkey on that address.

The page number and location that you find memorable, even if a "huge" string of numbers, is probably something that many other people would find memorable. Regardless of what number you choose, it will not be as secure as randomly generating a private key. What you are doing is similar to brain wallets which are notoriously insecure. Except your method is less secure as it does not include any key stretching or additional things to possible add randomness (e.g. hashing) that brain wallets do.

There's nothing stopping you from randomly generating a private key and then figuring out its location on directory.io. Or randomly generating the page number and randomly generating the key index on directory.io so that you can memorize them for your key. That would be more secure than you choosing the location manually. You can even keep generating random numbers until you find one that is memorable to you. That is much more secure than you choosing your own private key.

Furthermore you are still vulnerable to many attacks (even the same ones that you thought you weren't vulnerable to) with your scheme.

First of all, you are essentially sending your private key to a remote web server (directory.io). The owner of that website can see that your browser would be visiting the same page over and over again. It would not be hard for them to just search through the private keys on that page and see which ones have coins and then steal them. In fact, any man in the middle could do this. The site doesn't even use https so anyone sniffing traffic on your internet connection (e.g. shared wifi) would be able to see exactly what page you are on and then just scan those private keys.

Secondly, you still need to load that private key into a wallet software in order to spend from it. You will probably have the private key on your clipboard, and the private key will be held in insecure places and in insecure memory. With a proper wallet software that generated your private key, the private key will remain in that software's memory (unless you export it). Your private key would then be able to be stolen by keyloggers and clipboard loggers which constitutes far more viruses than coin stealing viruses as coin stealing viruses much find specific files to steal your coins. This means that your key is much more vulnerable to viruses on your computer. Additionally you would still be vulnerable to traditional coin stealing viruses because most wallet software will write imported keys to a wallet file so normal coin stealing viruses can go steal those wallet files.

Thirdly, because the private key is in an unencrypted form, if the private key is stolen, then the thief can spend your coins immediately. With wallet encryption, if your coins are stolen, you still have time to move them as strong encryption and a strong password will protect your private keys.

Lastly, you would be reusing the exact same address over and over again which will lead to significant privacy loss. There's a reason that nearly all wallet software gives you a new address every time you want to receive coins and every time it makes a change output.

What is the code that you are using to generate an address?

Yes, it will.

I don't remember the actual behavior. I don't think it will upgrade the database.