The behind-the-firewall nodes will need the following from an on-the-network bitcoind:

1. They need to be able to ask it "tell me about any transactions to these bitcoin addresses..."
2. They need to be able to send it a signed transaction and ask "Please broadcast this for me."

Item 1 is implemented in my monitorreceived patch ( https://github.com/gavinandresen/bitcoin-git/tree/monitorreceived ).

Item 2 would be cool.  Anybody want to design and develop an "accept transaction" patch?

All the other functionality needed (like generating public/private keys, generating and signing transactions) could be, and should be, in my opinion, be done as a project separate from bitcoin.  Making the code small and self-contained and as secure as possible would be the goal; it could be re-used to create a type of lightweight client that ran on cell phones in addition to running behind corporate firewalls.

But again:  if that clear interface includes a command to "send XYZ bitcoins to some address", then how is the separation making you more secure?

I agree-- we're in the Wild West days of open-source currency.  I expect people will get burned by scams, imitators, ponzi schemes and price bubbles..

I tend not to worry about things that are out of my control; I don't think there's a whole lot that can be done about scammers, imitators, and ponzi schemes besides warning people to be careful with their money (whether dollars, euros or bitcoins).

First: I've reviewed Bitcoin's networking code looking specifically for possible buffer overflow vulnerabilities, and found none.  It is possible I missed something; please help review the code and let me or Satoshi know if you find anything suspicious.

Second: I don't think splitting the wallet handling code into a separate process will improve security at all.  If there is code that can send the nicely-compartmentalized wallet handling code a command "Send XYZ bitcoins to address 1ABC...", and that code has a buffer overflow vulnerability in it, then you are just as vulnerable as today.

If your PC has been compromised, then you are in trouble; anything you do on your machine may be intercepted by a bad guy.  Log into your bank account website-- the bad guy might hijack your session and transfer money out.  Start up bitcoin-- the bad guy might inject keyboard and mouse events to send coins out.

Even if Bitcoin implemented multi-factor authentication before allowing wallet access ("scan your fingerprint and enter your password to send coins"), if your PC is compromised a bad guy could arrange to modify the bitcoin address that you say you want to send coins to, so you think you're authenticating a payment to Wally's Discount Center but you really authenticate payment to Doctor Evil's Empire.

The test network (run bitcoin with the -testnet flag) is a different block chain, implemented so that the two chains never get confused.  If anybody wants to start yet another block chain, it isn't technically hard, and won't cause any problems for "real bitcoin".

The hard part would be getting anybody to use your alternative; it would have to be better in some way other than just "I started the new chain, so I've got a lot of the easy-to-generate-at-the-beginning-coins."

Actually... prioritizing free transactions based on both amount and their "age" should make this attack toothless.

The basic idea is that if you're spamming lots of small free transactions, you'll be creating lots of brand-new "pennies" (you'll take an old 50BTC generated transaction, then split off a penny and get a penny and 49.99 change.  Then split that 49.99 to get another penny, and so on and so on).

Sorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain ("old money") are given priority would let normal transactions go through.

The spammy transactions would still take up network bandwidth and disk space; if that becomes a problem, nodes could just ignore small, new transactions (not relay them) and let the nodes that are doing the spamming queue up and rebroadcast the transactions.  They'd trickle into the network eventually, and in the meantime the spammer's bit-pennies would be tied up.

You already did.

Hmmm....

At some point (bitcoin 0.9?) debug.log should contain only really critical errors/warnings.  Right now it is more of a trace.log.

Flushing it after every write is the correct thing to do-- otherwise critical information about what caused a crash could easily be lost.

Always closing and re-opening it is darn convenient if you've got a log-rotating script running... but working poorly with FileVault is definitely a bug.

That's not right-- the person paying you doesn't know your public key, they just know your bitcoin address (which is a 160-bit hash of your public key).

You can (and I have) send bitcoins to ANY 160-bit bitcoin address, whether or not there actually is a public/private keypair corresponding to that address.

If Satoshi goes rogue, then the project forks.  He has a very strong incentive (success of the project, growth of the value of the bitcoins he owns) not to do that.

If the SVN repo gets hacked, then we back out the hacked changes (that's easy to see; several of us look at every svn commit) and warn people who might have compiled with bad source to recompile.

I'm having trouble figuring out exactly what you would like to happen-- is your complaint that you have a different definition of what "open source, peer-to-peer" means than the rest of us?

tentative: I don't get it.

You seem to be saying that somebody might be secretly working on a longer block chain, and all their hard work will be ruined because they won't be able to replace the block chain everybody else is using non-secretly because the block chain everybody else is using might get locked in.   Ummm... yeah!  Don't work on longer block chains in secret.

Either that, or you're saying Satoshi might accidently lock in a shorter block chain, and most people either not noticing or not caring.  Umm... no, I don't see that happening.

The block chain lock-in check is only done when new blocks are accepted.  Here is what would happen if Satoshi tried to commit a block lock-in that most of the network thought was shorter:

1. Imagine everybody downloads the new client with the bad lock-in.
2. Everybody who had the longer chain before ignores the lock-in, and continues to push the longer chain.
  (unless the longer chain contains a bad transaction-- the chain is checked for bad transactions on startup, see  CBlock::CheckBlock)
3. Newbies who are downloading the chain for the first time will hit the lock-in code, and will be running with a shorter chain.

There will be chaos as newbies generate blocks on the shorter chain, which only other newbies will accept.  "oldies" will also continue to generate on the longer chain.  Transactions will get added to both chains... and the "oldies" will beat Satoshi into submission.  Unless there is a legitimate bug (like the overflow bug that inspired the block chain lock-in code in the first place).

If I am misunderstanding your concerns, please speak up.  The number one development priority for bitcoin is security.  If you have found a problem, please email or private-message Satoshi, or post here (besides possible network denial-of-service attacks-- only email about those if you have a brilliant idea for how to prevent them...).

Ok, looks like two problems-- if rpcallowip=* works, then maybe bitcoin thinks your IP is something else (or maybe there is a bug in the bitcoin rpcallowip code).  Run this on the web server:

As to why the PHP code isn't working-- can you turn on error_reporting and get more information on what isn't working?

Does it work if you (temporarily) set rpcallowip=*  ?

And are you SURE you're running a bitcoind that supports rpcallowip?  Run bitcoind getinfo, and check the "version" value returned (version 0.3.12 or later, if I'm reading the source correctly).

If bitcoin thinks the connection is not allowed, then it just ignores the connection attempt-- nothing is written to debug.log.  That's probably the right thing to do-- otherwise somebody malicious could try to fill up your hard disk by repeatedly attempting to connect to port 8332.

If you can recompile bitcoind, the "ClientAllowed" routine in rpc.cpp is where a printf() to log connections could go.  But I'd guess either you misspelled "rpcallowip" (I always type rcp instead of rpc...) or have a firewall blocking connections.

If you can ssh into the web server machine (or any other machine, actually), try:
  curl http://machine_or_ip:8332/

If you get "couldn't connect to host" then it is a firewall problem.
If you get "Empty reply from server" then it is an rpcallowip problem.
If you get an HTTP "Authorization Required" or "Authorization Failed" reply, then it is a username/password mismatch (those ARE logged in debug.log, though-- grep for ThreadRPC).

Looks good to me.

Try to connect then look at the end of bitcoin's debug.log; see if it is even getting the connection.

Also:  did you restart bitcoind after adding the rpcallowip?  The .conf file is only read at startup.

Bitcoin: money For the People, By the People. Not the Elites.

(eleven words-- eleven is my favorite number!)

If you've got good crypto there's a fifth choice:

5. Give them dummy keys that unlock something innocuous.

Like a TrueCrypt-encrypted Hidden Volume filesystem.

grondilu, I think your premise is flawed-- banishing the words "money" or "currency" will not help avoid future troubles with governments.

I wonder if we have already passed the point where a user-typed-in-arbitrary-key can be both secure from brute-force attacks and convenient to use.

If you make the key long enough to prevent brute-force try-every-possible-key attacks then typing it in gets really painful.

You can add proof-of-work, but attackers tend to have lots of CPU power (think botnets) and lots of time, and if you make the proof-of-work take more than a few seconds per attempt on a low-CPU device it gets really painful again.

I'm thinking some variation of wallet-on-a-USB-stick might be a more convenient and practical way of physically exchanging bitcoins.

I wonder if Ebay would let you sell USB sticks pre-loaded with Bitcoin, a snapshot of the block chain, and a "starter wallet" with X bitcoins in it...

RE: one mandatory account:  yes, the empty-string-named-account will be the "master" account.

RE: existing use cases:  you should be able to do everything you can do now... EXCEPT for change the label of bitcoin address after it is created.  Although associating a unique transaction ID to a bitcoin address seems like the wrong thing to do (since the same bitcoin address might be re-used for multiple transactions; your application might not allow that, but the addresses are publicly available in the block chain and you might be opening yourself up to unpleasant hacks if you don't consider what should happen if an old bitcoin address that you THOUGHT would be used only once receives a few bit-pennies....)

This morning I thought through what might happen in case of a disaster and a service using accounts had to restore from a wallet backup and some other, alternative source of transaction history (maybe application-specific transaction logs sent to an offsite logging server).

Assuming your backup is recent enough for your keypoolsize, no bitcoins will be lost, but account balances will be wrong because any "move", "sendfrom", and associate-bitcoin-address-with-account actions will be lost.

I've tweaked the proposed API to make recovery easier; I'm still thinking about "setlabel" -- in the recovery case, you definitely DO want to be able to re-associate bitcoin addresses with accounts...