Bitcoin Forum
December 08, 2016, 08:20:08 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Configurable transaction fees  (Read 2225 times)
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 04, 2011, 07:26:53 PM
 #1

Satoshi's paper talks about miners being able to set their own fee policies in future, especially when the generation output from a block drops significantly.

This is not yet implemented, and it's not exactly straightforward to do. The current client displays a dialog window telling the user that his transaction exceeds limits and asking if she wants to add a transaction fee. We definitely want to keep this feature, but it would become quite hard if every miner had his own fee policy.

I'd like to request comments on how it could be done.

My idea is to create a kind of language that would define miner's fee policy. For instance, the current rules from the mainstream client could be written roughly like this:


if sum(output.value) < 0.01 then:
  return { relay => true, accept => true, fee_required => 0.01 }

if sum(waiting_tx.size) < 27kB then:
  return { relay => true, accept => true, fee_required => 0 }

return { relay => true, accept => true, fee_required => 0.01 * (sum(waiting_tx.size) / 250kB)


relay => true means that the node agrees on forwarding the transaction matching the given criteria (i.e. if relay => false, then node won't propagate such a transaction further down the network)

accept => true means that the miner will accept such a transaction into the block as long as fee_required is met.

The code above doesn't cater for transaction prioritizing etc; but it's an example to show my idea.

Now.

When a miner solves a block, he propagates it through the network along with the miner's fee policy. Other nodes receive and store this policy along with the block (discarding policies older than some given amount of blocks). Whenever a user sends out a transaction, the node runs all the recent (say, 100) policies against it, providing the current sizes of block and all the other required input data, to see how many miners would require a fee for the transaction and how large the fee would be. It will then be able to tell the user something like: "Yo, your transaction is soo large that approximately 50% of miners will require a fee of 0.01, approximately 30% require a fee of 0.05 and approximately 20% will accept it for free, based on the current usage of the network. Would you like to play a ga^W^W^W set a fee to get your transaction processed faster?"

1481185208
Hero Member
*
Offline Offline

Posts: 1481185208

View Profile Personal Message (Offline)

Ignore
1481185208
Reply with quote  #2

1481185208
Report to moderator
The grue lurks in the darkest places of the earth. Its favorite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481185208
Hero Member
*
Offline Offline

Posts: 1481185208

View Profile Personal Message (Offline)

Ignore
1481185208
Reply with quote  #2

1481185208
Report to moderator
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 04, 2011, 07:33:58 PM
 #2

I think in the long run people will be submitting transactions directly to miners or mining consortiums, bypassing the P2P network altogether. The current broadcast/floodfill system is convenient as it requires no other infrastructure and I'm sure it'll always be used to some extent.

But it's much simpler and more flexible to just have your client say "Send this transaction to <MinerCorp Alpha>" and you can negotiate the fee directly with that (set of) miners. Now maybe there is some kind of standard language to enable those negotiations, but the space of possible negotiations is huge so web integration might be better. Like, maybe if you're a repeat customer you get a discount.

As a random example, I think in future miners who charge by the gigahash of work done will be more common. Your proposed language can't handle that. I guess size would still be involved, but only to stop really wild abuses rather than being something regular users encounter.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
May 04, 2011, 07:42:49 PM
 #3

I don't think there's a need to make it complicated.

Allow each client to set a "fee per kilobyte", which can be any amount including zero. Let the miners set whatever policy they like.

That's enough to get a competitive market. Anything else is too complicated for Average Joe to understand.
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 04, 2011, 08:01:09 PM
 #4

I think in the long run people will be submitting transactions directly to miners or mining consortiums, bypassing the P2P network altogether. The current broadcast/floodfill system is convenient as it requires no other infrastructure and I'm sure it'll always be used to some extent.
Interesting... would have to think about that, but I think it defeats the decentralization of bitcoin a bit.

But it's much simpler and more flexible to just have your client say "Send this transaction to <MinerCorp Alpha>" and you can negotiate the fee directly with that (set of) miners. Now maybe there is some kind of standard language to enable those negotiations, but the space of possible negotiations is huge so web integration might be better. Like, maybe if you're a repeat customer you get a discount.
If you want that, why don't you use paypal, LR, and that sort of stuff?

As a random example, I think in future miners who charge by the gigahash of work done will be more common. Your proposed language can't handle that. I guess size would still be involved, but only to stop really wild abuses rather than being something regular users encounter.
By the gigahash? Who would they charge by the gigahash if that gigahash produced no blocks? I don't see it done.

Also mind you, that my proposed feature would only provide a rough indication to the end-user, rather than a sure-tell sign of what the fee will be in the end.
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 04, 2011, 08:03:11 PM
 #5

I don't think there's a need to make it complicated.

Allow each client to set a "fee per kilobyte", which can be any amount including zero. Let the miners set whatever policy they like.

That's enough to get a competitive market. Anything else is too complicated for Average Joe to understand.
I agree the simpler it is the better.

But the current default tx fee policy is already way too complicated for Average Joe to understand. It's hard for me to understand, and the details of it aren't even mentioned on the wiki, one would have to go to the C++ code directly to find out what the weightings are for priorities and stuff.

I don't think we could get away with a simple hard-set "fee per kilobyte", because we DO want some transactions to be free and some others to require a fee.
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
May 04, 2011, 08:33:56 PM
 #6

But it's much simpler and more flexible to just have your client say "Send this transaction to <MinerCorp Alpha>" and you can negotiate the fee directly with that (set of) miners. Now maybe there is some kind of standard language to enable those negotiations, but the space of possible negotiations is huge so web integration might be better. Like, maybe if you're a repeat customer you get a discount.
If you want that, why don't you use paypal, LR, and that sort of stuff?

Because those are just different methods of payment which use the dollar?
Bitcoin is a different currency. This MinerCorp Alpha wouldn't be able to inflate at will, for instance.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
May 04, 2011, 08:38:57 PM
 #7

I don't think we could get away with a simple hard-set "fee per kilobyte", because we DO want some transactions to be free and some others to require a fee.
The fee is not "hard-set", it's a user interface option in the client.

Yes we do want some transactions to be free. What I expect will happen is that the cheapskates will set their fee to zero, and jostle for the limited number of free transactions. Everyone else wants their transactions to clear quickly and will set their client to pay "the going rate".
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 04, 2011, 08:40:29 PM
 #8

But it's much simpler and more flexible to just have your client say "Send this transaction to <MinerCorp Alpha>" and you can negotiate the fee directly with that (set of) miners. Now maybe there is some kind of standard language to enable those negotiations, but the space of possible negotiations is huge so web integration might be better. Like, maybe if you're a repeat customer you get a discount.
If you want that, why don't you use paypal, LR, and that sort of stuff?

Because those are just different methods of payment which use the dollar?
Bitcoin is a different currency. This MinerCorp Alpha wouldn't be able to inflate at will, for instance.

OK, then something like mybitcoin or mtgox.
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 04, 2011, 08:42:41 PM
 #9

I don't think we could get away with a simple hard-set "fee per kilobyte", because we DO want some transactions to be free and some others to require a fee.
The fee is not "hard-set", it's a user interface option in the client.

Yes we do want some transactions to be free. What I expect will happen is that the cheapskates will set their fee to zero, and jostle for the limited number of free transactions. Everyone else wants their transactions to clear quickly and will set their client to pay "the going rate".
And how do you propose to determine "the going rate"?
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
May 04, 2011, 08:53:05 PM
 #10

And how do you propose to determine "the going rate"?
A "going rate" is an aggregation of individual experiences. It's not centrally decided (although a new Bitcoin installation might set a reasonable default).

Consider how one determines the "going rate" for a loaf of bread. It's the price one has discovered, from experience, to be sufficient to buy a loaf of bread of the desired quality.

So, if your transactions aren't always getting into the next block, you may wish to pay more. On the other hand, if money is tight and you don't mind waiting, you can set your fee lower. The market sorts it out.
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 04, 2011, 09:02:09 PM
 #11

And how do you propose to determine "the going rate"?
A "going rate" is an aggregation of individual experiences. It's not centrally decided (although a new Bitcoin installation might set a reasonable default).

Consider how one determines the "going rate" for a loaf of bread. It's the price one has discovered, from experience, to be sufficient to buy a loaf of bread of the desired quality.

So, if your transactions aren't always getting into the next block, you may wish to pay more. On the other hand, if money is tight and you don't mind waiting, you can set your fee lower. The market sorts it out.
Right... but like you said, an Average Joe has no clue about the current going rate for a tx fee. And he won't be able to determine when the next block is happening, how many transactions of what sizes are currently waiting to be included, etc... Assuming Average Joe wants his transaction processed ASAP, and does not want to wait for a block just to see if it gets included, and then re-transmit his transaction with a higher fee and all that, he needs to BE TOLD what the current going rate is. And the only way to do it is in software.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
May 04, 2011, 09:22:45 PM
 #12

Average Joe ... needs to BE TOLD what the current going rate is.
Joe can simply be told that "If your transactions are too slow to confirm, you can go to 'Settings' and increase the transaction fee that you pay, which might speed things up."

You have proposed to define the miner's fees in a structured way, but I don't think that will work in the real world. No matter how intricate you make your language, there will be miners that do things in a different way. Some miners might give preferential treatment to repeat customers (communicated somehow "out-of-band"), some miners might give a better deal to those who are members of the Bitcoin Mutual Aid Association, some miners might have different rates for days/nights/weekends, some miners might charge ten times as much for certain transaction types as a kind of economic ostracism, some miners might waive their fee for payments to well-known charitable donation addresses, some miners will charge different fees depending how long since the previous block was generated.

But a stable market will eventually develop, and a "rule of thumb" will gradually become apparent, such as "free transactions normally get into a block within 12 hours; a fee of 0.1 BTC is almost always enough to get into the next block; a fee of 0.01 BTC gets into the next block 50% of the time".
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 04, 2011, 09:37:26 PM
 #13

Average Joe ... needs to BE TOLD what the current going rate is.
Joe can simply be told that "If your transactions are too slow to confirm, you can go to 'Settings' and increase the transaction fee that you pay, which might speed things up."
But that'll make him pay unnecessarily large fees at times.

Quote
You have proposed to define the miner's fees in a structured way, but I don't think that will work in the real world. No matter how intricate you make your language, there will be miners that do things in a different way. Some miners might give preferential treatment to repeat customers (communicated somehow "out-of-band"), some miners might give a better deal to those who are members of the Bitcoin Mutual Aid Association, some miners might have different rates for days/nights/weekends, some miners might charge ten times as much for certain transaction types as a kind of economic ostracism, some miners might waive their fee for payments to well-known charitable donation addresses, some miners will charge different fees depending how long since the previous block was generated.
That's great then. Remember, my structured way was only meant to provide a rough overview, not a binding contract.

Some of these different ways like time of day/week, or known addresses, can be catered for in the language. Some more complex ones could just have a flag like "I use a complex fee system" so a node would known how many non-standard miners there are. Interested people could then go to a website, see what sort of "complex" fee systems this miner uses, and perhaps even incorporate that into a new version of the language, if possible. Or just leave it at that.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
May 04, 2011, 09:59:29 PM
 #14

But that'll make him pay unnecessarily large fees at times.
It cancels out. Miners set their prices based on the average customer. If some customers are paying "unnecessarily large fees", the miners can still be profitable with some customers paying smaller fees than they would otherwise be required to pay.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 05, 2011, 03:09:38 PM
 #15

Half-baked thoughts:

Broadcasting policies makes me nervous-- it is too easy to lie, and there might be some advantage to lying.

Couldn't clients infer all the information they need to know about what transactions/fees are being accepted by miners by keeping track of transactions in the memory pool and looking at the last 10,000-or-so generated blocks?

How often do you get the chance to work on a potentially world-changing project?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 05, 2011, 04:32:10 PM
 #16

That doesn't work for lightweight SPV clients.

This is one reason I think we'll move to a direct-submission model with pay by the gigahash. There's really no way to know how much fees to pay today. Even if you try and guess based on prior experience, you might get unlucky and end up with a transaction stuck in limbo that nobody is working on.

The mining model I proposed a week or so ago in which you pay for work done rather than inclusion in a block solves this. If you are trying to pay too little to ever make it into a block the miner just rejects your tx with an error message (eg if you submit via HTTP POST you'd get "402 Payment Required"). If you pay 100 BTC then maybe the miner in question works on blocks for hours or days after your tx is successfully incorporated into the chain, just to ensure it's buried as deep as you paid for.

For end users who just want to buy something, they'd send free transactions .... they sit in the memory pool never confirming until the recipient wants to get some confidence they won't be reversed and pays the fee. To decide how much to pay in fees, you look at how many blocks you'd like it buried under, and how many gigahashes you'd need to pay for to achieve that in your chosen timeframe, then directly submit a fee-paying tx to the miner. They don't broadcast it. They work on it until they find a block and claim the fees.

It solves the "lower fees death spiral" problem discussed before as well.
gim
Member
**
Offline Offline

Activity: 90


View Profile
May 05, 2011, 08:44:02 PM
 #17

The mining model I proposed a week or so ago in which you pay for work done rather than inclusion in a block solves this. If you are trying to pay too little to ever make it into a block the miner just rejects your tx with an error message (eg if you submit via HTTP POST you'd get "402 Payment Required").

First thought: if this happens, we're somehow back to the standard bank model?

Many things are unclear.
How do miners know they have exclusivity on the tx? Even if you send the fee hardcoded to the miner address inside the tx, miners are still vulnerable to double tx attacks. So, it would require some trust and would somehow conflict with anonymity here, no?

If you pay 100 BTC then maybe the miner in question works on blocks for hours or days after your tx is successfully incorporated into the chain, just to ensure it's buried as deep as you paid for.

If it's buried 1 deep, it would continue to get buried deeper at the speed of the network anyway. Why to pay for that?

It solves the "lower fees death spiral" problem discussed before as well.
Thread? (I couldn't find it)
gim
Member
**
Offline Offline

Activity: 90


View Profile
May 05, 2011, 09:09:03 PM
 #18

Also, why the current fee model is not good enough?

Just put 0.001 BTC as the default fee per KB. Almost anyone would agree to pay that.

Why miners would refuse it? Scanning too much tx data would cost them a few nonces?
In fact, it's probably the opposite... miners should implement heuristics to the Knapsack problem, just to grab as much fee as possible.

Unless... someone is willing to spam the blocks up to 0.002 BTC per KB just for fun? And the fee would raise? Maybe, but that is 2BTC per block currently, quite a lot.

I don't understand why today, some tx that have a 0.01 fee are not automatically included into the next block.
Blocks are not so crowded these days, so miners just loses money. For sure it will change, won't it?
goblin
Jr. Member
*
Offline Offline

Activity: 38


View Profile
May 06, 2011, 10:00:54 PM
 #19

Quote from: [mike
]
That doesn't work for lightweight SPV clients.
SPV being lightweight mobile-like clients? They could just fetch an aggregated and processed transaction fee policy guess from a full node with some special protocol message.

This is one reason I think we'll move to a direct-submission model with pay by the gigahash. There's really no way to know how much fees to pay today. Even if you try and guess based on prior experience, you might get unlucky and end up with a transaction stuck in limbo that nobody is working on.

The mining model I proposed a week or so ago in which you pay for work done rather than inclusion in a block solves this. If you are trying to pay too little to ever make it into a block the miner just rejects your tx with an error message (eg if you submit via HTTP POST you'd get "402 Payment Required"). If you pay 100 BTC then maybe the miner in question works on blocks for hours or days after your tx is successfully incorporated into the chain, just to ensure it's buried as deep as you paid for.
Firstly, there is already a way described by Satoshi to re-send a transaction with a higher fee. Secondly, I found a few problems with such a solution:

1. You said you pay per gigahash. Let's say you paid to MineCorp1 100 BTC which is defined by their rules to cater for 100 Thash. They start up their rig and mine for 100 Thash and find nothing. All the user's money went to waste.

2. MineCorp1 can mine for 100 Thash and find a block, but actually have some incentive not to put the user's transaction in there. Because no-one can prove who actually found a block, they can pretend they didn't find anything and include other, more valuable transactions into the block.

For end users who just want to buy something, they'd send free transactions .... they sit in the memory pool never confirming until the recipient wants to get some confidence they won't be reversed and pays the fee. To decide how much to pay in fees, you look at how many blocks you'd like it buried under, and how many gigahashes you'd need to pay for to achieve that in your chosen timeframe, then directly submit a fee-paying tx to the miner. They don't broadcast it. They work on it until they find a block and claim the fees.

3. The miner can just take the fee-paying tx and drop the user's transaction.

Quote from: gavinadresen
Broadcasting policies makes me nervous-- it is too easy to lie, and there might be some advantage to lying.

Couldn't clients infer all the information they need to know about what transactions/fees are being accepted by miners by keeping track of transactions in the memory pool and looking at the last 10,000-or-so generated blocks?
I agree, nice idea. Perhaps even a mixture between broadcasting pre-set policies and learning from the past could be used.

Hopefully there's not much incentive in lying.

Also, mind you, trying to "guess" a policy based on looking at the past might be more difficult. With a broadcast fee policy, you have an input (state of network, number of transactions waiting, etc.) and an algorithm (the fee policy), so you can predict the fee by applying this algorithm to this input. With looking at old blocks, you have an input and an output, but you have to guess the algorithm. Perhaps neural networks are good at this, but it's kinda hard to implement.

It's not so easy, but we'll face that problem sooner or later, so there'd better be a discussion for it :->
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 06, 2011, 10:30:57 PM
 #20

Would the intelligent use of the "sequence" field of the tx mitigate this somewhat? For instance, if you have a transaction sitting around unconfirmed for a while, you could manually increase the tx fee and rebroadcast. Or, perhaps the software automatically increases the transaction fee by some amount and rebroadcasts every X minutes the transaction has not been included in a block.
Pages: [1] 2 »  All
  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!