Here's what could happen if somebody controls 50% of the nodes-that-are-accepting-connections:

I join the network with a node behind a firewall (so I only connect out to 8 nodes).  I have a 1-in-256 chance that all my connections are to the cheater's nodes.

If I am very unlucky and all of my connections ARE to cheater nodes, then they can:
  + refuse to relay my transactions to the rest of the network
  + refuse to send me new "block created" messages
  + send me only the addresses of other cheater nodes

They could also send me a bogus version of the block chain (well, bogus back to the last compiled-in checkpoint), but that would be easy to detect (number of blocks in the chain would be different from what everybody else sees).

They could NOT:
  + modify/"damage" transactions
  + hurt the vast majority of network nodes that have at least one connection to a non-cheater

I'm glossing over some details and possible attacks (e.g. if the attacker can hijack my internet connections -- maybe I'm using a wireless network at a cafe -- then I'm screwed because they can just redirect all of my connections to cheaters).

The bottom line is:  make sure you have the right number of blocks (bitcoinwatch.com, for one, will tell you the block count). Don't do financial transactions on untrusted networks. And if your transactions don't go through after half an hour, restart bitcoin to connect to a new set of peers.

Is your Library/Application Data/ directory on a network-mounted volume?

Running bitcoin 0.3.13 on my OSX 10.6.4 Mac I'm not seeing any issues (it uses almost zero CPU when it is not generating, and 100%, but nice'ed, when it is).  I don't see any DirectoryService CPU usage.

From what you've said, it looks like disk writes are chewing up lots of CPU time for some odd reason.

An impromptu brainstorm this morning in IRC chat (thanks everybody!) helped me think through a few issues for an "accounts" API.

The big idea:

Replace the JSON-RPC "label" API with the notion of "accounts".

What is broken about the current API?
 + you can't get a list of all transactions that make up an account's balance
 + if your bitcoin service has the notion of maintaining a balance for multiple
   customers then you end up mirroring information stored in the bitcoin wallet database.
   Mirroring is a problem because if the connection between your service and bitcoin
   fails at the wrong time (e.g. between sending a "sendtoaddress" and getting
   back "sent") your database can be out of sync with the bitcoin reality.

Problems this proposal does NOT tackle:
 + multiple "wallets" for GUI bitcoin users
 + improving anonymity by keeping "coins" from different people in different "wallets"
 + "push" notifications from bitcoin when coins are received (or blocks generated)

NEW METHODS:
------------
getaccountaddress <account>
move <fromaccount> <toaccount> <amount>
sendfrom <account> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to]
listtransactions <account> [minconf=1] [count=10] [start=0]

CHANGES TO EXISTING METHODS:
----------------------------
getbalance [account] [minconf=1]

listreceivedbyaddress:
  return "account" instead of "label" in JSON-RPC result

sendtoaddress:
  same API, but debits accounts as described below

METHODS RENAMED:
----------------
setlabel --> setaccount
getlabel --> getaccountfromaddress
getaddressesbylabel -> getaddressesbyaccount
getreceivedbylabel -> getreceivedbyaccount
listreceivedbylabel -> listreceivedbyaccount
  ... returns "account" instead of "label" in result


METHODS REMOVED (deprecated):
-----------------------------
setlabel


NOTES:
------

All existing routines would continue to be supported for a while (e.g. listreceivedbylabel would be kept as a synonym for listreceivedbyaccount, and would return both "account" and "label" in the JSON result).

Coins going into or out of the wallet that don't have an associated account will be associated with a default account (named the empty string: ""). So sum(account balances) will always equal server account balance.

Generated coins will be assigned to the default account when they mature.

sendtoaddress, and the GUI "send" button, will debit accounts starting with the default account (if it has a non-zero balance) and continuing in alphabetical (ascii) order.the default address, which will be allowed to go negative.

None of these changes will be visible in the graphical user interface. These changes are for people running bitcoind to support bitcoin-related services, not for end-users.

It would be nice to support transactions by batching up several commmands and ensuring that they either all succeed or all fail.  But: this should be useful even without that feature.  The cleanest way of doing that is JSON-RPC-2.0 "batch send", and that all can come in a later version.

Why remove setlabel?  Because it is not clear what "setaccount <bitcoinaddrress>" means for old transactions that were received on that address-- do they remain credited to the old account (confusing!) or does history get rewritten so they are credited to the new account (your accountant/auditor will surely protest!).

UPDATE: svn rev 188 implements most of this (all but gettransactions).  And due to the disaster recovery scenario described below, 'setlabel' stays as 'setaccount'.

I like the Bitcoin = ... ideas.   Focus on the WHY, not the what or the how:
   http://www.ted.com/talks/view/id/848

If you're running something like mybitcoin or mtgox or any other site that lets customers keep bitcoins in accounts, then one-customer-per-bitcoin-process isn't at all practical.  To start with, every bitcoin process has a complete copy of the block chain...

I spent way too many hours yesterday trying to figure out why my Google App Engine code couldn't urlfetch from my -rpcssl bitcoin process, so I'm posting this to hopefully save somebody else from the frustration.

I made Bitcoin's HTTPS-JSON-RPC code fussy about what openssl ciphers it supports on purpose; by default, it doesn't accept SSLV1 connections or older, weaker ciphers or hashing algorithms (like single-DES and MD5).

Surprisingly, Google's App Engine urlfetch service currently ONLY supports RC4/DES/MD5/SHA, so, by default, App Engine can't talk via https to Bitcoin.  The workaround is easy (use the -rpcsslciphers= option to override the ciphers bitcoin will accept), and I'll document this on the rpcssl wiki page.

And hopefully Google will get with the program and support better encryption...

svn rev 172 (bitcoin 0.3.14.01) adds:

"testnet" and "keypoololdest" to getinfo output.  testnet will be true if you are running on the test network.
keypoololdest is the Unix timestamp of the oldest entry in the keypool.

For example:

I also made bitcoin return proper HTTP Date: headers to better follow the HTTP spec.

Dhaw generated all of these coins on his (her?) own machines.

Unfortunately, either due to a bug or some oddness with Dhaw's network connections they were all generated on an alternate block chain.

The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.

I suspect (but am far from certain) that a couple of psychological factors in the average human mind makes deflation worse than inflation.

First, we've got an irrational attachment to "free" (see the book Predictably Irrational for experiments that show this).  If money is deflating, I can just let it sit under my mattress for "free" -- and that might be more attractive to me even though I'd get a better return by investing it.  Investing ALWAYS looks like it costs something (brokerage commissions or lawyers fees or...).

And second, we've got an irrational aversion to loss and an irrational attachment to stuff that we own.  Investment means opening yourself up to the possiblity of loss AND lending out something you own; I think a little bit of inflation helps overcome that irrationality, by building in a little loss if you stick your money under your mattress.

I wonder if somebody could devise a small-scale experiment to figure out if deflation is bad for investment, and/or measure the size of the effect...

RE: payment:
If you really feel compelled to pay, send coins to the Faucet: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC

I implemented "validateaddress" in svn r169:


$ ./bitcoind validateaddress '1P3rpbSybuGgeL1bRwCJFWbn4yBjRNQrbY'
{
    "isvalid" : true,
    "address" : "1P3rpbSybuGgeL1bRwCJFWbn4yBjRNQrbY",
    "ismine" : true
}
$ ./bitcoind validateaddress '1111111111111111111114oLvT2'
{
    "isvalid" : true,
    "address" : "1111111111111111111114oLvT2",
    "ismine" : false
}
$ ./bitcoind validateaddress 'mwFzbfqePwXUyT28e1kFVVh48uMHDsRzbi'
{
    "isvalid" : false
}

No address version number; that wasn't trivial to do, so I didn't do it.

Awww, even replacing the lower-case-l's with 1's it ain't right:

Ruby (or your Ruby JSON-RPC library) isn't setting the Authorization: HTTP header from the username:password in the URL.

I don't know anything about Ruby, but Mr. Google might be able to shed some light-- you need to either set the Authorization: header yourself to do the HTTP Basic authentication (I seem to recall some Ruby code on the Wikipedia page about HTTP Basic Authentication) or, in some languages/frameworks there's a way of setting up a 'context' for HTTP connections so the authentication happens properly.

Thanks theymos!  I completely missed the leading-zero-bytes become leading-'1'-chars one-for-one.

I fixed the python code in the first message of this thread.

RE: what's the use of b58_encode?  It is dead code for this use-- bitcointools (where I first implemented this stuff) uses it to translate from binary hash160 to human-readable bitcoin addresses.

RE: 27 character bitcoin addresses:  I'm puzzled.  There's a mismatch between the way bitcoin treats leading zeros (leading 1's when base58 encoded) and the way my python code treats them.

ByteCoin: have you dissected the bitcoin code enough to explain how it decides how many leading zeros to add?  According to my code, '14oLvT2' and '11111111111111111111111111114oLvT2' are the same bitcoin address (corresponding to the public key with a hash of all zero bytes).

But bitcoin only likes the 27-character '1111111111111111111114oLvT2' version.

I'll have to stare at the code some more tomorrow when I'm more awake.

Bitcoin version 0.3.13.05 (svn revision 168) adds the -testnet option to bitcoin/bitcoind, for testing or experimentation with worthless bitcoins on the TEST payment network.

This version is compatible with my old compile-time test network patch.  Stuff you aught to know as you run this:

• A -testnet bitcoin will use the same bitcoin.conf file as regular bitcoin (unless overridden with the -conf= switch).
• The -testnet data directory is a "testnet" subdirectory in the regular data directory.
• A -testnet bitcoin listens for connections on ports 8333/8332, just like regular bitcoin, so you cannot run both -testnet and regular bitcoin at the same time on one machine.
• You can get play bitcoins from the TEST faucet at https://freebitcoins.appspot.com/TEST/
• testnet bitcoin addresses will not work on the regular bitcoin network, so it is impossible to accidently try to send real bitcoins to test address.  However, regular bitcoin addresses are valid testnet addresses; it is possible to try to send testnet bitcoins to a regular bitcoin address (they will effectively be lost if you do that).

This will be very useful for anybody creating a web-based bitcoin service.  You should be able to run bitcoind with the -testnet switch and no code changes to test your service with pretend, instead of real, bitcoins.

This looks pretty interesting (in the US):  http://www.paynearme.com/
Print out a payment slip on a website, walk into a store and finalize payment in cash, website merchant gets immediately notified.

From their Terms of Service:  "Please do not confuse our PayNearMe payment service with use of a credit card, debit card or pre-paid/loaded card. There is no extension of credit. And since there is no credit extended, there is no ability to challenge or cancel the transaction through a chargeback procedure."

Keys in the keypool store when they're generated (and the oldest are always used first).   Asking "what's the oldest key in the key pool" seems reasonable, and I think it would give you what you want-- you could compare that timestamp to the timestamp of your last backup to see if you're covered.

Although if you're going to periodically check to see what the oldest timestamp is (or you're going to periodically check to see if bitcoin has written a new timestamped backup file or periodically check WHATEVER) then it seems simpler to me to just periodically always call backupwallet.  Disk space and bandwidth is cheap these days...

nBits is difficulty in 'compact' format?  (if I recall correctly...)

It should be reported as floating-point 'difficulty', like you get from the 'getinfo' rpc command.

I will add that.

Backup every 30 sendtoaddress or generatenewaddress and you'll be fine-- you should always have at least 3 backup copies of all your keys.

If you're running a very busy service so backing up every 30 is too often, then run with -keypool=1000 and backup at least every 300 sends/generates.

I worry about bitcoin accumulating too many features and not doing any of them very well.  I suppose it wouldn't hurt to add an option so it automatically creates timestamped wallet backups... but should it erase old backups?  (if it doesn't, I KNOW people will forget to erase them and will be upset when their disk fills up with wallet backups and they're left to figure out how to clean up the resulting mess).  Should it encrypt them?  What should it do if an automatic time-stamped wallet backup fails?  When encrypted wallets are implemented, what should happen to old backups if the wallet encryption key is changed?