This probably happens because you have about 16000 addresses, and listunspent and getbalance need to scan for all of the unspent outputs and calculate the balance of all 16000 addresses. This is why it takes a few seconds. getinfo on the otherhand, does not need to scan through all of your addresses, and already has the data that it needs for the output.

The difficulty retarget is when the difficulty of the network is changed every 2016 blocks so that there is a 10 minute interval between each block. This retarget should occur roughly every 2 weeks, which is the timespan for the retarget.

yes.

It could be, but the keypairs are very small, and several thousand addresses would only take up a couple Mb tops. With current technology, and the current growth, this will never become a problem.

A new keypair is not generated for each send. Bitcoin core sends your funds from one or more of the addresses you own, and the remainder from the address goes to a newly generated address as the change. It will try to involve as few inputs as possible in order to create your transaction.

Bob can send his bitcoin to a mixer. The mixer service allows Bob to send multiple payments, one from each of his addresses, to them and then he can withdraw his bitcoin from the service when all of his Bitcoin has been sent there. The withdrawal takes Bitcoin from addresses that he did not send to and sends that to another newly generated address owned by Bob, thus anonymizing his Bitcoin. Alice will only know that the Bitcoin she sent Bob went to another address, but she will have lost her trail on Bob. Carol will only know that he funded his address from other addresses, but tracing those, she will be tracing Bob's payments.

If Bob does not use a mixer, then Carol can see the addresses she is being paid from, and Alice can see where the Bitcoin is being sent. If Bob also sends from many of his addresses, then both Carol and Alice will know what addresses Bob has.

Try running bitcoind and bitcoin-cli from the source directory where you compiled it. Running bitcoind will not show you anything, the cursor will only blink. Running bitcoin-cli will give you some output.

The latency of the internet and Tor and the time it takes to establish a connection makes changing ip addresses quickly enough to broadcast that many transactions per second impossible. The attacker would not be able to connect to another proxy and the bitcoin network, and still be able to send several million transactions per second. He's would need to broadcast then all almost at the same time or several million per IP. Thus, the network would still block him.

That already is a hard cap on block size... at 1Mb.

The blockchain only stores transactions that are confirmed, e.g. in a block. All unconfirmed tensions remain in the mempool, and if not broadcasted repeatedly, will be removed and forgotten within a day or two. Again, since 1 satoshi transactions are low priority miners are less inclined to fill blocks with them. Miners can also choose to not include any of the attacker's txs. Thus the attacker needs to continually broadcast all of his transactions to get them in a block, and the continual spamming of millions of dust transactions will get him blocked.

The other solution would be to keep the block size limit less than 1Gb. Even if the attacker tried to flood the network, the miners would drop their dust transaction unless they paid an exorbitant transaction fee. Furthermore, someone would notice 100 billion dust txs from the same address and inform the miners, who could just drop those txs from that address. The only way the attacker could succeed would be if they had 50% of the hashing power, in which case the network is already in trouble.

My numbers do not account for these, but they typically occur off chain. These transactions typically happen within the exchanges own system. The numbers I use come from https://www.frbservices.org/files/communications/pdf/research/2013_payments_study_summary.pdf. These numbers include all credit card, debit card, ACH, checks, and prepaid cards from 2012.

Someone doing that would be banned almost immediately. Their node would receive a banscore from its peers, and would thus be disconnected and blocked from the entire network for at least 24 hours. Miners would might also drop his transactions. Dust transactions have a lower priority, and it is likely that the miners would not include the transactions sent by the attacker into their blocks.

Can AWS codes be transferred? I thought they were locked to a specific account?

All of the BIPs, a description, the author(s), type, and status are listed on this page: https://github.com/bitcoin/bips. Some also have the proposals and an in depth explanation of them.

BIP stands for Bitcoin Improvement Proposal

Well, banks in their early days surely did run away with money. However, over time, people learn who to trust, and for big banks, it is more profitable and less troublesome for them to abide by the rules. Also, government regulation definitely prevents these types of scams from happening with fiat, but it is more difficult to regulate Bitcoin.

Another thing, it is much more difficult to run away with several million dollars of physical cash, and much easier to run away with several million dollars of Bitcoin, since Bitcoin is digital, and cash is physical. Face to face transactions of banks also makes it more difficult for the scammer to hide, than it is for a digital bank for Bitcoin.

While there is a problem with scalability in Bitcoin, the number of transactions required to create blocks that exceed the network speed is astronomically large. I ran some numbers to show this:

The USA handled 122.8 Billion non-cash transactions in 2012. I rounded this up to 150 Billion transactions.
In transactions per second: 4756 tx/s in 2013. Round up to 5000 tx/s
In transactions per block: 3000000
Thus, using the average transaction size of 0.2 Kilobytes, the block size would be 600000 Kb = 600 Mb.

Now, this is just the USA, with some inflated numbers, so the numbers worldwide are definitely higher, but not be too much.

Even with larger than 1 Gb blocks, the worldwide average network speed is 23.3 Mb/s, so I rounded down to 20 Mb/s.
The largest block size which could cause the scenario you outlined would be 12 Gb. Which could most definitely support all the worldwide non-cash transactions.

Of course, these numbers are averages, they could be higher, they could be lower. The internet speed depends on the location, the number of transactions depends on the time and place.

While the number transactions could pose a problem for block size and internet speeds, due to the astronomically large number of transactions to cause a problem, the core developers are not focusing on that yet. They will probably get around to addressing that issue, but they have other issues such as the size of the blockchain. This issue is currently being thought about and developers are attempting to resolve it. They will move onto other pressing issues first before coming to fixing the issue with download speeds.

If you have a solution to this issue you present, by all means, share it. Propose a BIP and submit it to the community and the core devs. It will eventually become implemented, and you will have just fixed a potentially big problem with Bitcoin for the future.

There wouldn't be any DOS attacks from spamming the network. Once one transaction is created to consolidate the UTXO's and that transaction was considered valid, any other transaction spending the same inputs to consolidate would be invalidated and treated as a double spend. These would then be removed from the network. Also, any node spamming the network with these transactions within a very short amount of time would receive a banscore from its peers and thus be disconnected from the network for some amount of time.

There is no bullet proof way because anyone can send two transactions with the same inputs without anything stopping them.  The chances of being attacked depends on the person you are dealing with, and generally, accepting 0 confirmations with large transactions have a high risk of a double spend. If there is a double spend, either the seller sees that a double spend happened and doesn't send the goods, or the buyer gets the goods and keeps his money. The seller can protect himself by waiting for a couple confirmations to ensure that another transaction to double spend cannot be accepted by the network.

It kind of depends on your definition of a bank. If you want a place to store BTC in a third party, then a web wallet could be a bank. On the other hand, if you think of a bank in the traditional sense, then I don't think there are any. There is no way for the bank to make money for interest. These things could also be scams.

I'd like to join.

Name:  achow101
Post count:  113
Rank:  member
Bitcoin address:  1At6EhbjN8BLCJz4pVAjsFcNzhzxQmXrwZ

I can do this. How much will you pay, and will you use an escrow?

Personally I use Netbeans for development. I have imported Bitcoin core into it before. The process was simply to create a c++ project, choose the option for c++ project from existing source, point Netbeans to the git cloned folder, and hit finish. It was very quick and easy, there was no need to import each file individually and manually.

So you are saying that bitnodes abuses the network since it takes up a connection slot on all nodes.

What I fail to understand is how my node abuses the network, because even though it takes up a connection slot, it still has the full blockchain and can relay blocks and transactions. It is a full node

How does this abuse the network? Since it is a full node, wouldn't it help the network because it can provide data to all of the nodes that it connects to?

Actually, that might be the answer to number 1. I have not increased the limits, and Ubuntu has a soft limit of 1024 files per user, and Bitcoin usually aborts around 1000 nodes connected. It aborts because it cannot open the database, which might be because the limit prevents it from opening another file. I will increase the limit and see what happens.