Bitcoin Forum
December 07, 2016, 06:42:48 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Should this solution be accepted?
No, I don't think it's a problem - 0 (0%)
No, I want to wait for a better solution - 9 (45%)
Yes, this seems good for the short-term at least - 4 (20%)
Yes, this covers my needs long-term - 7 (35%)
Total Voters: 20

Pages: [1]
  Print  
Author Topic: JSON-RPC API change: Explicit handling of transaction fees  (Read 2167 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 05, 2011, 04:16:25 PM
 #1

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.

1481136168
Hero Member
*
Offline Offline

Posts: 1481136168

View Profile Personal Message (Offline)

Ignore
1481136168
Reply with quote  #2

1481136168
Report to moderator
1481136168
Hero Member
*
Offline Offline

Posts: 1481136168

View Profile Personal Message (Offline)

Ignore
1481136168
Reply with quote  #2

1481136168
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481136168
Hero Member
*
Offline Offline

Posts: 1481136168

View Profile Personal Message (Offline)

Ignore
1481136168
Reply with quote  #2

1481136168
Report to moderator
1481136168
Hero Member
*
Offline Offline

Posts: 1481136168

View Profile Personal Message (Offline)

Ignore
1481136168
Reply with quote  #2

1481136168
Report to moderator
1481136168
Hero Member
*
Offline Offline

Posts: 1481136168

View Profile Personal Message (Offline)

Ignore
1481136168
Reply with quote  #2

1481136168
Report to moderator
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
October 05, 2011, 05:57:28 PM
 #2

(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?

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 05, 2011, 06:04:53 PM
 #3

(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
Legendary
*
Offline Offline

Activity: 1708



View Profile
October 05, 2011, 06:13:51 PM
 #4

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?

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 05, 2011, 06:20:37 PM
 #5

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
October 05, 2011, 06:22:12 PM
 #6

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 05, 2011, 06:32:32 PM
 #7

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
October 05, 2011, 06:43:13 PM
 #8

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
October 05, 2011, 07:11:54 PM
 #9

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 05, 2011, 07:18:37 PM
 #10

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
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
October 09, 2011, 12:43:28 AM
 #11

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
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
December 01, 2011, 03:29:20 AM
 #12

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
December 01, 2011, 03:47:10 AM
 #13

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
December 01, 2011, 03:57:26 AM
 #14

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
December 02, 2011, 05:52:14 PM
 #15

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
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
December 03, 2011, 12:47:24 PM
 #16

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
Member
**
Offline Offline

Activity: 77



View Profile
December 06, 2011, 03:51:27 AM
 #17

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?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!