JSON-RPC API change: Explicit handling of transaction fees

[Luke-Jr]

Link to pull request

This patch disables automatically adding "minimum" fees for JSON-RPC methods-- instead, it returns an error (stating how much fee is "required") or, iff the user sets the new second parameter "force" to the 'settxfee' JSON-RPC method, sends the transaction with the user-specified fee.

There are two ways to use this:

• Read the error, optionally prompt your user to approve the fee, and use "settxfee" to retry the send with the fee.
• Use "settxfee" with the "force" option to send it with a lower fee than "required", because you know a miner who will accept it.

This only affects JSON-RPC users, who should be assumed to understand the risk of sending with insufficient fees.

[1714170801]

1714170801

[1714170801]

1714170801

[1714170801]

1714170801

[2112]

(stating how much fee is "required")

This would require replacing a PRNG in the stochastic knapsack solver. Currently there is a call to rand() there. This isn' reproducible and testable. Maybe you can think of some repeatable PRNG that is explicitly seeded off with something that will every time select the same coins from the same wallet and thus require the same fee?

[Luke-Jr]

(stating how much fee is "required")

This would require replacing a PRNG in the stochastic knapsack solver. Currently there is a call to rand() there. This isn' reproducible and testable. Maybe you can think of some repeatable PRNG that is explicitly seeded off with something that will every time select the same coins from the same wallet and thus require the same fee?

No, that would be an unrelated change. Right now, the code just does a while(notEnoughFees) { addFees(); findCoins(); }

[2112]

No, that would be an unrelated change. Right now, the code just does a while(notEnoughFees) { addFees(); findCoins(); }

Are you proposing an iterative solution to a non-monotonic non-deterministic optimization problem?

Do I understood you right?

[Luke-Jr]

No, that would be an unrelated change. Right now, the code just does a while(notEnoughFees) { addFees(); findCoins(); }

Are you proposing an iterative solution to a non-monotonic non-deterministic optimization problem?

Do I understood you right?

I'm proposing moving "do I accept this fee" logic outside of the "always say yes" we have right now, nothing more.

[theymos]

I don't think there should be any way for users to override required fees until "stuck" transactions can be reversed.

[Luke-Jr]

I don't think there should be any way for users to override required fees until "stuck" transactions can be reversed.

This wouldn't change anything user-facing (ie, GUI).

[theymos]

This wouldn't change anything user-facing (ie, GUI).

Non-expert people are not limited to the GUI interface. If this was included in the main release, I'm sure many people would get transactions irreversibly stuck.

Maybe it'd be OK to allow it with a "-disableSafeFees" switch or something.

[2112]

I'm proposing moving "do I accept this fee" logic outside of the "always say yes" we have right now, nothing more.

Then your patch is worse than the original problem. It pushes bitcoin further down the path of being an untestable and non-deterministic software.

I think the sipa's competing approach is much better. He proposed a "pseudo transaction"
that rolls the dice once, selects the coins, presents the calculated fee and allows the JSON-RPC
user to commit or abort the transaction.

I believe that his patch had a locking and garbage collection problem.

If your JSON-RPC Keep Alive and JSON-RPC multi-threaded locking patches are approved then sipa's patch is fixable.

As it is your patch makes a user-visible problem hidden under the additional layer of obfuscation and randomness. People tend to notice unapproved fees draining their balance. The current situation is "always say yes" only in bitcoind. The bitcoin client pops up a dialog box.

[Luke-Jr]

As it is your patch makes a user-visible problem hidden under the additional layer of obfuscation and randomness. People tend to notice unapproved fees draining their balance. The current situation is "always say yes" only in bitcoind. The bitcoin client pops up a dialog box.

This only affects bitcoind.

Also, new version requires an undocumented -nosafefees option for that.

[ShadowOfHarbringer]

I absolutely support this patch.

Not allowing me do what i want with my money was the exact reason i created "No forced TX fee" fork.

People should be given a choice, ALWAYS - that is all Open Source is about. There should be an expert switch, preferably in bitcoin.conf, and additionally --force parameter should be specified in bitcoind/JSON-RPC when user wants to send transaction without fee/with lower fee - so we can have absolute certanity that the user knows what he is doing.

Also, a warning message of some sort could be returned after payment is sent to give user further information about what he just did.

[ByteCoin]

I don't think there should be any way for users to override required fees until "stuck" transactions can be reversed.

At the moment, if you want to send without fees and risk getting "stuck", you can compile your own client. Since you're running non-standard software then it's clearly your fault if your transactions get stuck.
If the official client can be used to send with an inadequate fee resulting in "stuck" transactions then the official client becomes "fragile software".
I imagine the support overhead and bad PR associated with stuck transactions is likely to be worse than the irritation with the miniscule fees.

A possible compromise might be to enable the option but to display a warning and leave the feature undocumented. I still don't see what the incentive for change is for the developers who are happy with the fees and want to keep the code simpler and smaller.

ByteCoin

[theymos]

At the moment, if you want to send without fees and risk getting "stuck", you can compile your own client. Since you're running non-standard software then it's clearly your fault if your transactions get stuck.
If the official client can be used to send with an inadequate fee resulting in "stuck" transactions then the official client becomes "fragile software".

This is also my position. Until there is no risk associated with sending some transactions (because they can be reversed), the default client shouldn't allow such transactions.

[casascius]

I believe that the transaction fee should be an optional parameter that can be specified per transaction.

The options would be to either a) pay a specific amount, failing the transaction if the amount is not enough (returning the minimum in the error message), b) pay the minimum that the client would otherwise enforce, c) pay a specific amount, to hell with the minimum (own risk), or d) pay whatever is pre-configured in the software.

The reason why I take this perspective is I believe that one organization should be able to run as little as one "bitcoind" server that services everybody on that local network, sort of how a single SMTP server collects email for a whole network.  This is because the resource consumption of bitcoind grows with the block chain, soon it can be expected to reach the point that doing this becomes a best practice.

I see bitcoind evolving into a multi-user daemon that either handles wallets for multiple people, or supports light client software that does all the wallet handling.  Yet bitcoind seems designed as though it will forever be deployed "per user".

I believe that it's a sin for bitcoind to act like it is only being used by one person.  A design where one must "settxfee" for the whole daemon, before doing a transaction, is not a good one.  Settxfee should set the defaults when such a parameter is not specified with a transaction, and nothing more.

[Luke-Jr]

I just added a "maxtxfee" option to get the old behaviour (enabled by default up to 0.01 BTC fee). Hopefully this is a good compromise?

[ShadowOfHarbringer]

I just added a "maxtxfee" option to get the old behaviour (enabled by default up to 0.01 BTC fee). Hopefully this is a good compromise?

Probably, however the question is: will this be merged into the mainline client ?

[gregwtmtno]

Hey Luke,

Thanks for the patch. I'm trying to use it to send bitcoins automatically at a certain rate, with fees included. In other words, if I'm trying to send 1 coin, I'd like the transaction + the fee to total to 1BTC. Currently, I have the client attempt to send a coin with no fees to create an error reporting the fee and subtracting that fee from the amount I'm going to send.

I get the feeling that this is an unreliable way to do things though. Is there a better way to make this happen?