Excessive, lazy quoting (like this message!) should also be discouraged.

I wrote this three years ago, and I'd still like to see something like it implemented.  Now we've got Bitcoin, implementing it might be much easier; I'd love to see a bitcoin bbs/forum that uses these ideas to reward thoughtful, high-quality discussion  (replace "email list" everywhere below with "discussion forum" and I think it all still works):

---

I was listening to "The Ethics of Liberty" yesterday, and it got me thinking about email lists.

Most email discussion lists seem to suffer from a Tragedy of the Commons-- there's not a whole lot of motivation for people posting their opinions to think twice about spouting off, or going on and on and on, or otherwise polluting the list with stuff that the subscribers to the list might consider junk.

There are a couple of solutions to these kinds of problems. You can try to set up some kind of policing system, with trusted moderators given the power to bless posts, ban people, etc. You need really thick-skinned, generous-hearted, even-tempered moderators for that to work.

A solution that works in the real world that hasn't been tried for the email mailing list problem (as far as I know) is some kind of economic system, where the common resource is given a value and anybody wanting to use the resource must pay rent (which is then used to maintain the resource).

So, here's a thumbnail sketch of how this might work for an email mailing list:

Create an artificial currency. If you have enough of this currency, you're allowed to post messages to the list. Longer posts cost more than shorter posts.

Everybody starts with some amount of this currency. Everybody is allowed to use it themselves, give it away, or sell it (for real money!) to people who want to use it to post messages.

Every message posted includes ways of:
- Tagging the message as "Worthwhile" --> transfers currency from your account to the poster's account.
- Tagging the message as "Waste of my Time" --> transfers currency from poster's account to the common pool of currency.

The amount of currency in the system is tied to the desired message traffic. We all have a limited attention span; basically, the trick will be to create an artificial economy so that the people who contribute positively are encouraged to contribute more, and people who "pollute" are punished.

Currency goes into the system every day (again, based on desired message traffic per day). Some is assigned to new people signing up for the list, and the rest evenly distributed to everybody already on the list.

"Lurkers" on the list could either hoard their currency, offer to sell it, or give it away to people from whom they want to hear more.

Y2K was a non-event exactly because it was predictable and so lots of people did lots of work to make sure nothing terribly bad happened.

My point is only that the block #210,000 switchover will, I think, be exactly the same.  An entirely predictable event that people will plan and prepare for.  It will be a significant event only for the very small minority of people who have to do the planning and preparing.

RE: complacency:  I think we're a lot better at getting complacent about random events (like earthquakes and hurricanes) than "this is absolutely 100% certain to happen on or around this date" events.

You can continue to use accounts as labels, create an each-address-gets-one-label, and map addresses-->user in your database.

However, your application will be faster and simpler if you let bitcoin do the addresses-->user mapping (one account per user), and store address-->user-specified-label in your database.

The bitcoin 'getaddressesbyaccount' method will give you the addresses-->user relationship, and all the accounting becomes much easier (listtransactions gets you all the transactions associated with a particular user, etc).


The label methods still work, call the corresponding account methods (e.g. call setlabel <bitcoinaddress> and it calls setaccount), but are deprecated, so they don't show up in the help and will eventually be removed.

The only 'potentially breaking change' is the sendtoaddress function, which now returns a transaction id instead of the word 'sent'.

I just browsed back through the git commit history, and I don't see any interim commits of the account code (I was working in local branches, and didn't push interim versions up).

davout: You should try dumping your wallet using the latest bitcointools (dbdump.py --wallet), it will tell you if it finds weird key values in there.

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.