I just committed a minimal implementation of "accounts", as discussed a few weeks ago in this thread.

If you're using the command-line or JSON APIs, you should be aware of a change that might make your code break:  the sendtoaddress method will return a hexadecimal transaction id (256-bit hash) instead of the string 'sent'.

All of the 'label' commands have been renamed; the old names are still supported but are deprecated and may eventually be removed.

If you're developing a web service using bitcoin, the new 'sendfrom' and 'move' methods can make it much easier to keep track of customer account balances.  The API is intended to be used like this:

Create a new account:  just generate a unique account ID in your application (maybe customer's login name).

Get a bitcoin receiving address associated with the account:
  getaccountaddress <account_id>
 Note: multiple bitcoin addresses can be associated with the account

Send bitcoins from the customer's account:
  sendfrom <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to]
 Will fail if <fromaccount> doesn't have enough bitcoins (otherwise returns transaction id)

Move bitcoins between accounts:
  move <fromaccount> <toaccount> <amount> [minconf=1] [comment]
 Will fail if <fromaccount> doesn't have enough bitcoins

Report account balance:
  getbalance [account] [minconf=1]


The empty-string account is a little bit special.  Any coins received on bitcoin addresses not associated with other accounts is credited to it, and coins sent via the (old) sendtoaddress method are debited from it.

Coming soon, I hope, will be a gettransaction <txid> method to return details of a transaction that is stored in your wallet (like which account it was to or from and whether or not transaction fees were paid).  And listtransactions, to get an accountant-friendly itemized list of all the transactions that went into any particular account balance.

I worry that the correct analogy is:

Typing a password every time you use your bitcoin wallet is like putting padding your car's steering wheel instead of wearing a seatbelt.  It might make you feel safer, but it is a false sense of security.

Good security is hard.  If you're not computer savvy, then you've probably already got spyware and trojans on your system, and running bitcoin on a system infested with spyware and trojans is a bad idea.  Period.

I think an online service that takes care of wallet security for you is a much better solution for non-geeks like my mom.

All that said:  As my personal bitcoin wallet gets more valuable, I get more nervous.  I would like to be able to export some of the value in my wallet onto a USB thumb drive and then put that thumb drive in my safe deposit box (along with a backup, gpg-encrypted copy that I'd keep in the fire safe in my basement).

Another analogy:  I keep most of my money in the bank; I don't have piles of cash or gold in my house.  I will do the same for my bitcoins, keeping only enough in my online, connected, possible-to-hack wallet to use day-to-day.

Wasn't me.  I don't remember Satoshi ever writing something like that, but I'm really good at forgetting things.

I agree with ribuck, if we ever need more than 21quadrillion bit-atoms, encoding more using the unused high bits in the 64-bit number will work nicely.

That would be a very nice problem to have.

The keypool IS used for coin-generation transactions.

And the way it is implemented, it should never throw away keys.  If I recall correctly, there is a very small chance if you lose power or bitcoin crashes a key from the keypool could be used twice.  But that has no bad effects, it is just very unusual.

Everybody is looking for:

h = f(x), where h < TARGET

I think you're asking if there is some weakness in SHA256 (or hashing in general) that can make solving that problem trivial.

It seems unlikely to me, but I'm not a professional cryptographer.  If TARGET were '4', then the problem is equivalent to:
h = f(x) where h = 0 OR h=1 OR h=2 OR h=3

Maybe there's some tricky method that reuses work and makes solving the TARGET=4 case more than 4 times easier than solving for TARGET=1 (which is "find this specific hash")... but I just don't see that doing anything more than what has already been pointed out in previous posts:  it is just a quicker way of hashing, so difficulty would go up.

Good article!

And good job jgarzik on answering questions!

daveout's code isn't quite right (because he based it on an earlier version of my python code).

Corrected version of the python code is in this thread.

Bitcoins are 50 times more valuable today than when I first heard about them six months ago.  If they just double in the next six months, they'll have risen 100-fold in a year.

It seems like a good idea to me to come to a consensus now about when to "move the decimal points" -- when should the Bitcoin program allow you to specify payments with more than two decimal places (e.g. "pay Gavin 0.001 BTC for his thoughts") ?

When should the Bitcoin program assume you're entering payments in 'millicoins' or 'microcoins' ?

And when should all of the internal minimums (e.g. smallest transaction fee or the trigger for the 'micro-transaction spam prevention') be lowered?


Here's a straw-man off the top of my head:

When Bitcoins are worth more than about ten dollars (or euros) each, I think it'll be time to allow sub-bit-penny payments.  And I think the "smallest free transaction" limit (and other internal minimums) should move in lock-step with that change.

When 1 Bitcoin is worth somewhere around $100 (in 2010 dollars), I think it'll be time for the client to switch to millicoins (e.g. .001 BTC), so if I'm buying a paperback book it costs 50 milliBTC  instead of  .05 BTC.

It'd been a while since I shot myself in my foot, so I guess I was overdue.

Anyhow, on my third attempt I think I've got it right-- I fixed a bug that was causing Bitcoin to be unusably slow on Macs running FileVault (the built-in filesystem encryption on the Mac).

The problem was Bitcoin opening and then closing the debug.log file on every write.  After a couple of "too clever for my own good" solutions that broke, or could break, in interesting ways, the code now opens debug.log and simply keeps it open, constantly appending to it.

If you run a bitcoind server, see the "don't forget to rotate your logs" thread for what you need to do for log rotation to work properly.

I just committed a change to svn to the way debug.log is written that means you need to change your logrotate configuration.

Why the change:  before, bitcoin was opening and closing debug.log on every print.  That caused it to be unusable on Macs running FileVault (and slower than it aught to be on various other systems).

After subversion rev 183, bitcoin will keep debug.log open and just append to it.

If you're rotating logs using the unix logrotate command, just add 'copytruncate' to its configuration file and the right thing will happen.  I changed the example in my post above.

ShadowOfHarbringer:  don't be lazy!  If you want to know if the lockins have been changed, it is easy to find out for yourself.

The blockchain checkpoints are in file main.cpp, around line 1,519:

Even if you don't know C++ or don't know how to use subversion, you can check every release here: http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/

Umm... how would they do that?

If even one machine remained connected to both the MiB and the rest of the network, then there will be no split.  Transactions and blocks will continue to flow between them.

And if the MiB disconnect themselves from everybody else... then what they do has no effect on anybody else.

If the MiB have more than 50% of the block generating power then they can set the rules as you describe (refuse to put transactions with fees into the block chain, etc).  If we didn't like it, we could write code that detected that they were "breaking the rules" (for example, we could reject generated blocks with no or very few free transactions, when we know there are old, free transactions waiting to go into a block), and work on our own "minority" chain.  Convince the merchants and exchanges to run our code instead of the MiB code and the MiB can go play with themselves, we'll all happily continue trading with each other on the minority chain.

So....

I want to register a new domain name "gavin.bitdns" in this hypothetical bitdns system.

How do I do it?  Run a BitX miner and hope that I generate a block sometime in the next week or three?  Ummm... yuck!

Or I want to buy a domain from somebody; what does that look like in the bitdns system?

Bad idea until we have secure DNS (DNSSEC) everywhere.

And maybe even a bad idea then; one slip of the fingers and your bitcoins might go to amazone.com instead of amazon.com.

How could I forget good old Berkeley DB?  So old its approach (schemaless key-value store) is back in fashion...

So: FOUR other open source projects.  Berkeley DB is also 100% open source.

I'm a "bleeding heart libertarian."  When I was young and naive I was "progressive/liberal," but now that I'm old and wise (or maybe just more cynical) I have a much greater respect for the positive incentives built-in to private markets, and the negative incentives built-in to government.

So I'm very sympathetic to the "it isn't fair that people with the fastest/most GPUs generate more bitcoins" point of view.

I agree that it would be more fair if every person started with an equal number of bitcoins.  Work harder than average or provide a service that people value and you'd end up with more than you started with.  Otherwise, you'd get bitcoin poor.

But I don't see a way to do that without some central authority deciding who is, and who is not, a 'person'.  And I'm old and cynical enough to think that if there WAS a central authority making that decision, that central authority would very quickly devolve into a corrupt, favor-granting, power-grabbing institution.

"Oh, I'm sorry Mr. Andresen, for the Good of the System we are delaying the granting of your second child's Bitcoin Bounty until they have completed the mandatory consumer education classes, registered to vote, and have completed the voluntary 250 hours of America Freedom:Works! projects that they were assigned."

If you've got a brilliant, fool-proof, decentralized way of solving the identity problem, speak up!  That'd be an even bigger breakthrough than bitcoin.

Probably against all of the credit card companies' terms of service; they don't like you taking money before "shipping the product."

Relevant threads from the past:
  http://bitcointalk.org/index.php?topic=227.0
  http://bitcointalk.org/index.php?topic=1494.0

I think a fully licensed online bitcoin exchange to/from US dollars via online credit card transactions (or another really quick, convenient mechanism) is critically needed.

Is it worth attempting:  I've been very tempted!  Unfortunately, to do it right and jump through all the legal hoops would require at least posting a $50,000 bond and probably thousands, possibly tens-of-thousands of dollars to hire lawyers to get all the paperwork in order.

And then I'd have to figure out how to accept credit card payments for bitcoins in a way that didn't open me up to massive fraud (maybe secondary approval via a phone call or text message).  And convince a merchant account provider that I'd solved that problem and that I was trustworthy (which probably means another infusion of tens of thousands of dollars to cover potential fraud).

I think it is a great opportunity for somebody (or some company) who has had prior experience in the currency exchange business.  The business model is clear and proven, and being the first fully licensed bitcoin exchange would have huge potential benefits if Bitcoin turns out to be a really successful.

All great ideas that I'm confident will eventually happen... assuming Bitcoin doesn't crash and burn for some reason (yes, I'm working hard on a technology I think has about a 30% chance will be made illegal or won't be "better enough" than alternatives to catch on or will overtaken by something even better or will have its peer-to-peer network overwhelmed with jerks mounting denial-of-service-attacks or will crash and burn for some reason I haven't thought of yet).

The "URL shortener" for stock Bitcoin would need to be a plug-in, where you give it one or more websites that provide URL shortening services (to get bitcoin addresses for email addresses or phone numbers or social security numbers (ok, SS#'s would be a bad idea)).  I don't think stock Bitcoin should or could do that, because that service means maintaining a centralized database, and trusting whoever runs that database not to suddenly, one day, decide to redirect all the bitcoins to themself and then retire to Bermuda.  (or trust them not to get hacked so hackers get all those coffee-shop payments...)

That'd be another good, standalone project for a good C++ programmer who wanted to do some Bitcoin-related programming...

I think the next big step for Bitcoin is a "lightweight client" that doesn't rely on a constant connection to the Bitcoin network, doesn't store the entire block chain, and doesn't try to generate blocks.

It is 100% open source.  Bitcoin relies on three other open source projects-- wxWidgets (for the user interface), Boost (for geeky C++ stuff), and OpenSSL (for cryptographic stuff).  Those are all also 100% open source.

Improving The Fine Manual (and the website) will be an ongoing project; thanks for your questions. I agree that there is a lot of work to be done on the documentation front.  Like most open source projects, most of us developers find writing code more fun than writing documentation or marketing material.


Satoshi is the main developer and person most in control of bitcoin (as said above).  I've been the second-most active developer over the last month or so.

PS:  if you have the time and feel like helping out... most of the documentation is in the Wiki, which anybody can edit.  And constructive, specific suggestions for making the main bitcoin.org web page better are welcome, too.