BitcoinTalk

Security

BitcoinTalk
#1
From:
Bitcoiner
Subject:
Security
Date:
Has there been a concerted effort to attack, subvert, or break Bitcoin? One way to test that it is secure from attack would be to actually try to undermine it, by double-spending coins, creating fake coins, posting false transactions, etc... and if flaws are found, better that they are found now than later, when the bitcoin economy is potentially larger and there is more to lose.
BitcoinTalk
#2
From:
Gavin Andresen
Subject:
Re: Security
Date:
It's a bad idea to try to break the "in-production" bitcoin network.

If anybody is starting serious work on either extending Bitcoin or developing compatible implementations or trying to break it by creating bad transactions, I think creating a "parallel universe" test network with its own block chain, data directory, etc makes sense.

Satoshi:  would you be open to a --testnetwork (or something) flag to bitcoin that swapped to an alternate genesis block, data directory, listen port and IRC channel?  Maybe with a really short average block generation time, too (like once per minute instead of once per 10 minutes) so everything happens ten times a fast to make testing quicker.
 
BitcoinTalk
#3
From:
llama
Subject:
Re: Security
Date:

Satoshi:  would you be open to a --testnetwork (or something) flag to bitcoin that swapped to an alternate genesis block, data directory, listen port and IRC channel?  Maybe with a really short average block generation time, too (like once per minute instead of once per 10 minutes) so everything happens ten times a fast to make testing quicker.
 

I second this, however I don't think block generation time should be changed.  I think it should be identical to the production network.  This, for example, would allow testers to try to subvert the system by creating nodes with particularly low latency, and keep the results applicable to the real network.

Great idea Gavin!
BitcoinTalk
#4
From:
satoshi
Subject:
Re: Security
Date:
I'll start thinking about how to do this.

At the moment, you can kind of use -connect.  You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100.  If you start it out blank and don't let it connect to the main network, the difficulty is still at the original low difficulty.  If you've port-forwarded though, then outside nodes might still connect inward to you.

With -connect it still uses IRC, do you think it shouldn't get on IRC when you're telling it to only connect to specific nodes with -connect?  The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two.  In that case, you wouldn't want the -connect computers on IRC.

void ThreadIRCSeed(void* parg)
{
    if (mapArgs.count("-connect"))
        return;