Does the fee come out of thin air or is it taken to from the transaction so that it cost 25,009 to send 25,000 BTC?

They can, but the odds that you'll get useful exploit code that just happens to be that collision are still insanely high.

I'll share (2) IPs

64.186.154.76

and

64.186.155.104

What amount does one have to send to incur a transaction fee though? I've send some large amounts around myself and never saw a fee?

Anyone know where the changelist is, I'm curious to what was fixed/changed/etc.

I don't think the block download brings your computer to a halt, it's more like the program isn't going to burn up 100 megabits to get the blocks. It runs very light on bandwidth and so do the other peers you are connected to get the blocks.

That's why I created those package block downloads, to save time. It's quicker to download a small 32 MB file from my fiber connection than to wait a while for the p2p network to send it to you.

I'm 100% certain that he isn't really generating that much and I'll leave it at that.

If the machine is setup to only connect to their node, that could work since it would be kind of a central spending point that would quickly be able to tell if someone was trying to double-spend the coin.

As for different networks and nodes, like Bob's Escrow is different from Jane's Escrow, the added delay would make a theoretical attack possible, but no one is going to get rich ripping off vending machines.

That might be a good experiment to try on the test network to see what happens. I think it both machines are going through the same node, then trying to double speed should be stopped at the first node if they both are connected to it first.

I"m not part of the development team, but my take on it is that you'll just be replacing the randomness with another randomness. Right now, even though the difficulty is very high, blocks are still being generated in under 3 to 5 minutes. So if this new system was in place, you would still be waiting for a block just as long as you would now. I don't usually disclose how many PCs I have in the BTC network for sanity reasons, but let me say that I have systems that can barely manage 90 khash/s and a few that are chruning out 19,2000 khash/s and one beast doing 38,400 khash/s. They don't win any more blocks than the much slower PCs does. One of my 900MHz PCs solved a block under 100 seconds by pure chance alone after the difficulty was increased. The other super clusters are still 0 after the difficulty went up earlier today.

I'm afraid your solution would give my super clusters a big advantage because then it becomes they will always have the lowest hashed block if it's a CPU vs CPU thing.

I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.

My bad, I'll restrict the 32 core systems to doing the main bitcoin generation next time instead of seeing what would happen at the beginning of a test network  

Testing the new release candidate. This resolves the minimize on close accidentally doing a minimize to tray. No X server crashes either, nice! Now only if we could get that tray thing to work again 

Interesting, I could still be alive then.  *gramps sitting in rocking chair*  "I remember back in the old days when we didn't have 200 core computers in our cell phones to create these blocks" to which the great-great-great grand kids reply "Yeah, he's loony; everyone knows there is no such thing as a single core computer...." 

It does, but it's using calculations based on the swarm. I think it would need something new to predict what an individual computer will do.

LOL, I can see the frontpage with the FBI hauling out high power voltage lines rigged to a server farm with the guy yelling "Don't unplug them, I still need 20 more confirmations for the last 50 that was generated!!"

Ah ok, cool. I continue to be astounded by how much thought was put into this system to keep it balanced, nice job!

As long as it doesn't become self aware (as computers often do) and then it will know what I've been spending my Bit Coins on. 

The Windows Client had it's own static IP with port 8333 open for it, I could see from the gateway device that it was connecting out to other peers and other peers were connecting back in. But after the 8, it's like it quit connecting out to peers and after a while the incoming peers stopped as well since it appeared to only be concerned with the peers on the LAN vs the WAN. The behavior of the Linux client is different though I've noticed, even if 50 people are connected to it, it will still seek outbound connections to other peers and inbound peers continue to trickle in as well.

While this will only be a problem for people like me that have hundreds of PCs at their disposal, the reverse is, one could setup PC(s) to connect to a single client 8 or more times and then after a while, the poor windows client would suck itself into it's own matrix world where it thinks it's on the network solving blocks, but it's really trapped back in time.

This is just a theoretical attack of course, I'm not going to lose any sleep over it, but I figured I would throw it out there for the future. The easiest way to negate this would be to put in some self-checking code for IPs. Basically, have to check that is has 8 connections or more that are NOT from the LAN/Same IP Address/etc when it's running as a dual node/client mode.

So if the difficulty was increased so high that it took a day to find a winning block, that means the lucky winner would have to wait 120 day before they could spend it or about 4 months if everyone else was averaging about the same speed? Seems like at the high end of the difficulty, there is an issue with coin generation vs. being able to put it into circulation by spending. Wouldn't the long delay cause a lot of generated coin to be lost because anything could happen to the PC that won in a long amount of time if the winner had to really wait that long? They might un-install the program or the computer get eaten by a virus or power surge well before then.