I've been making slow but steady progress on my at-the-network-level testing tool. I don't put a lot of faith in standards documents-- it is too easy to misinterpret or ignore them. Good implementation-independent test suites seem like a better investment of time.

What's working:  python-based code that serializes/deserializes messages in both bitcoin's binary format (to talk to the node being tested) and JSON (so it is easy for us humans to tweak/examine test data). Connecting and requesting all blocks.

Still todo: actually start writing test cases, figure out what other tools I need to write to create good test cases, and start systematically going through the "rules of bitcoin" and devising tests to make sure the rules are being followed-- starting with the super-important "get this wrong and you split the blockchain" rules.

I hope to recruit some of you to help out with all that...  I'll be creating a github project with my progress so far very soon.

The google link on the bitcoin.org homepage is/was my idea.

"The One True Forums" for bitcoin doesn't make sense to me-- the whole point of bitcoin is to be decentralized. I sincerely believe that open and free competition makes everything better, and I hope that more places to discuss bitcoin pop up and compete to be the best.

In the future, I'd like most of the links on the bitcoin.org home page to be google searches, including the "download bitcoin" links (I think we'll see some great new bitcoin clients released over the next six months or so).

Works for me (from a private testnet bitcoind):

Bitcoin 0.3.24 adds a   -port=  option to listen on a port other than 8333 for incoming connections.

Don't do that, you'll just spend a lot of time re-downloading the block chain and then be back in the same state you were before (unless you happen to get lucky and your transactions get confirmed while you're waiting for the block chain to download again).

Restarting bitcoin and letting it get 8 fresh connections might help. Allowing incoming connections so you have more than 8 connections should also help your transactions get confirmed.

Safest thing to do is to be patient; your transactions will be rebroadcast and eventually will get confirmed. If they're not confirmed in a week, then there are ways of deleting the transactions from your wallet and "freeing up" the stuck bitcoins, but messing with your wallet should always be a last resort.

Yes, all of the send* methods return a transaction id on successful send.

Because to non-technical users, "privacy" is a single feature, not a series of separate technical issues.

Does this patch give any sort of warning if bitcoin isn't being used through a proxy?

I worry that a user will be REALLY careful keeping all their addresses separated so their ordinary transactions are separate from their fund-the-oppositition transactions, and then will get busted by the Secret Police who were eavesdropping on their bitcoin IP traffic at their ISP.

Very-low-priority transactions will get dropped by peers, because they look like "spam" transactions and network bandwidth is not free.

I don't know if the current rules are written down anywhere besides the source code; improving the fee-handling and spam-detecting code in bitcoin is high on my bitcoin improvement wish-list, so if they were written down they'd be likely to change fairly soon...

It will get confirmed; it is already 'funded' (you can never send more coins than you have in total in your wallet).

This example might help; if you have exactly two accounts in your bitcoin wallet and their balances are:

Account A: -0.1 BTC
Account B: 1 BTC

... then if you tried to send 1 btc from account B the send would fail with an "insufficient funds" error.

I'd suggest funding a 'TransactionFees' account, and then when a sendfrom results in transaction fees reimburse the account by moving funds from TransactionFees.

I'm thinking about how to do higher-level testing of bitcoin, and I think we could get a lot of mileage out of a testing harness that works at the network protocol level.

I'm thinking of testing things like proper handling of block chain re-orgs and valid and invalid transactions.

Examples:

Block chain re-org test:

• Start a bitcoin client with an empty wallet and just the genesis block, -noirc listening on a non-standard port.
• test harness connects, then feeds it a pre-canned block chain
     ... then sends it a longer fork
• test harness makes sure client accepted the longer chain by sending it a getblocks messsage
    (or disconnects and re-connects and checks the start_height in the version message)
  

Valid/invalid transaction tests

• Start bitcoin client as above
• test harness connects, sends a series of valid and invalid transactions (via inv message and then responding to getdata).
• test harness checks to see if transactions were accepted or rejected by checking responses to getdata (should be no response for invalid transactions)

---

A set of good data files with "tx" and "block" (and "inv" and all the rest) messages in them, combined with something like pexpect could make a good test system. I'm thinking they should be human-readable (with a proxy listening tool or wireshark plugin or something that dumps bitcoin protocol into the human-readable form) but pretty low-level; maybe a version message looks like:


So, before I start working on something like this:  Anybody already doing something similar?

Losing double-spent transactions should probably be reported as -1/unconfirmed, -2/unconfirmed, etc -- meaning "there is a N-confirmed transaction that conflicts with this one."

-6/unconfirmed seems like the natural "this transaction ain't never gonna be confirmed, time to report it as -N/orphan."

-1/unconfirmed should be enough to stop re-transmitting it.

And -120/orphan seems like a safe time to "unspend" any inputs (let them be spent by new transactions) that weren't spent by the other, conflicting transaction.

... he says nonchalantly, knowing full well that actually making bitcoin behave that way means a lot of very careful coding and lots and lots of careful testing...

The shortcut, maybe-good-enough-for-now solution:  export all the private keys from all the messed up wallets.  Start with a clean wallet, then re-import all the private keys and let the clean-slate bitcoin figure it all out.

So go ahead and document it, volunteer to keep it up to date (that's the hard part), and submit a patch. After the latest source-file re-org, there is a top-level doc/ directory where a "wallet_format.txt" file would go.

https://github.com/bitcoin/bitcoin/pull/379

I think this is critical enough to include in 0.3.24rc2.

Who decides whether or not a miner has broken the rules?

Several people have asked me about buying it, but I won't sell it unless I trust that the team that takes it on has experience keeping customer's money safe and the resources to do all of the things I don't have time for-- penetration testing, better customer support, insurance on the coins in escrow, etc.

bitcointools has a fixwallet.py that can often fix broken wallet.dat files.
  https://github.com/gavinandresen/bitcointools/

One of the speakers at the Emerging Technology conference I attended at the CIA was from Facebook Payments, and he seemed pretty adamant that they're committed to doing what they can to keep the people buy the credits (users who want to play games) separate from the people who cash them out (the game developers).

So a facebook app implementation of bitcoinjs would very likely not be approved for Facebook payments.

One of Bitcoin's major challenges is the legal uncertainty surrounding it.

It is really no different from other new Internet technologies (should Skype be regulated like a phone company? Does google's deep-linking violate copyright? ... to give two examples from a few years ago...), but because it is money there are a lot more laws and regulations that may or may not apply.

It'd be easy to ignore that and just damn the torpedoes, full steam ahead with the technology. And given the nature of geeks on the Internet, that is what is going to happen anyway... but I decided it wouldn't hurt to try to be proactive and start a conversation with my representatives in Washington, DC about the Bitcoin Project.

So I met briefly with staffers from Rep. Olver and Sen. Brown's offices yesterday. I gave a very brief overview of bitcoin, mentioned Senator Schumer's "eradicate Silk Road" press conference, and stressed that Bitcoin is meant to be a stable, secure, international currency for the Internet, NOT a currency for criminals.

I also mentioned that the legal uncertainty is a barrier to innovation, and asked for advice on what, if anything, could be done about that. There is no good answer-- government moves really slowly, and they're wedging newfangled Internet ideas into legal structures that were created when telephone were the latest and greatest technology.

However, the house of representatives staffer I talked with did suggest that encouraging you-all to introduce yourselves to your congressperson's staff is a good idea.  If they know that interesting, job-creating bitcoin businesses are happening in their districts and they've met the person making it happen, then they're much more likely to support bitcoin-friendly legislation.

So, if you're an upstanding, law-abiding, clear-thinking citizen doing interesting things with Bitcoin, I encourage you to take a little time and introduce yourself to your representative's staff. I wouldn't bother talking to the representative-- they're probably too old to really understand bitcoin ("Tubes!  Money through the tubes I say!"). Talk to a 20-something staffer who grew up with the Internet and is likely to be a lot more sympathetic to the idea of a peer-to-peer Internet money.

Wow, this snuck up on me...

So I'm headed to Australia in a week.  I'll be in Sydney for a few days; anybody want to meet for lunch on the 9'th or 10'th?

Then I'll be in Hobart for a couple of weeks, then near Cairns for a couple of week beginning July 22'nd; send me an email if you're nearby.