I would say everyone connected to everyone (first option) because the one big node that has 1,000 other clients connected through it is great for redundancy, but also gives a good central point of attack. It's easier to attack a single node than to try and attack them all.

I've been running some experiments with some isolated BitCoin clients to test for bugs or security issues. So far so good, haven't found anything worthy of discussion here, but I did come across a thought experiment, I figured I would put it out for discussion.

I understand how the core of BitCoin prevents cheating, basically you take the network combined CPU power to generate a chain that rely on math principles to prevent someone from trying to cheat due to that person needing more *corrupt* CPU power than *honest* CPU power out on the network making a direct attack against the block chain too expensive or difficult.

Has anyone thought about what happen if instead of attacking the block chain or math principles that build via CPU time and instead attacked the time itself as a way to produce a *corrupt* chain that could be fitted into the existing clients without needing to defeat all the CPU time it took to produce it? Instead of trying to throw as much CPU power at building a corrupt chain, you instead focus on cheating time to build a corrupt chain?

Would an attack like that really be something to worry about?

I can already tell you, it has almost no impact on the CPU, it will shave off some khash/s, but the big difference is bandwidth and memory.

When running the program by itself (8 connection limit), you'll use between 16 and 28 MB of RAM for the program, 300MB a month for bandwidth (24/7 operation basically)

When you run *nearly* unlimited connections, the memory usage jumps up to about 128MB of RAM, bandwidth usage also jumps way up as well to where you are using 100MB in a day instead of a month.

Truthfully though, for a "super node" as you've now coined it  it's not really that hard spec wise for any server to handle, my old celeron server could easily handle this kind of load if it was shaved down to just a few thousand connections.

Exactly why a good count would be difficult as it currently is setup. I could have hundreds of clients behind a node and the outside world (Internet) would never know from what I know about how everything works.

The connection limit is just a suggestion, you can connect more than 8 clients even without a custom compile. The limit was setup to prevent a home PC from making thousands of connections and overloading "generic" home routers that can't handle that kind of connection state table. Think of the 8 limit as more of a soft-limit for sanity reasons for the typical user of the program.

Maybe not official, but I compile my own BitCoind to run unlimited connections (well, in theory I set the limit for 65535)

As of now, I have about 7,100 connections going, so I would assume *at least* that many nodes are out there now.

I'm running an experiment to give everyone a more definitive answer.

I have two fresh PC each running the BitCoin client (new install, no blocks, transactions, etc) and they are only network to each other. I'm having them generate coin against each other.

I think that if such a large network split did happen, it would be from the client standpoint (basically someone would compile a client that uses a different bootstrap method, so in essence you would have a "new" bitcoin chain that would forever be separate from everyone else).

Are you looking to save up to buy other things or just need some BTC to experiment with?

Not easily because it would entail finding out what "blocks" everyone else has. Since everyone is working off the current chain, if you did find a client with "another" chain, it would either be silly short or hacker longer.

It is possible to run an experiment just to see what happens. It would take 4 separate clients though running at the same time (probably help to have 4 different PC to do this)

Basically, take a fresh install of 2 PC, have them only connect to each other and let them generate blocks starting at 1, build up some coin, transfer between the two in a few transactions, then shut them down. Do the same thing on 2 different PC, build some coin for longer (more blocks), transfer some coin around, shut them down. Then fire up all 4 at the same time and have all 4 connected to each other and see what happens when one pair had a longer block chain than another.

My guess is the longer block chain will win and the lesser of the pair would lose all of their history/coins.

So if this was on a much larger scale (east vs. west), then whoever had the longest block chain would win once the networks started to merge back together.

Thinking about that thought experiment, one could run their own internal micro-payment system for fun 

Since I didn't find a forum post or wiki on this (I probably should add to the wiki), I've compiled a static help file, figured it would be useful for everyone here doing a lot of work with bitcoind. Some are obvious, but other's didn't have a full description.

• getaddressesbylabel <label>
  Returns the list of addresses with the given label.
  
  
• getbalance
  Returns the server's available balance.
  
  
• getblockcount
  Returns the number of blocks in the longest block chain
  
  
• getblocknumber
  Returns the block number of the latest block in the longest block chain.
  
  
• getconnectioncount
  Returns the number of connections to other nodes
  
  
• getdifficulty
  Returns the proof-of-work difficulty as a multiple of the minimum difficulty.
  
  
• getgenerate
  Returns if the server is generating coins. Returns true or false.
  
  
• getinfo
  Returns the server balance, blocks, connections, proxy, generate, genproclimit, & difficulty
  
  
• getlabel <bitcoinaddress>
  Returns the label associated with the given address.
  
  
• getnewaddress [label]
  Returns a new bitcoin address for receiving payments.
  If [label] is specified (recommended), it is added to the address book so payments received with the address will be labeled.
  
  
• getreceivedbyaddress <bitcoinaddress> [minconf=1]
  Returns the total amount received by <bitcoinaddress> in transactions with at least [minconf] confirmations.
  
  
• getreceivedbylabel <label> [minconf=1]
  Returns the total amount received by addresses with <label> in transactions with at least [minconf] confirmations.
  
  
• help
  Returns list of available commands.
  
  
• listreceivedbyaddress [minconf=1] [includeempty=false]
  [minconf] is the minimum number of confirmations before payments are included.
  [includeempty] whether to include addresses that haven't received any payments.
  Returns an array of objects containing:
  "address" : receiving address
  "label" : the label of the receiving address
  "amount" : total amount received by the address
  "confirmations" : number of confirmations of the most recent transaction included
  
  
• listreceivedbylabel [minconf=1] [includeempty=false]
  [minconf] is the minimum number of confirmations before payments are included.
  [includeempty] whether to include labels that haven't received any payments.
  Returns an array of objects containing:
  "label" : the label of the receiving addresses
  "amount" : total amount received by addresses with this label
  "confirmations" : number of confirmations of the most recent transaction included
  
  
• sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]
  <amount> is a real and is rounded to the nearest 0.01
  
  
• setgenerate <generate> [genproclimit]
  <generate> is true or false to turn generation on or off.
  Generation is limited to [genproclimit] processors, -1 is unlimited.
  
  
• setlabel <bitcoinaddress> <label>
  Sets the label associated with the given address.
  
  
• stop
  Kills the bitcoind process
  

Is it a AMD only optimization perhaps?

I can tell you from personal experience, you are better off buying them in the market than generating them now due to the growth of the network clients and the current difficulty level makes buying server time no longer economical.

Perhaps if a stable OpenCL client comes out  

I've got 7 year old celeron machines generating blocks, so speed isn't really king for coin generation as much as just luck and having a lot of systems to try 

Similar to like a phone card for those pre-paid phones. You get a card for $15, $25, etc. amounts. Wal-mart *activates* the card by swiping it like a credit card, then those jumbled random numbers on the back are active to transfer X amount of BitCoins to whichever address you specify.

This allows you to buy the cards with cash (no credit/debit trail), but the only issue is really, how many BitCoins do I get for $1.00 for example? That's where the tricky part lies, I'm going to have to poll as many market sites as (they) will allow me to (talking with others about it) to get the conversion rate. So while it's possible that if you buy a $10 card and redeem it that day for more bitcoins than you would have got the day before, the key will be to make sure people understand that when they buy it. So they can buy it has sort of a investment or spending currency if they like.

It's certainly going to be easier to sell them that way to the giants like Wal-mart than to convince them to take BitCoins as payment. As time goes on though and things expand, who knows what the future may hold.

About the closest you'll find so far is me, as part of the greater Nashville, TN area.

Instead of wasting with them (they do frustrate me sometimes), why not create a new article at a more "friendly" place like
http://en.citizendium.org/wiki/Welcome_to_Citizendium

Actually you guys kind of stumbled upon part of the project I'm working on with a bank. Basically, (as was said with paypal, credit cards, etc.) you have to pay a loss to get BitCoins in and out of conversion. Part of what I'm working on is what you guys describe, go buy a BitCoin "card" at a store, redeem it online to have the BitCoins transfered to your account to purchase with, pay bills, etc.

Instead of wasting with them (they do frustrate me sometimes), why not create a new article at a more "friendly" place like
http://en.citizendium.org/wiki/Welcome_to_Citizendium

I would post up the compile log in the Development & Technical section, might get more help there.