Any level of testing is useful and appreciated.  Various types of testing that are helpful:

• "it works" testing:  Simply run the latest Release Candidate (or latest version, if released).  Make sure all the basics work (for whatever definition of "basics" you desire).  This is the level most accessible to casual users.
• Major features testing:  Develop a short checklist of must-work features, and organize volunteers to work together and go through that checklist, item by item.  Test each major feature on each major platform.
• Stress and fuzz testing:  Attempt to "stress" the system somehow, or randomly corrupt bits of data.  See what breaks.
• Regression testing:  Record bugs fixed, and develop automated test cases that successfully reproduce the bugs on older versions, and verify newer versions remain fixed.
• Unit function testing:  Rigorously exercise each C++ class to ensure it behaves as expected at a micro level.
• Full peer automated testing:  Automated testing of RPC and P2P functions is non-existent, because of the difficulty in doing so.  Find a solution to this problem.
• Data-driven tests: If possible, write software-neutral, data-driven tests.  This enables clients other than the reference one (Satoshi client) to be tested. Embed tests in testnet3 chain, if possible.

The community at large can be a big help simply by doing the first item:  download and run the Release Candidates and the latest version, and report any problems.  Even reporting success is fine by me, for example: "Version 0.7.1 works for me on Windows 7/32-bit" posted on a forum thread.

It is always very difficult to organize any sort of testing regime with open source volunteers that come and go.  Each volunteer chooses their level of involvement.  Any amount of testing and test-case writing, large or small, is helpful to bitcoin.

Thanks for the report.  We definitely hear you, and hope you will try 0.8.  The network sync (processing blocks) is significantly faster, minutes instead of hours.

Correct.  -loadblock=FILE is the answer for the current client (0.7 or later).  That imports and validates blocks from the given file(s) in the same manner as the Initial Block Download (IBD) performed over the network.

Old ideas -- Search for "colored coins" and "smart property".

Miners only select (or ignore) transactions provided to them.

The bitcoin client you run chooses what transactions and blocks to validate and relay.

Miners cannot change the rules without bitcoin user agreement.

The on-disk block file format was just updated to match the network's "block" message format.

This is an incompatible change.  You will need to delete, and re-download, your block databases.

Thankfully, the network is not centrally-controlled.  And hopefully never will be.

The existence of an incentive does not presuppose all will follow that.

Thankfully, most do, otherwise value would collapse.

And if everybody's bitcoin transactions take forever to confirm, users will abandon the network, and bitcoins will have no value.

Miners have an incentive to encourage users to use bitcoins, over and above simple fee income.

The more users, the more value conferred by the block reward + fee total.

No users, block reward + fee is worthless.

Block's nVersion policy is already specified, in the recently accepted BIP 34 - "Block v2, Height in Coinbase"

Please do not use nVersion as an additional nonce.

Stratum mining and getblocktemplate (BIP 22) already have provisions for ASIC miners, through the extraNonce field and other possibilities.  This provides unlimited nonce range.

Any change to the block header is a hard fork upgrade, and should be avoided at all costs.

We are overly cautious because any screwup costs real money.  Literally.

Sorry, this is just not true.  Nobody started off "suggesting that users use online wallet services."

The advice has always been "run a node, if you can.  Please please please run a node.  If you absolutely cannot run a node...  use a mobile or online wallet."

Online wallet has always been a last resort, because that is a centralized solution.

The more people that run nodes, the stronger the network.

No.   Any miner doing that will cause bitcoins to lose all value, at which point the network will route around the troublemaker.

Limiting your mind to a decentralized, distributed currency is thinking too small.

Think decentralized, distributed financial system.  Bitcoin is just the base for something bigger.

Too centralized.  Try distributed bonds.

Or even better, a merge-mined data timestamping service...  no blockchain bloat, as it is just another merkle branch in the merged-mining merkle tree (of which a single merkle root is then published in each block's coinbase).

AFAIK, most simply do not bother to detect network mischief at all, outside of what bitcoind protects.  No algorithm.

You cannot defend against the "miner spends, while simultaneously withholding a block containing a double-spend"  This is impossible to detect beforehand with any algorithm.

Merchants simply make a business decision to accept the risk of a double-spend, by (a) being well-connected, and (b) only selling inexpensive items where it is not worth the difficulty of an attack.

Edit: and (c) employing external anti-fraud mechanisms to hopefully select customers less likely to double-spend.

As has been repeatedly stated, Bitcoin Foundation will not be directing the dev team to work on specific projects.

More likely the reverse is true:  the community and dev team will suggest things that need funding (like Gavin's salary).  If the Foundation's members agree, it happens.  Otherwise, it doesn't.

It is generally inadvisable to come up with licenses on your own.

Smart lawyers spent years on the current licenses, including rounds of open review and comments across multiple jurisdictions in the world.

It is doubtful lone efforts will match that sufficiently to make a bulletproof license, compared to existing ones.

Typically the choice is GPL (and variants like LGPL) or BSD (and variants like MIT/X11).  Those licenses are much more likely to have established court and legal precedent.

If you read the thread, you will see many examples where it is clearly beneficial to open source:  Linux Foundation, Apache Software Foundation, Tor Project, ...

I'd wager much of the open source software you use every day, even if unknowningly via remote, is covered by one or more open source foundations.

No.  Version 2 blocks are accepted and relayed just fine.


Mining a version 2 block will not hurt your chances of propagation.  You should mine version 2 blocks, if possible.