Could we have an "send all funds to" option?

[CIYAM]

Was thinking about "emptying" my wallet (for better anonymity) and although not that tricky is a slight pain to have to do pull up a "calculator" to work out the exact amount to send when taking into account the tx fee (assuming it would be > than the minimum due to cleaning out the "lint" of small unspent outputs).

Perhaps it might be worth adding a "Send All Funds To" check box to the "Send coins" tab so that the amount to send (minus the required fee) can just be worked out automatically for the end-user?

[Blazr]

Probably off-topic in a way but this is how I usually do this.

What I usually do is export all the privkeys and import them to MtGox. They'll automatically sweep all the funds out.

This has the added benefit of, in the offchance somebody accidently sends BTC to an address from my old wallet someday in the future, MtGox will automatically sweep the funds into my account.

[CIYAM]

Not a bad technique - of course I won't be throwing out any private keys (just effectively sweeping them all out to a new address) but I would think that if it's not too hard for the software to do this for the end user (who could be Gavin's Grandma after all) then why not have it do the work for them?

[flower1024]

Not a bad technique - of course I won't be throwing out any private keys (just effectively sweeping them all out to a new address) but I would think that if it's not too hard for the software to do this for the end user (who could be Gavin's Grandma after all) then why not have it do the work for them?

its not that easy because fee calculation is not deterministic.
i've tried to that manually but i think importing the privkeys to mtgox is the easiest solution.

[CIYAM]

its not that easy because fee calculation is not deterministic.

Really - I thought it was?

This https://en.bitcoin.it/wiki/Transaction_fees#Rules_for_calculating_minimum_fees is wrong then?

[flower1024]

its not that easy because fee calculation is not deterministic.

Really - I thought it was?

This https://en.bitcoin.it/wiki/Transaction_fees#Rules_for_calculating_minimum_fees is wrong then?

it depends which coins are selected - which appears to be random sometimes.

as i tried to empty my wallet i had this case (example with easier numbers):
1BTC in wallet
 - 0.995BTC to send fee was 0.001
 - 0.999BTC to send: fee suddenly was 0.005

so it was impossible to empty my wallet (i got around this by using to txn's)
so i had a problem ,)

[CIYAM]

it depends which coins are selected - which appears to be random sometimes.

If I am "emptying" the wallet then how can it depend upon "which coins" (I presume you mean "unspent outputs") as I am spending them *all* (and I don't believe it matters *which* one is used to provide the tx fee)?

(perhaps you weren't completely emptying your wallet?)

[flower1024]

it depends which coins are selected - which appears to be random sometimes.

If I am "emptying" the wallet then how can it depend upon "which coins" (I presume you mean "unspent outputs") as I am spending them *all*?

(perhaps you weren't completely emptying your wallet?)

because the fee does also use unspent outputs.

[CIYAM]

because the fee does also use unspent outputs.

Sorry edited after you replied - so it does matter which "unspent output" the fee is chosen from?

[flower1024]

because the fee does also use unspent outputs.

Sorry edited after you replied - so it does matter which "unspent output" the fee is chosen from?

only in case if you are emptying your wallet because this also implies that you send other outputs.
my example above is a little easier but a similiar problem.

 - 0.995BTC to send fee was 0.001
 - 0.999BTC to send: fee suddenly was 0.005
^^ here is the problem that the biger tx uses more (very small) outputs which results in a higher fee.

[CIYAM]

only in case if you are emptying your wallet because this also implies that you send other outputs.
my example above is a little easier but a similiar problem.

 - 0.995BTC to send fee was 0.001
 - 0.999BTC to send: fee suddenly was 0.005
^^ here is the problem that the biger tx uses more (very small) outputs which results in a higher fee.

Thanks for this - I hadn't actually thought about it much (clearly) so I can now understand this would not be easy at all.

Guess we won't be seeing this "feature" any time soon then.

[CIYAM]

However I just thought of this - if it *remembered* that last way it chose to do the tx (in terms of which unspent output to use for what including the fees) then provided that that fee paying unspent output has enough to cover all the fees it could solve it couldn't it?

[flower1024]

However I just thought of this - if it *remembered* that last way it chose to do the tx (in terms of which unspent output to use for the fees) then provided that that address has enough to cover all the fees it could solve it couldn't it?

imagine a wallet which contains ONLY of a few million transaction with a satoshi each.

[CIYAM]

imagine a wallet which contains ONLY of a few million transaction with a satoshi each.

Sure - nothing is going to help with that situation (i.e. no help for Satoshi Dice players).

[DannyHamilton]

it depends which coins are selected - which appears to be random sometimes.

If I am "emptying" the wallet then how can it depend upon "which coins" (I presume you mean "unspent outputs") as I am spending them *all*?

As long as your are emptying the wallet in a single transaction, as far as I can tell all unspent outputs will be spent as inputs, and there will only be one new output to the desired new address.  As long as you know how many outputs are in your wallet (which the client program should know), this shouldn't result in a variable fee.  It should be possible to calculate the size of all the inputs added together (as well as their cumulative age), then predict the size of a single output and determine what the fee needs to be.

because the fee does also use unspent outputs.

In this case the fee would simply be a reduction in the amount specified in the output.  All previous outputs would be used as inputs.

It should even be possible to determine if the fee can be reduced (and therefore the amount transferred to the new address increased) by leaving some extremely small outputs behind in the old wallet.

Perhaps a window stating something like:

Code:

Empty your 10 BTC wallet with a 0.02 BTC fee resulting in 9.98 BTC at the destination.
Leave 0.00005 BTC behind in the old wallet, empty the rest of it with a 0.0005 fee, resulting in a maximized 9.99945 at the destination.

Choose one, and click [Send Coins]

[etotheipi]

Armory has this feature.  Kinda.

Just send a regular transaction, and use the "MAX" button and try to send it.  If you need a higher fee, it will cancel and  fill in the correct fee for you.  Just hit the "MAX" button again, and it will recompute based on that correct fee, which won't change because it was already based on sending 100% of your coins.  You can now send successfully.

If you don't have enough fee to cover the sweep operation, Armory will let you know.  Basically "sorry, there's no way to sweep this wallet."  I still haven't figured out how I should gracefully handle that.

At one point I had a button for "Sweep Wallet", but I don't remember why I removed it.  I should add it again...

[Gavin Andresen]

With the current transaction fee rules, inputs of less than about 0.00005 BTC will cost more to spend than they are worth.

(somebody check my arithmetic, I'm good at dropping digits:  MIN_TX_FEE is 0.0005 BTC per kilobyte, an extra input is a signature+pubkey+a few extra bytes = 100 bytes, so minimum fee per input is about 0.00005 BTC)

Wallet software should probably display micro-inputs as zero to the user (they really are worthless right now, since they cost more to spend than they are worth) and ignore them when computing the wallet balance or getting inputs to spend.

[DannyHamilton]

With the current transaction fee rules, inputs of less than about 0.00005 BTC will cost more to spend than they are worth.

(somebody check my arithmetic, I'm good at dropping digits:  MIN_TX_FEE is 0.0005 BTC per kilobyte, an extra input is a signature+pubkey+a few extra bytes = 100 bytes, so minimum fee per input is about 0.00005 BTC)

Wallet software should probably display micro-inputs as zero to the user (they really are worthless right now, since they cost more to spend than they are worth) and ignore them when computing the wallet balance or getting inputs to spend.

Except that transactions that are smaller than 10 kilobytes do not currently require a fee.  So the user can probably create a transaction that contains nearly 100 inputs each at 0.00005 BTC.  That would be nearly 0.005 BTC worth of 0.00005 BTC inputs that would be spendable in any one transaction.

I'm not sure how the Bitcoin-Qt software goes about determining which inputs to use to create a transaction, but it might be nice if there were some sort of easily settable configuration where a user could choose to have it either "Prefer to consolidate small inputs" or "Prefer to minimize inputs" when creating a transaction.

With "Prefer to minimize inputs", the client could choose the fewest number of inputs that will exceed the intended transaction amount while keeping the total of the inputs as close to the intended transaction amount as possible.  This setting would help maintain the best possible anonymity since fewer addresses would be "connectable" by being included as inputs in the same transaction.

With "Prefer to consolidate small inputs", the client could choose the maximum number of small inputs that it can include in a transaction without triggering a required fee. This setting would trimming the amount of dust from the wallet and reducing the likelihood of a larger fee being necessary in the future at the cost of reduced anonymity.

[Gavin Andresen]

Except that transactions that are smaller than 10 kilobytes do not currently require a fee.  So the user can probably create a transaction that contains nearly 100 inputs each at 0.00005 BTC.  That would be nearly 0.005 BTC worth of 0.00005 BTC inputs that would be spendable in any one transaction.

But a transaction with a 0.005 BTC output triggers this rule:

Code:

// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01

... so you're back to paying 10kilobytes * 0.0005 BTC / kilobyte == 0.005 BTC to spend those 0.005 BTC.

Yes, if you have a large-value, well-aged input then you can combine it with tiny transactions, have a single output greater than 0.01 BTC, and probably get into a block for free.

If you want to prototype a smarter coin-selection algorithm, you might start with the 'spendfrom.py' code I wrote as an example of using the raw transactions API:
  https://github.com/bitcoin/bitcoin/pull/2162

[DannyHamilton]

. . . Yes, if you have a large-value, well-aged input then you can combine it with tiny inputs, have a single output greater than 0.01 BTC, and probably get into a block for free . . .

This is what I was pointing out.  That the client probably needs to continue to include the outputs less than 0.0005 in its balance because they are still usable without a required fee in this sort of situation.