I updated mine too (several times) - guess we are starting to confuse each other.

I do understand the point that an account has to belong to yourself so will just repeat what I think might be more intuitive.

If I do a "setaccount" to an address that is not my own why couldn't it just put this account on the address(es) that the send had come from?

I guess the fix is a documentation one then - sorry for the misunderstanding.

I do think it is rather unintuitive but thanks for the explanation and the link (just read it).

Perhaps it could make sense that a "setaccount" to an external address instead sets the account on the internal address(es) that the funds came from?

Also after reading the link am not 100% sure about it but would I be correct in saying that I'd have to do a "move" to get the "account" to change for a "send"?

As stated if I do a "listtransactions" the account field is always "" for every send even though (either through the GUI or bitcoind) I later set an account on the send addresses.

If I do a "getaccount" it *does* return the (to my way of thinking) correct string but never does it appear in "listtransactions".

To repeat just do something like the following:

bitcoind -rpcpassword=xxx listtransactions "*" 1000

and look at the account field for every "send" tx. In the version that I am using (0.4.0) for any "send" tx that address will always be "" no matter what you do.

Well if not buggy then why does "getaccount" give me a different result than "listtransactions" (are there more than one type of account in Bitcoin)?

Ouch - was thinking that I must have done something wrong rather than finding bugs in the very first RPC command I tested.

Interestingly the problem only seems to occur for the "sent" tx's as I do see all the account names for the "receive" tx's fine (so perhaps a fix for at least this part may not be to hard).

Hmm... why not go to another bank then?

I have just started playing with bitcoind (under Windoze using the 0.4.0 and running the GUI as the server) and noticed that when I did a "listtransactions" an entry like this:

...
{
    "account" : "",
    "address" : "1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6",
    "category" : "send",
    "amount" : -0.50000000,
    "fee" : 0.00000000,
    "confirmations" : 1234,
    "txid" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "time" : 1213411747
},
...

I wanted to put an account on the 1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6 address so I initially did this via the GUI (which shows up in the Address book fine) but it just stayed blank in the listtransactions output when I re-ran the command.

So I then ran the following:

bitcoind setaccount 1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6 name

and it created a new address (documented behavior if the account name is the same as it already has I read) so why can't I see the account when I do listtransactions?

Strangely enough if I run this:

bitcoind getaccount 1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6

then it returns "name" is one would expect.

I see - thanks for the info - well at 1 hr and 8 mins we don't have a new record then (which I am glad about as am currently awaiting # of confirmations to trade).

Waiting now for 1 hour for this block to be generated (according to http://blockchain.info as well as what I observed looking at http://blockexplorer.com).

Is this kind of wait common (as I hadn't noticed it before)?

Great - thanks for that (I assumed it should be the case but is much better to get some confirmation).

Just wondering about the wallet encryption and persistence when bitcoin-qt is started without a wallet (as in a new installation).

What I am wondering is whether "wallet.dat" gets persisted (with exclusive file access locking) with the private keys unencrypted before you actually enter the passphrase to encrypt or is the wallet information just held in memory until you shutdown the client?

Will send you a PM shortly.

Hopefully for your sakes it is not another frozen bank account issue.

This happened to me (a case of bad timing) and ANZ (their bank at that time) never returned my funds.

This has been discussed before and is really only a client-side display issue.

If BTC becomes much more valuable than it is now then the clients could be changed to start displaying values as mBTC (being .001 BTC?) or something similar so the end user won't need to see a bunch of leading zeroes.


Cheers,

Ian.

Yes - I just had the Tuk Tuk experience in Bangkok again recently (last time I did this was around 20 years ago and it hasn't changed). Got taken to at least four different shops with the last one being a travel agency (so no products to look at just a desk to be sat at with a high pressure salesman on the other side).

Mind you there are some bargains to be had in Beijing (although the Silk Market is not really a good place to look for them) and also we can arrange purchases via Taobao (the Chinese equivalent of eBay) provided the goods can be delivered whilst you are over here (generally deliveries are 2-3 days). I very much doubt any other tour will offer people this service.

Also for people on a budget we are very familiar with using the subway (best value in the world at 2 RMB to go anywhere on it 1 way), buses (often less than 0.5 RMB by using an IC card which we will provide you with upon arrival) and even know of the best value hostels (as we have some friends that regularly stay at them).


Cheers,

Ian.

Thank you very much for the translation.

Any Bitcoin tourists out there?

After recently acting as tour guides for family members before our wedding, my wife and I have decided to offer via this forum the opportunity for anyone interested in visiting Beijing to be able to pay for their entire trip (apart from air tickets) in Bitcoin (RMB conversion rates to be taken from btcchina).

We are not going to organise trips for large groups (maximum of six people) so we can provide flexible arrangements and avoid the need for hiring large buses.

We are not affiliated with any tourism company and will take people only to places that they are interested to visit (itinerary suggestions will be provided upon request). In particular you will not be taken to any shops unless you have asked to go there (this can be a big problem with budget tours in China).

The initial Bitcoin payment won't be necessary until arrival (we will meet you at the airport) and payment for each tour day can be made at the end of the day. We will provide receipts for all transportation, accommodation, tickets and meals and will charge a modest fee (around 5 BTC per day) for our services.

We have not yet set up a web site for this endeavor as we are just putting this out to test the water and to offer people another way to actually spend their Bitcoins.

For further information either reply here or PM me.


Cheers,

Ian.

As I've stated before for every registered voter there is a tx for them to spend (their vote) and every receipt (which holds the vote in plain text) is a tx of the same amount (their vote again - but cannot be linked to the initial one except by the UUID known to the user).

Anyone can count them - just not while they are encrypted (if you don't encrypt them then users, organizers or parties could collude to screw the whole thing up).

Encrypting the ballots is not a problem though because if the organizers/parties cheat then either the balances will not zero sum (which all other parties will also know) and/or the UUIDs will not match (which each user can verify their own vote was correctly processed).

Well I only mentioned a tool rather than what to do with it actually - the advice I would have given (if he was interested in the tool at all) would be to hardlink to the large file rather than to a directory and I *know* Bitcoin works with that because that is how I use it.

Okay - nearly there.

1) The UUID would be encrypted along with the rest of the ballot so the user submitting your vote cannot see it. This number will only be known to the organizer/parties and to yourself (with the organizer/parties not having any way to trace that number to the voter as it is only used by the voter to later find their vote - in fact after verifying your vote receipt you can destroy that UUID so no-one can determine who you voted for later on).

2) Yes the votes are encrypted so that only the organizer/parties (which would be all parties not just the one you are voting for) know initially who you voted for. It is the receipt tx that then contains the same vote in plain text along with the UUID.

So the votes do end up being public and unencrypted and each voter can verify their own vote (you just can't verfiy other users vote unless they want to tell you there UUID). Also the total BTC/VTC of receipts should equal the total BTC/VTC that was sent out to registered voters who voted (am not really considering non-voters as I think an automatic dummy vote could accomplish that).

The point of the ballot (and UUID) encryption is to prevent the users colluding with each other to try and cheat the system. The workflow I showed earlier basically says that you don't qualify to have your own vote submitted until you have submitted a vote for someone else. The idea being that it is in your interest to help out with making the ballots anonymous.