If you are talking about the characters you can use for the password, then your can use whatever characters you want as long as it is part of UTF-8, which most characters are.

If only the exchanges changed to use XT (or whatever other client that implements a fork), then they would be losing business because few other users are also using XT so they don't make any money. If the users and exchanges were switched to XT and pushing for a for, then the miners would follow because that is where the money is. If miners and exchanges switch but users don't, then those miners and exchanges are incentivised to switch back because there is no money to be made if no one else is using that fork. In all of those cases, it is not possible for one group to coerce everyone else to switch, there has to be two out of three to do so otherwise there is no incentive for the other groups to switch.

Also, in your example, with such a fork, there is nothing that distinguishes a Core transaction from an XT transaction, so those XT holders who are sending core coins to that exchange are also sending their XT coins to that exchange. What you described is simply not possible.

We already know that a fork without consensus is suicidal, it is suicidal for both sides. That is why we always wait for the supermajority before enforcing any sort of fork, hard or soft.

Run the same command you are running with zapwallettxes but instead of having zapwallettxes there, change it to -rescan.

Why do you say I am delighted? Stop putting words in my mouth. I see that there is centralization, there inherently is. There absolutely is no way to have complete and absolute decentralization. But it isn't on the scale or level which you claim it is.

Yes they would have been heard. The thousands of miners who mine at those 3 pools who are against XT (or any other proposed fork) switch to other pools who does not support the fork. Those 3 pools no longer have a majority.

The thousands of users (including the miners) who don't support the fork stop using those 4 exchanges and use other less popular but just as good exchanges.

The thousands of users who use those 5 developer's client switch to another client.

With all of the options out there, people aren't being forced to use anything, and if they don't like it, then they don't have to use those products or services which use rules they don't like. This is consensus.

No. The signatures in a transaction applies only to that transaction due to hashes. The hash can only represent on specific set of data, that one specific transaction. If the data is different, then that hash will not match and thus the signature is invalid for that data. Unless the attacker is able to find a hash collision which also happens to be a proper transaction, then signatures cannot be reused. IIRC the current hash used is SHA256 which has no known attacks against it.

How does this have properties of a soft fork? It is missing the key point of a soft fork, old clients are still able to use Bitcoin after the fork. This is a hard fork since I cannot run current software after this fork and still be able to send and receive transactions and use it as I do now.

There is already a strong incentive to upgrade with a normal soft fork. Miner's blocks will be orphaned if they don't upgrade.

And such forks have happened before, see the July 4th forking incident: https://bitcoin.org/en/alert/2015-07-04-spv-mining

I think this is different. What you propose is simultaneously mine on two different blockchains, the old and new one. This is a 51% attack on the old chain as it just produces a bunch of empty blocks thus preventing confirmations. In a normal soft fork, this doesn't happen and other miners can extend that old chain, they just don't have any incentive to do so. Again, see the July 4th forking incident for an example of miners extending the old chain. Your proposal wouldn't allow that to happen, but old clients would only be able to use the old chain, so it is a hard fork.

If Danny understood it, then I invite him to explain it to me since he is much better at explaining than you are.

I think the wallet needs to be unlocked in order to generate new keys, so the keypool size will probably increase the next time you unlock the wallet.

I think the wallet marks all of the keys in the keypool before an encryption as used so it regenerates the keypool after encrypting which is how 5000 became 10000

No it cannot. Clients running the old rules are not able to use Bitcoin as they have normally. They are unable to use Bitcoin at all because they cannot see the transaction data in the blockchain and thus won't know about confirmations. This proposal is not backwards compatible, and backwards compatibility is the key point of a soft fork.

They could, but that is also why we wait for a supermajority of miners say that they are willing to enforce the new rules before actually enforcing.

No it does not. A soft fork simply lets the old chain die out if people are still mining there. They aren't actively attacking the old chain as your proposal suggests. A normal soft fork would still allow miners to mine on and extend the old chain. This causes problems, see the July 4th forking incident for an example of this.

So it really would just be discouraging any use of the old chain and force people to switch to the new one.

The way I understood it was that it is supposed to be that people on the old chain can still use Bitcoin normally. As I said in an earlier post, this is not possible unless somehow all of the UTXOs in the new block are presented in the old block format. But I think in order to do that, a software upgrade is still needed so that the client actually knows what to do with that data because it cannot be in the same format that is currently used. Either way, I don't think the idea that this is a soft fork works, it is still a hard fork.

Hard forks don't need consensus, we just want consensus to actually do one. It only requires the same amount of hashpower to execute. The difference between soft forks and hard forks is not the hashpower required, it is whether the new rules are backwards compatible (soft fork) or not (hard fork)

Nothing about your proposal makes it backwards compatible (a soft fork). It is not possible to still use Bitcoin if you are running an old version of software, as is the case with hard forks. The point of a soft fork is that I don't need to upgrade but I can still send transactions, see confirmations, see other transactions, and consider other transactions and blocks as still valid even if they run under the new rules. Your proposal makes it so that I can't see confirmations (so I can't spend the Bitcoin because the transaction will remain in the mempool and then disappear when no one continues to relay it after it has been confirmed), and it won't consider new blocks containing actual block data as valid since they are too big. It is still a hard fork.

Your Bitcoin is safe as long as you have that wallet file.

It should be rescanning the blockchain now to see how much Bitcoin you have. You might have to restart Bitcoin Core with the rescan option.

How did you set the keypool? The increase to 10000 might have been caused by the way that you had set the keypool size.

Did you get a new address 17 times? It looks like Bitcoin Core is trying to keep 10000 address in the keypool, so if you request a new address, it will generate another and add it to the keypool. This will happen even if you don't have any transactions.

I see a few problems with those proposal

1) You are proposing to fork the blockchain without consensus. This in itself is a problem, we don't want to fork without consensus (even with a soft fork) because there is still the possibility of the old chain surviving, and that can lead to some major problems.

2) Your generalized soft fork idea breaks one of the basic principles of Bitcoin, storing all of the transaction history in the blockchain. It is not possible to know what the transaction data is if you use your idea to transform blocks under new rules to blocks under old rules. It isn't backwards compatible so it isn't a soft fork. If I ran a client with the old rules, then I would not be able to know what the transactions were in that block without having to download the fork. That is completely pointless.

Linux and Windows are constantly being developed, otherwise we would still be using MS-DOS. Look at the linux kernel git: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/. There are commits happening very frequently, and some even happened today. Windows is also constantly developed. They release windows updates every tuesday of each month. They release Service Packs and new Windows versions. Are you calling that "not constantly developed"? More people rely on Windows and linux every day than do people who use Bitcoin. They have more at stake, and they still constantly develop.

Yes. There are a few BIPs proposing a dynamic block size but they have not been implemented yet. To change to use a dynamic block size (or to change anything with block size in general) would require a hard fork.

It probably is possible. As for why it isn't implemented, it is just another altcoin feature, and altcoin features are rarely implemented back into Bitcoin. Also, it looks like zerocash doesn't have any production ready code yet so there isn't even anything to implement and test out yet.

Please don't. You are just going to bloat the blockchain. The general idea to putting stuff in the blockchain is to use special transactions with weird outputs so that when you decode it in a certain way you get the data.

This is off topic, but to answer your question, it is due to the recent release of new ASIC hardware. More efficient ASIC mining hardware has made mining a little cheaper so more people are mining. They also have higher hashrates so people are replacing their equipment and getting more hash power. If you are insinuating that there is some conspiracy to increase the hash power and do something malicious, you are wrong.

That is what it is supposed to display. That is simply what the api returns. If you keep refreshing the page, you will see that the numbers change.

Who are "They"?

Are you saying that you don't actively participate in the economy (by buying and selling stuff) so that means that you can care about centralization but those who participate don't? That is flawed logic. I participate in the economy, and I care about this. Other people also participate, and they clearly care about centralization and where Bitcoin is going. And it does also affect their profits. If Bitcoin goes in a direction that is bad for Bitcoin, then they are going to lose profits. So yes, they will care if it goes in a direction that makes them lose profits.

According to the commit that marks it as withdrawn: