Bitcoin Forum

(as posted on SE (http://bitcoin.stackexchange.com/questions/5607/api-keeping-account-balance-positive-knowing-in-advance-the-transaction-fee))

I'm using the json API (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list). I need to keep all the account balances positive: I call getbalance first, check if it has enough bitcoins to proceed, and then move or sendfrom.

This approach causes two problems.

Problem 1 is that this is not an atomic operation, so after the first getbalance the balance could actually be changed.

Problem 2 only happens with sendfrom: there might be a transaction fee, hence if the user sends his entire balance, he'll have a negative balance due to that.

Solution to Problem 2 would be to know in advance the transaction fee: I noticed (though I didn't try) I can set it with settxfee, but I found no call to get it, is there?

While I could implement some external lock mechanism to solve Problem 1, I'd rather use a bitcoind native method, though I get it does not exist, does it? Hacking the sendfrom function to have it check the balance before sending would be enough, I guess?

No, the transaction will fail if a tx fee causes the account to go negative

I'm sure it is impossible to get a negative ballance

No, the account balance will go negative, I just tried.
We're talking about accounts (https://en.bitcoin.it/wiki/Accounts_explained) here.
They do go negative.

Last time I tried it did not work that way, but maybe you're trying with the default account, which is allowed to go negatvie.

no:

You're doing a "move" which is not the same thing as a "sendtoaddress".

Again, last time I checked transaction fees could not lead a non-default account into negative.

I'm not saying it has not changed, I am giving you the result of my experience.

Last time I checked "move"s between accounts would silently round the amounts to two decimal places, but it has been fixed since then.

The only way to know for sure is to test on the latest versions :)

sendfrom() makes balances go negative by the fee amount if someone withdraws all coins.

yeah that is exactly my "problem 2", thanks for understanding that.
I've reported it as a bug (https://github.com/bitcoin/bitcoin/issues/2079), hoping they do consider it a bug.

@davout: yeah, I'm doing a move there. It is "problem 1", listed in the opening post.
I've fixed it hacking bitcoind code (https://github.com/Lohoris/bitcoin/commit/4442224ee497260de6800fd09d6c2af993a046ac), though.

If it's as you say it is indeed a bug that needs to be fixed.
If I was you I would simply not use the accounting feature.
It just doesn't scale well.

Yeah, but that feature is exactly what I need to build a website... I mean, I would have to re-implement it from scratch anyway, so I'd rather not re-invent the wheel...

Nobody except me and Lohoris working with the accounts feature?

Maybe it doesnt scale too well for sites as big as davout`s sites, but wouldnt that just be a problem of the current 0.7 implementation?
I mean the feature itself is great and if it gets some attention from developers it could scale well in the future, or am i missing something which totally sucks about accounts anyway?

Because installing a database myself and implementing exactly the same on my own would really look like reinventing the weel for me...

Why doesnt some bigger site instead of writing their own code contrubute better code to the bitcoin client?
(that question goes a bit to people like you davout)

It was what made Instawallet absolutely unusably slow in the beginning of 2012.

I used to use it for Bitcoin-Central as a second layer of accounting, but at some point I realized discrepancies, which were due to the silent rounding.

Anyway, I don't mind this feature, but I think it's going to be really great when bitcoind uses a relational database that you can query directly.