The "accounts" feature (to replace "labels") is done for now:  listtransactions and gettransaction are implemented, and move, sendfrom, and getbalance <account> are enabled.

This should make implementing web services much easier; you can assign each customer their own 'account' and rely on bitcoin to keep track of exactly how many bitcoins they have, have it return a list of the customer's last N transactions, etc.

This is a minimal implementation on purpose-- for example, gettransaction doesn't return every possible bit of information you might want to know about a transaction, and will only return information for transactions in your own wallet.  We are trying to think ahead and not add features that will be broken or taken away when bitcoin supports running in a 'lightweight client' mode, without access to the entire bitcoin transaction history.

I've updated the API wiki page with the new methods.

I agree with FreeMoney.

I think that as long as the generation reward is predictable there will be essentially no problems; people are smart, and will plan ahead.  I predict the 100 blocks after the generation reward gets cut to 25BTC will be generated in the same time as the 100 block generated before the reward cut, within, oh (pulling a number out of my ear) 20% plus or minus.

I'm reminded of the Y2K hype back in 2000; that was a predictable event that turned out to be a non-event.

... and the person you hand the keys to will have to trust that you didn't keep a copy of them (or if you did, that you won't spend them before they do).

I grabbed the "Digital Coin Technology" pdf file.

It looks to me like it fails in the second paragraph:

If the DigitalCoin software can read the serial number, then so can other software.  It is simply not true that "The DigitalCoin software alone can ..."

Either you have a central server running the DigitalCoin software and you have to trust that the people running that server won't double-spend DigitalCoins.

Or... you have Bitcoin, where the "serial numbers" are the public keys of coin generation transactions.

From the previous thread:

Implementing something that won't even work on our own forums would be a bad idea, in my humble opinion.

I haven't tested my 'master' bitcoin-git branch in a while, I wouldn't be surprised if the new 'accounts' code in the subversion tree broke something.

Which not-in-subversion features are you using?

I saw a version of this at a presentation of a local "time dollars" group... and I think their arguments go wrong at a couple of places.

First, wealth creation is limitless (we continue inventing more efficient ways of doing things and new things to spend our time and money on), so it's simply not true that an ever-increasing money supply (created via debt) is unsustainable.  If there was some way of pegging the creation of the 'right' amount of money to the overall amount of wealth being created, then we'd get stable prices and the 'right' level of investment.

And second, the argument is that the system is stacked against the borrower-- that it is designed so that there's never enough money for everybody to pay off their debts.  So if I WANT to pay back my debt, I'll find out there's a money shortage, and I won't be able to.

That ignores the fact that I can walk away from my debts via bankruptcy.  And the fact that many loans are secured with some form of collateral, which lenders accept in lieu of cash.  Borrowing/lending is not an entirely closed system, and, ideally, lenders have to be smart and fund borrowers who are creating real wealth.

So... 8 years ago some bittorrent folks came up with the magnet: URI scheme.
And yet I don't run across many magnet links as I browse the web.

As I browse the web I run into exactly three URI schemes:  http, https, and mailto.

I think a bitcoin mime type will be easier to implement and is likely to be more successful.

MrFlibble:  "Fair" is one set of coins (however many the Faucet is giving out at the time-- hopefully, bitcoins will continue to become more valuable, and I'll give out fewer over time...) per person.

I like the postcard idea, although I'm not willing to type in bitcoin addresses written on postcards!

Hmm... any stamp collectors here?  Paying people bitcoins to send you postcards (with stamps on them) might be really fun...

And re: using OpenID instead of a Google Account:  that'd be easy to implement, but way too easy for cheaters (who can just be their own OpenID provider and give themselves as many OpenIDs as they want).

Designing and implementing user-friendly wallet backup for the GUI bitcoin seems like it would be a great little project for somebody who knows C++ and knows, or is willing to learn, wxWidgets programming.  The non-GUI code already has the 'backupwallet' RPC method, and 'getinfo' will tell you the age of the oldest key in your keypool.

For extra credit, the code could keep track of the last successful backup and warn you that it is time to backup again when the keypool age gets close to the last backup time.

What error did you get, farmer_boy?  The only errors I see in the server's logs are "rate limit" errors.

The Faucet tries hard to prevent people from cheating and using it more than once; unfortunately, that means if somebody who "looks like you" uses the Faucet before you, you might be prevented from getting your coins.   If that happens, try again a day later.

I've been thinking about implementing a two-tiered Faucet:  one that gives out a smaller number of coins and just requires you solve the CAPTCHA (and has all the current anti-cheating measures in place; there are one or two people still people cheating, but they're only able to get a few bit-pennies an hour, and they're going through an amazing amount of trouble to do it).

And another that gives out a larger number of coins if you login with a valid Google account.   Getting tens or hundreds of Google accounts is harder than solving CAPTCHAS.

But if I did do that... I'd get accused of implementing the Faucet as a sneaky way of stealing Google account email addresses.

Sigh.

As a veteran of the premature standardization trenches (I wrote most of the ISO/IEC 14772-1 "VRML97" specification before I changed my last name from "Bell" to "Andresen")... I agree with foreverdamaged.  It is too early to try to create a formal specification.

However, it think writing informal specifications documenting how bitcoin works right now is a great idea, and will be really helpful when it is time to go through some standardization process.

There never was a way to place labels on a per-transaction basis.  It was always a one-label-to-multiple-bitcoin-addresses association.

But all of the old label functionality is still there, just renamed.  You should be able to do anything you were doing before.

However, you might think you were doing something that you weren't actually doing.  There was no way to label/name particular transactions before (just addresses).

RE: the empty string as the default account:   None of this is (or will be) visible to GUI users, and if you're a programmer using the JSON or the command-line interface SURELY you know how to quote strings.

RE: hierarchical wallet keys:  Huh?  If you want trivial searching and grouping... then export the info into a database and use SQL.

The "" (empty-string-named) account is allowed to have a negative balance.  You can sendtoaddress as long as the entire wallet has enough coins.

Accounts (like labels before them) are just a useful accounting mechanism.  The rest of the network doesn't know or care what accounts you have.  And although transactions to and from the wallet are credited or debited to accounts, all of the 'coins' get mixed together in the wallet, there is no notion of "this account received 100 bitcoins in this transaction, so we should use those for that transaction out..."

For example:

100 bitcoins are sent to an address associated with Account A.  A's balance is now +100.
50 bitcoins are sent to an address associated with B.  B's balance is now +50.
100 are moved from A to B. A has zero, B has 150.

B is allowed to send 150, but it won't necessarily be the 100 originally sent to A and the 50 sent to B; if other accounts have received coins (transactions), those might be sent instead.


bitcoin doesn't care (use any valid JSON string for the name), and the rest of the network doesn't care, so use account names that make sense for your application.

The send methods don't try to be clever; they always broadcast transactions.

If you want that behavior, be clever yourself:  call  getaccount <bitcoinaddress>  before calling send, and then call move instead of send* if you find out the bitcoinaddress is one of yours.

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.