Reindex. start with the -reindex option.

I wasn't talking about separate blockchains or sidechains, etc. I am talking about literally a separate data structure tacked onto the block that allows any sort of transaction to go inside of it. That would break backwards compatibility, and it is the naive implementation of such a size increase. There of course has to be plenty of other things to be done in order to maintain compatibility, and for just a block size increase, is too complex and still a bad idea. It would be easier to do just a hard fork to increase the block size at that point.

In theory a soft fork could be made where there is a so called "extra block" which would contain additional transactions. It's a horrible idea because it isn't actually backwards compatible since old nodes may not know that a transaction has confirmed if it were in the "extra block"

It looks like it received a bad message and just crashed. These crashes are usually hard to reproduce and thus we can't really debug them to fix.

It is extremely unlikely that Core will lower the thresholds. They are specifically using the BIP9 soft fork standard and that specifies a 95% threshold for all soft forks, not just segwit. If anyone were to propose a lower threshold, I believe that many of the developers working on Core would fight against instituting such a change even though we all want segwit to be deployed. I myself would fight against any such change even though I want to see segwit deployed.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1643020.0

Duplicate.

You have to wait for the transactions to confirm. It has nothing to do with your wallet.

Nowhere. Affiliate links (also known as referral links) are not allowed to be in a post anywhere on this forum. You can however have them in your signature.

Potential (pretty much is) spam attack underway: http://statoshi.info/dashboard/db/transactions

Even so there are still protections against that. Bitcoin Core uses a distributed and deterministic release process (known as gitian building). Multiple people build the Bitcoin binaries and the hashes of all the binaries must match. Then the release is made and those hashes are signed with Wladimir's PGP key which only he has (in theory). The code signing keys for windows and mac are controlled only by Cory Fields (IIRC). Anything a malicious entity does would result in hashes that don't match what was released and what the gitian builders published when they did the gitian builds.

If it can't find the DB it will spawn the DB by itself unless the socket it is occupied by something.

What error do you get?

It's called a sybil attack and they are entirely possible. A miner's node could be theoretically connected to only malicious nodes which could withhold all the new transactions and only relay blocks. It would be more effective to just cut them off the network though.

There isn't really an issue. The issue is that miners SPV mine, and that can be really bad for the blockchain as it can lead to forks.

Theoretically possible, but not likely.

There are no such things as "fake transactions". If a transaction is invalid it will be rejected. If someone attempts to DoS a node with invalid txs, then they will be banned by that node.

Empty blocks (blocks with one transaction, the coinbase transaction) usually occur due to SPV mining where the miners have not validated the previous block before building the next block on it. This means they don't know what transactions were included in that block so they do not include any transactions in the next block until they have validated the previous block.

The other blocks with few transactions may happen if the entire mempool of the miner's node was cleared by the last block and they have only received a few transactions when they began building the next block. This may be unlikely, but not impossible.

There may be another reason, but it all depends on the algorithm used to select the transactions. Blocks being at less than the maximum is not really strange, they happen all the time.

One thing to note is that if all blocks were full (as many claim is true but is actually not), then a significant amount of the "backlog" would actually be cleared.

Addresses do not expire. Addresses are not linked to a transaction. The site simply means that they will no longer actively watch for a payment to that address so they will not mark your order as paid. You will have to contact their support in order to fix that issue. Bitcoin transactions are not reversible so if your transaction confirms, you will not be refunded. You must ask them to either refund you or proceed with the order.

Your transaction has not confirmed because the fee is too low. You paid a fee of 7390 satoshis (~32 satoshis per byte). A fee that will allow your transaction to confirm within one block would be 20160 satoshis (90 satoshis / byte) according to http://bitcoinfees.21.co/.

This transaction depends upon your first unconfirmed transaction. It cannot confirm until the first one does.

The fee is too low on this one.

With Electrum, you can set it to use dynamic fees (it figures out the best for you) by going to Tools > Preferences and checking the Dynamic Fees checkbox. To get the fastest transactions, move the fee multiplier slider to the right so that the fee you pay is higher thus your transaction confirms faster.

Can you post a screenshot?

Armory doesn't actually do anything with Tor since it is a local connection to a local bitcoind. The bitcoind is what actually uses Tor. The bitcoind will use Tor for all of its traffic.

Can you stop spamming with all of these threads? Just make a thread for questions about the code breakdown. Also, I highly suggest that you read the Documentation at https://dev.visucore.com/bitcoin/doxygen/ and you logically think through what you are asking before asking the question.

I don't need to even read the code to understand this line, just logically thinking.

This line adds the chainwork of the previous block to the chainwork of the current block. It uses the ternary operator to start at 0 if the previous block doesn't exist, i.e. the genesis block. Otherwise it will get the chainwork of the previous block.

Go to /Users/James/Library/Application Support/Armory/ and post a screenshot of all of the files inside that folder. I have a hunch that Armory picked up an encrypted backup (you said your friend made encrypted backups?) from that folder because the original from the folder got corrupted.

no