Topic: Concerns - IRC DDOS Attacks, Wallet Limits (Read 1830 times)

After making some code changes on a single thread on a CPU I was able to generate these stats after 12 hours:
 wallet                 9793ms
Rescanning last 131051 blocks (from block 0)...
 rescan                24540ms
Done loading
mapBlockIndex.size() = 131055
nBestHeight = 131051
mapKeys.size() = 399643
mapPubKeys.size() = 399643
mapWallet.size() = 0
mapAddressBook.size() = 399538

So about 33294.833333333 public/private key pairs per hour on a shitty processor. I also did mispeak I now realize that I'm not generating "wallets" but rather just a hash that contains public/private key pairs. This is probably not the most efficient way to perform such an attack, having a pool of computers generating the public/private keypairs would be a much better method. However, I have determined that the current system is safe enough for me I hope that someone with more time to dedicate to this is not successful. I will still trust in a bank external to the bitcoin system with the vast majority of my money because there is a remote chance out of "luck" someone may generate my public/private key pair, reconstruct the transactions in their wallet and drain all of my cash. I will be testing again with some GPUs once my hardware comes in, sorry about the RPC flood, lol. I guess at least the network is resilient enough to not even notice.

Exactly. But in more detail: If you generate a wallet you are basically generating a (bunch of) key pair(s): a public one (basically this is the receive address) and a private one (which can send BTC that were received by its corresponding public key earlier). No one notices when you do this on your computer.
So, you can generate lots of addresses, but you can't do anything with them (do transactions that clog the network, so someone does notice): unless you have some huge amount of BTC lying around you can send send them some fractional bitcoin. *
If someone else generates an address that is already generated in your astronomical pool, he can just use it. (And you can drain his funds, but this is astronomically difficult, as some else said before)**

* = spamming attack
** = generating lots of addresses: Collision attack
See https://en.bitcoin.it/wiki/Weaknesses, it has lots of information and of course it explains it more elaborately than I do

Yep, exactly.

There's only 2^140 possible addresses! Get cracking!

2^140 = 1393796574908163946345982392040522594123776

So what your telling me is I really do need to write code to generate all possible wallets and I can spend bitcoins out of everyone's wallet?

There're records. But there's no de-duplication. If 2 people generate the same address, they can both spend coins sent there.

So your telling me other peers have no clue about what address is assigned where and there are absolutely no records to prevent duplication?

You are still worried because you didn't understand that Bitcoin is not fully dependent on IRC.  And because you don't know that there haven't been any PGP keys collisions yet.

But if you are really that worried, you can use multiple addresses, to reduce such an unlikely risk. ^_^

Wallet addresses are NOT ALLOCATED.

I think you guys are missing the point. I'm not worried about my coins. I'm worried about the future of the bitcoin if someone were to launch that attack on the bitcoin network. If all wallet addresses were allocated, what measures are in place to reclaim empty/unused wallets?

Ah. It's perfectly legal to generate an existing wallet again.
Yes, someone could generate your wallet and take your coins. It's unlikely.
Unlikely: all the air in the room happens to congregate at the other end; you die of asphyxia.

I do not plan to do it, I'm throwing it out there as a what if. If all of the addresses have been generated is there a function that will reclaim empty wallets? The only people interested in this are like the two senators that want to see it shutdown.

I don't know about BitcoinJ, but in the original Bitcoin client, you can add nodes manually.  See the wiki for nodes.

There are 2^160 possible addresses, so your investment in wallet mining to find a collision would be astronomical. You would not get any benefit from it --besides the big news-- as the only wallet who would be able to spend that address's balance is the one who has the private key.

Hi all,  I would first like to welcome everyone looking at this to my first thread on the forum! 

My first concern is that of peer discovery, I know by briefly looking through the code for the BitcoinJ client that it seems the general way to discover peers is by connecting to an IRC server and looking for peers in the channel list. IRC servers are vulnerable to DDoS it would be quite easy for the U.S. Government, or anyone with a botnet to launch an attack on the IRC server. I'm not sure if it is true for the official bitcoin client but the BitcoinJ client only specifies one IRC server. Is there a plan to setup a mirror service like we seen with WikiLeaks but for IRC? I guess as along as one node could be found you could potentially receive the list of peers by that node. My concern is for clients that have not discovered any nodes yet. I also seen a DNS resolution file but it was not implented yet. I know in the official client there are some IP addresses that are commented out and I suppose people could look on a site for at least one node to connect to, so maybe I answered my own question.

Second, what if someone mined Wallets instead of bitcoins? What I mean by this is that if someone created a client that continuously created send and receive wallets how long would it take before all of the addresses are used up? How would you prevent this?