Account negative balance

[bananas2]

I'm writing a multi-user app based on the account feature. I cannot allow a negative balance in any account, but it often happens even if i check the balance before allowing the user to send funds 'cause the transaction fee is added to the value being sent.

How do i work around that? Can't i set bitcoind to not allow negative balances?

Thank you

[laanwj]

The plan is to remove account functionality in the next major release.

If you want to keep balances for users, implement the necessary database logic yourself. Use bitcoind only to watch the network for transactions. Maintaining 3rd-party deposits is beyond the scope of the reference client.

You will also encourage more accurate wallet address accounting instead of
having the client do that behind the scenes through the account grouping I
like this especially for new adopters so they setup their transactions
correctly. +1
On Mar 7, 2014 1:49 AM, "Wladimir J. van der Laan" notifications@github.com
wrote:

The plan is to remove account functionality in the next major release.

If you want to keep balances for users, implement the necessary database
logic yourself. Use bitcoind only to watch the network for transactions.
Maintaining 3rd-party deposits is beyond the scope of the reference client.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3810#issuecomment-36972147
.

[bananas2]

Thanks, i will do that. Anyway even with my own accounting system i don't know how i could prevent the user of sending more than its funds as the transaction fee is added after the send command. The problem remains the same to me.

The JSON RPC will reject the transaction if the funds at the input address
are insufficient to cover the requested amount and including required fees.
You shouldn't need any special handling for that even current state. If
somebody wants to totally exhaust the last little bit of dust just use a
small fixed fee for those as special cases. Will that work?

On Fri, Mar 7, 2014 at 2:08 AM, bananas2 notifications@github.com wrote:

Thanks, i will do that. Anyway even with my own accounting system i don't
know how i could prevent the user of sending more than its funds as the
transaction fee is added after the send command. The problem remains the
same to me.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3810#issuecomment-36972987
.

[bananas2]

In this application the user will be often sending his full funds, in this case the RPC does not reject an account transaction if it does not have enough funds for the fee as far as the wallet do. If i code my own accounting, i would have exactly the same issue. The Bitcoin clients let you cancel a transaction if you do not agree with the transaction fee, why i can't do the same via RPC? Or is that just an estimate calculated by the client(similar to your suggestion of a fixed fee), not the actual transaction fee? If it is not the actual fee it is something i believe must be changed in the code, the user must know exactly the cost of his transaction before sending it.

Honestly to keep everyone's life simple I would enforce a "minimum tx fee"
for full address liquidation in your implementation. Where you may pay
slightly more in tx fees you make up for it on simplified implementation
details. The concept of fees is a moving target as market prices fluctuate
and is driven by a lot of inputs including how frequently you are hitting
the block chain. I'm not aware of any more scientific way to do this, so
hopefully somebody else can chime in and provide more insights.

On Fri, Mar 7, 2014 at 10:19 AM, bananas2 notifications@github.com wrote:

In this application the user will be often sending his full funds, in this
case the RPC does not reject an account transaction if it does not have
enough funds as far as the wallet got enough. If i code my own accounting,
i would have exactly the same issue. The Bitcoin clients lets you cancel a
transaction if you do not agree with the transaction fee, why i can't do
the same via RPC? Or is that just an estimate calculated by the
client(similar to your suggestion of a fixed fee), not the actual
transaction fee? If it is not the actual fee it is something i believe must
be changed in the code, the user must know exactly the cost of his
transaction before sending it.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3810#issuecomment-37033095
.

[gavinandresen]

Neither bitcoind nor Bitcoin-Qt wallets are appropriate for multi-user use.

They certainly have been used for that, but the companies that did that decided (for whatever reason) not to help debug/test/optimize/etc. that use. Part of that would perhaps be a better solution for transaction fees.

You should not be charging user A for transaction fees because user B decided to fill up the wallet with lots of tiny transactions. And that is exactly what would happen if you tried to charge users for the transactions that go OUT of the wallet (because the bitcoind wallet considers everybody's unspent outputs when creating transactions).

So, best practice is to either just consider transaction fees a cost of doing business and pay them out of your profits, or charge a fixed fee for every outgoing transaction and charging "too much" for some transactions and "too little" for others.

For ClearCoin, I created a "FEES" account, funded it with some coins, and then when transactions were sent I would move balances from escrow accounts to or from the FEES account when a transaction was sent (sendtransaction, then gettransaction to get the fees paid, then move, if necessary, so the account balance was correct).

[bananas2]

Thanks for the inputs.
Is there an appropriate multi user alternative to bitcoind? Well, i will have to use it if not.
Does "settxfee" guarantee that the fee will always be whatever i set it to?

[gavinandresen]

Appropriate multi-user alternative to bitcoind: I don't know. I won't recommend code that I haven't used or code-reviewed myself.

Does settxfee guarantee: No, because settxfee is "pay this much fee per kilobyte in transaction size" and transaction size depends on number of inputs (which you cannot predict, unless you construct the transaction yourself using the raw transaction API) and number of outputs (which is typically either 1 or 2, depending on whether or not a change output is created).

[bardiharborow]

Someone really needs to build a open-source deposit tracking system for Bitcoin. The only hard bit about that is bitcoind doesn't let you access transactions of non-account addresses. Is there a way we can change/add RPC commands so that bitcoind has more block explorer type functionality? Maybe a gettxsforaddress command? This wouldn't have to be enabled by default, we could have a txindex=1 type of option. Any thoughts? When I can run bitcoin-abe without having a separate block database I will be very happy. =)

[sipa]

That would require indexing all transactions by address, which is another order of magnitude heavier than -txindex already. And it's totally unnecessary for just a deposit tracking system... existing wallets can do that just fine (perhaps watch-only ones)... it's just the accounting layer on top that's missing.

[bardiharborow]

@sipa Well then we need make more progress with watch-only addresses, don't we.