Bitcoin is decentralized.

If US researches want money they can spend, they would withdraw their BTC to USD. While GBP may be worth more than USD, converting from BTC to USD will still give them the same amount of value as BTC to GBP. Besides, they would want to spend USD in the US since US stores don't accept GBP.

He is saying that they are top notch researchers and computer scientists who would probably find the problem first and fix it before others figure it out. Since the people who would be researching that probably depend on Bitcoin and wish to see its success, they probably wouldn't exploit those vulnerabilities since doing so could completely crash and destroy Bitcoin. Also, they would be millions of DOLLARS not pounds since those institutions are in the US.

All transactions have fees. You need transaction fees in order to get a miner to include your transaction in a block. Every client should be setting fees by default, not just bitcoin core.

From a technical aspect, it is difficult to prevent Gavin from using the alert key. There is only one alert key, and the private key for that is distributed among a multitude of people. Since it is hard coded, changing the alert key in a future version means that the new key would only work for that version, and the old key for the older versions. This means that Gavin would be able to still send alerts to old versions if chose to do so. The other option would be to cause the alert mechanism to display the static "Alert Key Compromised" message but that would also create a lot of panic.

At this time, I don't think people are discussing the alert key and the political ramifications because of both the difficulty to change the key and the fact that there is no immediate need to do so. There is no indication that Gavin would even attempt to use the alert key and that there are ways to remove an alert put out by Gavin (or anyone else with the key). Furthermore, Gavin is still actively contributing to Bitcoin Core. He works on other fixes and is active on the development mailing list as well as the github.

The alert key for the entire bitcoin network is the same, so that includes XT.

Confirmed to have the alert key: Gavin Andresen, Theymos, Satoshi Nakamoto, Gregory Maxwell
Not confirmed but probably have the key: Wladimir J. van der Laan, Jeff Garzik, Pieter Wuille

Also, please note that there will not be a definitive list of everyone who has the alert key for their own personal safety as well as to prevent attempts to coerce key holders.

You get 14 potential activity every 14 days.

There is a problem with the website queue and I will be rebooting the server which will fix the problem. This problem should be fixed in my next version which involves overhauling the queue system and adds a token and email system for access to results. This will take a while though since it is a major code rewrite.

BIP 100 doesn't even have a client implementing it, so even if they reach the threshold, it won't do anything. The threshold is also 90% (not the 75% used by BIP 101) and requires 12000 blocks which is 3 months worth of blocks.

Now that you fixed that, is that all that needed to be done? Or are there other problems that need to be fixed before you can pay the bounty?

Auction is now over. I am contacting the highest bidder.

Minimum increment is 0.01.
Buyer can choose escrow. Can be anyone in trusted escrow list. Buyer will pay all fees.

How would you know whether a transaction has an output in the previous block if you don't know what transactions were in that block? Additionally how would you know whether an unconfirmed transaction which uses an older output was not confirmed in the last block?

So one thing that people have pointed out in other threads that also mention this proposal is that a someone can spam transactions which fill blocks and forces the block limit up. Miners can also lower the block limit to an infinitely small amount. I think you should also add in upper and lower bounds on what the block size limit can be. Perhaps 1 MB and 32 MB to prevent this kind of thing from happening.

Open an issue on github and post your stuff about armory in the proper sub forum which is Development and Technical Discussion > Alternative Clients > Armory.

You can always set the data directory manually by yourself.

Bitcoin has always had the consensus changes done by the miners. Technically, nodes, exchanges and merchants have no direct control over the consensus. It has always been and will always be the miners who make the consensus changes because the consensus changes are in the blocks, which are made by miners. Exchanges, merchants, and users have indirect control by giving miners incentives to mine for one consensus change versus another because if miners end up on a fork that no one else uses, they lose money.

Those spam transactions can delay low fee transactions for a long time.

Where were you a month ago when someone was spamming transactions? Don't give me BS about a "stress test" it was most definitely a spam attack. It caused 80000 unconfirmed txs, many of them legitimate.

While that is possible, you need to see it the way that miners see it and do some cost-benefit analysis.

Preventing transactions could cause several negative outcomes for miners. They would be losing out on transaction fees if a fee market doesn't develop. If the blocksize goes too low or fees go too high, people might just stop using Bitcoin causing the price to drop and thus miners are losing money. An increased backlog of transactions can negatively impact the full node by filling its mempool to the point that the node just crashes.

The only positive that could come out of causing small blocksizes would be the possibility of a fee market, which compared to the risks, is not something they would attempt with their already small profit margins

Also, if you think that miners would do this, then why are so many of them voting for 8 MB blocks?

A solution to this problem you present would be to create a lower bound on the blocksize limit. It would be that the maximum blocksize cannot go any lower than say 1 MB (or any other number you like).

Try going to store/SPVBlockStore.java and changing the constant DEFAULT_NUM_HEADERS to a lower number. I think that might help.

I am currently working on that as well as an email system so it will also email you (if you want to be emailed) with your results.

Other changes I am adding are a database that I can go in separately to change instead of using a static lists which may not be reliable.

I do understand and that is what it is currently supposed to do. Whether it actually does or doesn't is a different story. It worked in my tests so it should work in production, but may not always be the case.