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...

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.