How to avoid negative account balance due to fee?

[bananas]

Supposing an app(running btc daemon) where the user can withdraw all the funds from his account(sendfrom comand). When the suer withdraw 100% of his balance it may go negative due to the transaction fee, and such fee will be taken from the main account. How could i avoid that? I can't predict the fee if any as far as i know? What is the solution?

[jl2012]

Bitcoin won't allow negative balance anyway

[Bitalo_Maciej]

You CAN predict the fee, and YOU are in control of setting it. The algorithm is pretty simple (at this moment, it will change in next versions):

Code:

ceil((TX_SIZE_IN_BYTES) / 1000) * 0.0001

So for 250 bytes you pay 250 / 1000 * 0.0001 = 0.0001 BTC.
For 3200 bytes you pay 0.0004 BTC.
Etc.

If the amount to send + calculated fee is bigger then the balance, you have to subtract the fee from the amount itself, so you will send less to cover up for the fee.

[donsanto]

It is impossible to have a negative balance. The bitcoin protocol does not allow it.

[bananas]

It is impossible to have a negative balance. The bitcoin protocol does not allow it.

Are you sure? I mean on an individual account, not on the wallet toal. Here it gets negative.

[bananas]

You CAN predict the fee, and YOU are in control of setting it. The algorithm is pretty simple (at this moment, it will change in next versions):

Code:

ceil((TX_SIZE_IN_BYTES) / 1000) * 0.0001

So for 250 bytes you pay 250 / 1000 * 0.0001 = 0.0001 BTC.
For 3200 bytes you pay 0.0004 BTC.
Etc.

If the amount to send + calculated fee is bigger then the balance, you have to subtract the fee from the amount itself, so you will send less to cover up for the fee.

Thanks, but now i don't know how i will predict the tx size?

My withdraw code is just:

$is_valid = $api->call('sendfrom',$account,$address,$btc,6);


Is not there a way to just tell the wallet daemon to not allow negative balances? thanks

[Bitalo_Maciej]

Please don't use bitcoind accounts for that purpose. They weren't meant for this, and you will start to get bugs. I'm not sure what exactly happens when you try to send whole balance of one account to somewhere else. Either it will fail with an error message, or it will take the fee from the amount as I said (unlikely, I think), or - which is a disaster in your case, it will take the fee from another unspent output without you knowing it until it hits you.

[bananas]

Please don't use bitcoind accounts for that purpose. They weren't meant for this, and you will start to get bugs. I'm not sure what exactly happens when you try to send whole balance of one account to somewhere else. Either it will fail with an error message, or it will take the fee from the amount as I said (unlikely, I think), or - which is a disaster in your case, it will take the fee from another unspent output without you knowing it until it hits you.

What bugs?

It takes the fee from the account but when you send the whole  account balance it gets negative due to the fee and send the fee from the main(my own) account (which was my issue).

But suppose i make my own account system as you suggested, i will have the same issue. I still have to know the fee before sending any funds or it will be taken from me.

- user has funds to send X
- X + FEE is larger than user funds
- user sends X
- the system will send X + FEE anyway cause my wallet has enough funds

I need to take X + FEE from the user, and avoid sending it if the total is larger than his funds.

[Bitalo_Maciej]

Actually, there is a way to calculate the length of the transaction before sending it:

Code:

10 + (148 * I) + (34 * O) + I

Where I is the number of inputs, O is the number of outputs in the transaction. This assumes that all inputs are spending normal "pay to address" outputs, and all the outputs are normal "pay to address" outputs as well.

[bananas]

Actually, there is a way to calculate the length of the transaction before sending it:

Code:

10 + (148 * I) + (34 * O) + I

Where I is the number of inputs, O is the number of outputs in the transaction. This assumes that all inputs are spending normal "pay to address" outputs, and all the outputs are normal "pay to address" outputs as well.

How do i know the number of inputs ?