It takes a loooong time to get up to that many connections (days) because it depends on how many other peers the other clients are looking for an open connection for.

There is one behavior that I've noticed.

Block sync stalling.

When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block. The problem is, if you stop and restart the client, it just picks up where it left off on the same stuck block. The only way I've seen to fix this is to delete the block chain so that the client will re-download it.

I've had to clear out a few block chains for a few servers because of this, I'll notice they are stuck on block 70,000 for example, while the rest of the network is working on block 70,839 for example.

That might explain why you go weeks without winning a block with a 24/7 PC going.

The server farm I had running before were spitting out blocks all day, but now that I'm just down to a few dozen servers and the difficulty is way up, I barely see about 3 or 4 blocks a day spread across all of them. But I know the 0.3.8 version is working like it should, except for the occasional block freeze.

I haven't had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.

You would then have to rely on "for profit" companies to be the central authority for the new currency and how long would it take to generate the full chain even at a difficulty of 1.00?

Maybe we need a big technical chart that documents every single step about how BitCoin works and the next time someone starts a topic about why everything in bitcoin is done wrong, we can point to that chart and say "here's how it works, document how your new process will work in detail and we will compare"  

I think that would help to cut down on a lot of assumptions/disputes I see in topics every-time the issue of "this isn't being done right" comes up in this forum.

Just saying....  

I think it's already set by default not to "generate coins" when it's first installed

How would the connect default work?

LOL 

Ah I understand then, the answer is botnets can't forge currency because the swarm would not accept it. The only thing they can do is produce "real" currency at the expense of the stolen CPU time. Just like forcing slaves to mine gold will still net you real gold, just at no cost.

The only known *practical* attack to bitcoin from a botnet would be to have more CPU than the swarm at your command and to use that CPU power to double-speed currency. So while that could possible fall in into the "forged currency" category, it's not so much to make fake currency as it is spending valid currency twice before anyone notices.

Trust no one node, but if enough nodes are saying the same thing, then trust that. 

A botnet is a stolen computer already, the concern people have is that it will take over bitcoin in some way. What you are talking about is what we already know. They use the stolen CPU time to generate BTC and then sell it on the market. It's stolen CPU time, we have no control of that. What we do have control over is how much damage it can do to others that are running honest clients.
The system was designed with that in mind. That's why it uses a formula that forces anyone that participates in the protocol to behave or else they are ignored. So if anyone is going to game the system, they have to do it by the rules that everyone else is following. Right now, the only rule to game is CPU time. It's either expensive, donated, or stolen.

That's the problem with having one PC generate all the coin, that one PC is a central authority of it and can price it anyway he/she likes. To de-centralize it means you need some way to force everyone to play by the rules or else one person will try to bend the rules.

I respect that you don't agree with how it works, so I offer up that we be shown a better way that we can't all punch holes in. It's open source software, if there is a better way, it can be used. Currently the rules are why they are because the entire network is designed with "trust no one" but instead "trust everyone collectively".

Ah ok, you track by new receive address, I understand now. I forgot you can generate an address on the fly like that with a label. Yes, I certainly want control from a website perspective rather than a client only.

So one could generate label "customer_123" for address "<well you know, it's really long>" and which a payment comes in to that one address only for the right amount. It won't matter what send address the customer does/doesn't generate. It must be late, I should have seen that before  

That's good to know because it can help integrate with the market sites to do currency conversion so one doesn't have to adjust the BTC prices every day to cope with the market up/down swings.

Sent 10BTC for the help. 

Well *snap*, that's what it was. Sometimes I get my virtual machines mixed up, thanks! Sending 10BTC to you!

For reference in case anyone else encounters this

Put up a bounty for the faucet thief......hmm.... 

I think that's the issue you have though, you think it's inefficient and resource intensive on purpose when really it's not. No one is required to generate coins to use the system. If you click the generate coin list, you are basically volunteering your resources to strengthen the network and in exchange, you *might* get some coin for it. Since coin is in demand to use the system, someone has to generate it. If generation was as easy as "input how many you want, *bam*, you have 1 million now" it would make the entire system pointless. It's a chicken and the egg puzzle except there really isn't a puzzle here. People need bitcoins, they generate them at a fixed rate to make it worth spending the CPU time.
There's no reason to think of it that way, anymore than the local barber is collecting hair to clone an army of super-men for world domination. You have to draw the line somewhere. If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense.

I have seen the topic come up here a few times "what if someone seeks to exploit this?" and the answer is the same over and over, it has been designed from the ground up to counter this exact concern. If you want to "game" the system, you need a lot of CPU power. CPU power cost money. The system scales itself to the available CPU power it has so if you bought 10,000 EC2 sessions from Amazon and started a massive bitcoin generating farm, you would never make more money out of it than what you put into it for long because the system would self-adjust against it. If someone throughs a massive botnet at it, the same thing will happen. The system is set for self-feedback, so to try to steal from everyone is to try to steal from yourself at the same time.

I finally got around to compiling the 0.3.8 source tonight, but noticed it errors out wxWidgets when it didn't before. I did notice on the wxWidgets website that they have a new 2.9.1 release. Are the new versions of Bitcoin being written against the new 2.9.1 wxWidgets release?

This the error I was getting in case anyone was curious

Per the example, how would that process work with what you suggested? How are you going to predict what address they send payment to you as?

I just checked the block averages, since the bump up in difficulty the average has actually be lowered to about the 6/hour target now (where as before it seem to be 10/hour and the difficulty was always climbing)

Seeing how the new client is a lot faster now, seems the difficulty finally caught up with the CPU power out there. I wonder if the difficulty will go again in the next week or so. 

From and Comment fields

Right now, if you transfer from one address to another, well that's about all the info you get, client ABC transfered 5BTC to client XYZ.

With IP to IP, it would be more like Client ABC transfered 5BTC to Client XYZ, and add extra data like "for a lotto number or stock buy or store purchase, etc."

This would allow website operators to accept transactions with custom data that can be used to further process for other things.

Example; I run a website where if you send me 10 BTC, I'll e-mail back a copy of an e-book. You could use the client "from address" field to plug in your e-mail so that when the 10BTC comes in, the website will know that it just got a payment and send the e-book to the return e-mail address automatically.

Another use is payment documentation. I transfer 100BTC to XYZ person and put in a comment of what it was for "paid 100BTC for a new video card".

It depends on your network layout. If you are using the entire public network, then yes you are depending on that time for the data to be processed by everyone else that is running a node. But, you don't have to do it that way. You can build a trusted node (like a server) and have your clients direct connect to it and let it do the fast verification for you.

It won't net you 20 confirmations in a few milliseconds, but it will help stop double-spending as long as you remain in control of that node because it knows what is being spent. The whole double-spending issue arises from trust. When you are comparing anonymous seller to anonymous buyer, the only "middle man" for trust is the entire swarm (hence confirmations that neither is cheating)

If you know you can trust your own node(s), then it reduces the likely-hood that double-spending will occur within your own trusted network. So if your example applied to an ATM like card for example, the bank (or whoever) would have all of those ATM machines networked to their own private node (or server) which would then further connect to the outside (Internet) for the rest of the transactions. So if you went to an ATM, withdrew 100 BTC (say the entire account only had that much), then moments later went to another ATM elsewhere and tried to withdraw that amount again, somewhere along that trusted chain would spot a double-spend attempt and basically report back no BTC left for that address.

The whole verification process is how you put the swarm to work, all those clients are examining if your transaction was valid or not, but you don't have to wait for them to transfer the coin around. You can spend the coin around in circles all day without a single transaction verification. It's only when double-spending occurs does the network correct for itself and fix the balances.

Banks already have this exact same problem. They all have their own networks that connect to other bank networks and it's just as easy to double-spend on their ATM as has been demonstrated at black-hat hacker conventions for probably 10+ years now. I remember reading about the issue back in 1997 because a lot of networks will still on dial-up then for banks and the latency issue was part of the attack because everyone had their own *database* that all had to inter-connect.

With bitcoin, everyone is the database and banker and guard at the same time, so while it's not perfect, it's actually a lot better than what banks are using. Have you ever noticed at an ATM they have about 20 "network" stickers for all the different banks and setups that the ATM has to be compatible with?

Hey cool, you can even see the generation and other transactions in it, nice