There is a current limit on the number of sigops (signature operations) to prevent a miner from creating a block that takes ages to verify due to an extreme number of sigops. Sigops currently include the OP_CHECKSIG and OP_CHECKMULTISIG as well as a few others. The current limit is 20000 sigops per block which is 1000000 (1 MB)/50. Thus the maximum number of block sigops will increase according to the formula of blocksize/50. It will become 40000 for a 2MB maximum.

As for why it is written like that, probably because the code is like that to allow for any blocksize but still preserve the ratio between blocksize in bytes and number of sigops.

That looks to be correct. I think blockchain is just assuming mainnet since both addresses have the same hash160.

You can create a script which goes through each block and uses the getblockhash and getblock rpc commands. You can retrieve the json data for each block which includes a field for the nonce. Then just extract the nonce and save that to a file.

bought some more codes from him

Node count is easily manipulated, so it is not a good metric of support (as we can see here). For support they are looking for 750 of the last 1000 blocks mined that contain a different version number which indicates that that block supports Bitcoin XT

BIP 101 blocks have a different version number that means that that block and miner supports XT. Those blocks are still valid since the fork has not yet happened.

Full Nodes a clients on the Bitcoin Network that verify all blocks and transactions. XT happens to be a full node but is modified so that it follows different rules. Blocks mined through XT will have a different version number and it will cause a hard fork of the blockchain when 750 of the last 1000 blocks use its version number.

Get a faster processor.

I think I might implement both.

The official reason is the prevent SPV clients from spamming old nodes that don't support bloom filters with their bloom filter requests.

As for having the option to disable bloom filters, I couldn't tell ya.

None for the SPV client. For the full node that supplies the client data, it reduces the amount of data it uses and prevents DoS attacks. Otherwise disabling bloom filters is pretty much pointless and not beneficial except for people running nodes on low end hardware and low bandwidth networks.

It can be both a problem and a benefit. Instead of wasting resources trying to get a node to respond to a service request it doesn't support, the SPV client can go look for nodes that actually respond to its request. On the other hand, if people disable bloom filters, you pretty much leave those SPV clients in the dark or using the old method which takes a lot of data.

Nope. No idea what you are talking about

There are other issues than just the blocksize limit. If every time some large issue prevented anything else from happening, than Bitcoin would stagnate and nothing would get done. Same thing with other software. You can't have everyone working on one issue and not doing anything else. It prevents any progress from happening.

There is a thing called multi tasking, which is what they are doing. They are working on multiple things at a time to be more efficient and get more done. While some people debate the block size issue, other people work on other stuff. Some people work on implementations of their proposals for the block size, and others do stuff to improve other aspects. This is what makes groups of people great. You can have a few guys on one thing, a few more on another, and so on.

If you actually read the developer mailing list, then you would see that they not only discuss blocksize stuff, but also other stuff. In fact, a large chunk of the discussions on the mailing list are not about the block size.

It is NOT blacklisting all SPV clients. It is implementing an extra bit which indicates whether the node supports bloom filters or not. They are also adding an option in Bitcoin Core to disable bloom filters should the operator wish to do so. It has bloom filters enabled by default.

Before deleting anything, find the wallet.dat file and copy that out to some other folder where it is safe. Then delete everything and fire up Bitcoin Core. If that doesn't work, then try uninstalling and reinstalling Bitcoin Core. If the program works, then go back to appdata and replace the new wallet.dat file in there with the one that you copied out.

XT is controlled by Hearn and Gavin and them only. Core is controlled by the core devs, which includes a lot more than two people, so I would say that Core is more decentralized than XT right?

Talking about Bitcoin itself though, then yes it is not controlled by anyone and the multiple forks of Bitcoin (including xt) and alternative clients all demonstrate that.

I included it because of the standard request for the post quality of an account since that can affect the price of the account. I needed a metric so I just used what my sig campaign used as a metric for acceptable posts (probably wasn't a good idea). However, I feel that a price estimator without including the post quality of an account would not be complete.

I will remove that if enough people want me to. So far, I have not seen anyone really mention their dislike with that feature (besides you) so I will leave it as is.

I would advise you read the discussion on that pr thread and read the actual bip here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010535.html

If you actually read any of those, it should be clear that this is simply giving operators the option of disabling bloom filters and thus disabling connections to spv wallets. It is just like the choice to choose Core or XT. Additionally, it is not only a change to Core, but a change to the protocol. It prevents SPV wallets from constantly sending requests to a node that does not support bloom filters (e.g. old nodes) thereby conserving resources ON BOTH ENDS so that they can be put to actual use instead of wasted.

Furthermore, Core is not by default disabling this feature. It is only giving node operators the option to turn it off, and for people who just start Bitcoin Core and leave it running (like me) then it doesn't matter.

I'm inclined to believe that they support XT and BIP101 simply because it is the only production code available that implements big blocks, which they all support. If someone creates different code that also implements big blocks (such as BIP 100) then we would have both more choice and that these companies would not stick to XT.

I realize that, but then how would you determine the post quality? Or just remove it from the results entirely? I based the post quality off of what my sig campaign accepted for decent quality posts which is at least 75 symbols in length.

So I have analyzed the potential activity issue and a manual count shows that my website is correct. I don't know why Bitcointalk says the activity is higher than what I calculated though.

It is OK and not stuck. Armory can take a long time to load. Just keep it open and after a while (can take several hours) if will load and be usable. The more often you use it, the less time the startup should take.