Have you read https://en.bitcoin.it/wiki/Contracts ?

There are several examples using nLockTime, which is not as powerful as what you describe, but it is implemented and can be used to provide some time dependency.

The slow part is not downloading the blockchain, it's verifying it and building a transaction index for it (the blkindex.dat file).

You can download a premade blockchain + index, but that implies a certain amount of trust in the supplier of the files, as they are not verified as thoroughly that way.

Unfortunately, no. There have been a rather large number of bugfixes since 0.6.0rc1 however, and 0.6.0rc2 will be created very soon. I hope this problem is fixed by now.

Good point, I don't recall updating the account info when importing. I'll try to do that still before 0.6.0's release.


Yes, that's a known issue, see the issue page. I'm not familiar with the GUI code, however.

In order to avoid confusion, I'd rather add an extra optional parameter "tolabel", separate from the "account" parameter already present. You really do not want people to confuse accounts and addresses any further (which apparently happened to you).

If the wallet was created with bitcoin-qt (even offline), you would not need -rescan when loading it into another client. The transaction would only show up as soon as the client caught up with the block chain, though. Sure that wasn't the reason it didn't show up without -rescan?

No, the *account* they were sent from. Accounts and addresses have nothing to do with eachother, and bitcoin transactions do not have a well-defined "from" address.

Neither BIP16/BIP17 have anything to do with block construction, blocks are not signed, and coins/transactions are not mined. What you choose to mine your blocks with is your own, but certain alternative chains may be optimized for FPGA's or not. Furthermore, what your greencoin branch of bitcoins do or do not, is up to you.

Any reason in particular for using such an old client? In particular, versions before 0.3.24 had a bug that prevents them from efficiently distributing the block chain to other nodes.

You may be interested in pull requests 841 and/or 886, which add such functionality to the reference client.

I must admit that I agree with gmaxwell here on the topic of green addresses: they use the block chain as a communication channel for what is essentially private information. Nonetheless, seeing block's and transaction's full contents is sometimes useful.

I finally understand what you're asking. You do not want accounts at all, you just want labels attached to addresses, and the ability to search for them.

I suppose that isn't too hard, and sounds useful indeed.

May I ask what you are trying to do (the big picture, not "put send addresses in an account")?

The account feature is for keeping separate balances, for example for an e-wallet website that wishes to keep a balance for each customer (an "account"), and receive and send funds for them.

I understand.


A move allows you to virtually move funds from one account to another. It will not change which account a particular send debits. That is something you choose when doing the transaction.


Bitcoin transactions do not have a from address (they can have multiple, or none at all, as they combine previously received funds), and accounts have nothing to do with the addresses in actual transactions. They are only for internal bookkeeping.

You mean: if a send address A is associated with an account X, then transactions to A will by default debit X, and this behaviour can be changed retroactively using setaccount?

That sounds possible, but to be honest, I fear it will confuse even more people.

My graphs are still up.

I updated my post above again.

I'm not sure I see what you mean with "two types of accounts". An account is group of receiving addresses for which a balance of what is received using them is kept. The confusing probably comes from the fact that a) setaccount doesn't complain when adding an address that is not your own and b) labels in the GUI are mapped to accounts.
Still, accounts for sending addresses don't really make sense: if your address is in my "ciyam" account, and I send money to you, would that debit or credit "ciyam"?

I'll try to explain it in another way:
* each receive transaction will credit one account, namely the account associated with the address it was received on.
* each send transaction will debit one account, namely the one specified using "sendfrom", or the default account ("") if the transaction was done using the GUI or sendtoaddress.
* move actions debit one account and credit another account.

Also note that accounts have nothing to do with the actual coins used in the bitcoin transactions involved.

EDIT: reformulated

Accounts are groups of addresses which automatically credit a named balance when transactions are received using them. If you use "setaccount" for an address that is not your own, there is no effect, nothing will ever be received using them.

The "account" field for sent transactions refers to the account a transaction was sent from, not to (that wouldn't make sense, as you can send to addresses that are not your own). The only way to influence that is using the RPC command "sendfrom", which allows changing the "from account" information.

There is somewhat more information here

Can you show me exactly which output you get, and why it is inconsistent? If it's really wrong, you stumbled upon a bug we'll gladly fix.

Accounts are only affected by:
* incoming transactions to their bound addresses
* sendfrom
* move

Changing what account an address belongs to, does not change former transactions' to-account field.

The account system may be very unintuitive, but I wouldn't consider it buggy.