Topic: Configurable transaction fees (Read 2710 times)

Sequence numbers are in the inputs, not the outputs. Satoshis plan for letting you change fees after broadcast would be very hard to implement by his own admission.

Yes, if you pay for 100THash of work it's possible you won't actually ever make it into a block, if you get very unlucky. Perhaps miners would sell "additional work after first block inclusion" or some other slightly different model. I'm not sure yet.

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.

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.


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

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 :->

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?

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 it's buried 1 deep, it would continue to get buried deeper at the speed of the network anyway. Why to pay for that?

Thread? (I couldn't find it)

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.

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?

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.

But that'll make him pay unnecessarily large fees at times.

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.

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".

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.

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.

And how do you propose to determine "the going rate"?

OK, then something like mybitcoin or mtgox.

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".

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.

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.

Interesting... would have to think about that, but I think it defeats the decentralization of bitcoin a bit.

If you want that, why don't you use paypal, LR, and that sort of stuff?

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.

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 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 " 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.