Why does everyone keep calling them fees? They're not fees, they're BIDS!

[blablahblah]

Yeah sorry they're fees plain and simple.  Called fees in the client, it's a transaction fee.  It's fine if you want to 'think of them as bids' whatever, but no they're fees

But that's just it: a 'fee' is something you have to pay in exchange, e.g: for an item with a fixed price, and if you don't pay then absolutely without a doubt you will. not. get. that. item. So, they're not fees. Different word, different concept.

How has this been going on for so long? I thought it was correct!

[Pteppic]

Here are some of my thoughts regarding the block size limit. I don't know all the technical issues, so I may have missed out some important stuff about orphan blocks, for example, but I hope a kind of market analysis might add to the debate from a different perspective.

In an efficient system, the price of transactions should converge towards the cost of processing those transactions.

For miners at the moment, the block reward covers their overheads in terms of hardware and electricity and so on. While there are relatively few transactions taking place, the cost of processing each transaction is negligible, or not worth calculating.

In the future, transaction fees will have to be covering both the cost of processing and also mining overheads as well. That means the most efficient miners will be those with the lowest total costs per transaction processed. In other words, they will be competing on bandwidth costs as well as electricity costs and hashing power.

So when transaction fees are making up a significant proportion of miner's income, the measure of a miner's efficiency might be something like transactions per second per dollar of costs instead of Mhash per dollar. Given the average rate of transactions on the network, a miner will be able to estimate the transaction fee per transaction in order to  break even. Even if there were no block size limit, they could choose to reject all transactions offering a lower fee than their break even point.

An efficient miner will be able to process a larger number of transactions with a lower fee per transaction. This will bid down the average fee size. An inefficient miner will not be able to find enough transactions with a sufficient fee so they will drop out.

If the block size is limited, then miners lose out as well, because conceivably, transactions with a big enough fee to be profitable will have to be ignored, because it will take them over the block size limit.

Some of those points need further thinking, but the important thing is to work out how to calculate the cost per transaction. That changes the thinking from wanting fees to be simply as big as possible to wanting them to be at least above your break even point. Also, instead of worrying how to keep transactions scarce, you can see that bandwidth limitations make transactions scarce, and therefore higher priced on their own without needing an additional block size limit.

[blablahblah]

Here are some of my thoughts regarding the block size limit. I don't know all the technical issues, so I may have missed out some important stuff about orphan blocks, for example, but I hope a kind of market analysis might add to the debate from a different perspective.

In an efficient system, the price of transactions should converge towards the cost of processing those transactions.

For miners at the moment, the block reward covers their overheads in terms of hardware and electricity and so on. While there are relatively few transactions taking place, the cost of processing each transaction is negligible, or not worth calculating.

In the future, transaction fees will have to be covering both the cost of processing and also mining overheads as well. That means the most efficient miners will be those with the lowest total costs per transaction processed. In other words, they will be competing on bandwidth costs as well as electricity costs and hashing power.

So when transaction fees are making up a significant proportion of miner's income, the measure of a miner's efficiency might be something like transactions per second per dollar of costs instead of Mhash per dollar. Given the average rate of transactions on the network, a miner will be able to estimate the transaction fee per transaction in order to  break even. Even if there were no block size limit, they could choose to reject all transactions offering a lower fee than their break even point.

An efficient miner will be able to process a larger number of transactions with a lower fee per transaction. This will bid down the average fee size. An inefficient miner will not be able to find enough transactions with a sufficient fee so they will drop out.

If the block size is limited, then miners lose out as well, because conceivably, transactions with a big enough fee to be profitable will have to be ignored, because it will take them over the block size limit.

Some of those points need further thinking, but the important thing is to work out how to calculate the cost per transaction. That changes the thinking from wanting fees to be simply as big as possible to wanting them to be at least above your break even point. Also, instead of worrying how to keep transactions scarce, you can see that bandwidth limitations make transactions scarce, and therefore higher priced on their own without needing an additional block size limit.

Hi Pteppic,
Thanks for your reply! While I disagree on some points, I appreciate the thoughtfulness.
As I see it, some mining costs are semi-fixed or sticky: hardware, scheduled maintenance etc.
Some mining costs vary, e.g.: electricity per block created.
That variable cost is essentially based on a bubble. It's a game of supply and demand, where a "limited resource" is being supplied by the protocol, and Bitcoin users 'demand' that resource.
The limited resource is a combination of two items: new coins, and block ledger space where transactions are signed.

(Ignoring the new coins for now), block space is like "bandwidth for SMS messages" -- there's a limited supply, and people find it useful so they're willing to pay in order to get some.

In the future, transaction fees will have to be covering both the cost of processing and also mining overheads as well. That means the most efficient miners will be those with the lowest total costs per transaction processed. In other words, they will be competing on bandwidth costs as well as electricity costs and hashing power.

True, but their aggregate costs are dictated by Bitcoin's popularity.
Let's say the markets are hitting $45 per BTC.
Discounting future investment and general betting, if a miner isn't breaking-even and getting at least $45-worth from their efforts, it's not worth doing. Thus the price regulates the "difficulty" of the hashing game, and since it's a competitive game it's no surprise that the system is constantly evolving. Inefficient miners get left behind, and the remaining competitors push the relative costs higher and higher until it's barely worth doing.

An efficient miner will be able to process a larger number of transactions with a lower fee per transaction. This will bid down the average fee size. An inefficient miner will not be able to find enough transactions with a sufficient fee so they will drop out.

I like to think of block space as a precious item that the miners want to sell for as much money for as they can get. E.g.: prime water-front real estate. Thus, high bids get high priority, and vice versa. And expensive requests (transactions with multiple I/O) also cost more. However, it's also a race against time because some other miner might also discover a block. Therefore only the bids that have already queued up are considered. If there's any unsold space at the end of the auction, some of the remaining space might be given away for free -- depending on the miner's politics. E.g.: one reason to reject free transactions could be to encourage users to "bid higher next time".

Let's look at 2 alternate scenarios:
1)
Block space is extremely abundant and there's always enough for everyone. Why pay? Even if 100 miners keep rejecting transaction requests to encourage users to cough-up higher bids, the 101st miner might sign all the 'free-loaders' regardless. Since the network difficulty must match the "resource reward" (made up of new coins and winning bids), low rewards would tend to force the difficulty down.

2)
If block space is too scarce, basically the opposite happens. Miners get rewarded with higher and higher bids... until Visa and Mastercard et al. start looking competitive again. Bitcoin doesn't operate in a vacuum so it should take its environment into account.

So how does one find the right level of scarcity to maintain a multi-dimensional balance of:
D1: high network security
D2: 'optimum'(?) exchange rate
D3: competitive transaction costs
??

By a fixed algorithm? E.g.: the Bitcoin protocol automatically adjusts block size as well as difficulty.
Or by a human-influenced market? E.g.: miners competitively pull block-size up or down.

I think both options are likely to have flaws, and it seems like an extremely difficult problem to model. Since Bitcoin will likely always have external influences (competing currencies and payment systems), and those externalities may behave irrationally, I'm leaning towards allowing a human-controlled evolutionary algorithm for finding that balance.

[johnyj]

Agreed that it is biding process, but then there is a question about who will get the bid

If you bid by a constant bitcoin value, those who transfer hundreds of coins will likely be willing to pay 1 BTC in fee, so that those small transactions will seldom get passed

If you bid by a percentage of total transaction amount, then those small transactions could take the most volume, since they want to do it fast even at a 5% fee, and those huge transactions will reduce greatly since the cost is too high

[Tomatocage]

Retarded thread is retarded. Derr why do they call it a "block"?!? It's not cube shaped at all! Derp.

[Anon136]

In an efficient system, the price of transactions should converge towards the cost of processing those transactions.

In an efficient system maybe but not in a secure system (atleast not in a secure bitcoin system)

[Pteppic]

I like to think of block space as a precious item that the miners want to sell for as much money for as they can get. E.g.: prime water-front real estate. Thus, high bids get high priority, and vice versa. And expensive requests (transactions with multiple I/O) also cost more. However, it's also a race against time because some other miner might also discover a block. Therefore only the bids that have already queued up are considered. If there's any unsold space at the end of the auction, some of the remaining space might be given away for free -- depending on the miner's politics. E.g.: one reason to reject free transactions could be to encourage users to "bid higher next time".

Let's look at 2 alternate scenarios:
1)
Block space is extremely abundant and there's always enough for everyone. Why pay? Even if 100 miners keep rejecting transaction requests to encourage users to cough-up higher bids, the 101st miner might sign all the 'free-loaders' regardless. Since the network difficulty must match the "resource reward" (made up of new coins and winning bids), low rewards would tend to force the difficulty down.

2)
If block space is too scarce, basically the opposite happens. Miners get rewarded with higher and higher bids... until Visa and Mastercard et al. start looking competitive again. Bitcoin doesn't operate in a vacuum so it should take its environment into account.

So how does one find the right level of scarcity to maintain a multi-dimensional balance of:
D1: high network security
D2: 'optimum'(?) exchange rate
D3: competitive transaction costs
??

By a fixed algorithm? E.g.: the Bitcoin protocol automatically adjusts block size as well as difficulty.
Or by a human-influenced market? E.g.: miners competitively pull block-size up or down.

I think both options are likely to have flaws, and it seems like an extremely difficult problem to model. Since Bitcoin will likely always have external influences (competing currencies and payment systems), and those externalities may behave irrationally, I'm leaning towards allowing a human-controlled evolutionary algorithm for finding that balance.

As well as VISA and Mastercard, the miners face competition from Mt.Gox internal transfers (free and instant and a high proportion of bitcoin users have accounts), other block chains and potentially Ripple. I don't think miners will ever have the pricing power to force large transaction fees on users. With that being the case, income from transaction fees can only be increased by processing more of them.

To address another point, instead of wondering 'why pay for transactions if space on the block chain is abundant', you could also ask 'why pay for transactions if miners are processing them for free?' Each transaction is using valuable computing resources. Any miner that allows an unlimited number of fee-free transactions will be costing themselves money. It is just that up to now, the computing resources required for transactions have been small in comparison to those required for mining, so they have not been considered. As the costs involved in processing high transaction volumes becomes clearer, I believe miners will modify their own behaviour to compensate.

It is like the miners who were operating at a loss when the price was less than $5. They are pushing the difficulty up for all miners, while they are also losing money. Other miners had no choice but to deal with it until they dropped out, or the reward increased.

[refaelsh]

After reading all the replays, I understand the following (and please do correct if I am wrong):
I was under the impression that there is no central authority on Bitcoin (like banks on dollars).
Now, it appears, there is: the miners. They can decide the amount of the fees We all pay.

[greyhawk]

You spelled "bribe" wrong.

[blablahblah]

After reading all the replays, I understand the following (and please do correct if I am wrong):
I was under the impression that there is no central authority on Bitcoin (like banks on dollars).
Now, it appears, there is: the miners. They can decide the amount of the fees We all pay.

+1
Agreed. That's partly why "centralisation" is a sensitive topic for some people. Miners do have a lot of power, and there's a limited number of things keeping that power in check, e.g.:

• Competition among miners (faith in humanity as a whole).
• Ease of breaking into the market and becoming a miner yourself.
• Ease of creating "alt-coins" and competing from the outside, because FOSS.
• Being a developer and trying to promote the development process in a certain direction.
• Discourse.

[Zangelbert Bingledack]

The "centralization" that is to be feared is monopolization, not merely having power with one occupation, like mining. As long as there is no forcible barrier to entry, there will not be centralization. Even with only ten miners controlling the network we'd be fine. If it got down to 3 or 4 I'd start to worry...but so would everyone else and they'd give them a rough time because of that, naturally curbing any centralizing tendency.

[Elwar]

If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.

Okay, fine then, they are "tips" or "gratuities"

-MarkM-

Hmm, TIPS: To Insure(ensure) Prompt Service.

[SgtSpike]

If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.

Create a double spend transaction with the same inputs and outputs, but a different "confirmation urgency bid"

Currently most clients in the network will block/not relay this second transaction though.

And rightly so.  If clients relayed double-spend transactions, it would make 0-conf transactions (which are used in things like digital download services) utterly useless.

However, I'd like to think that a particular set of rules could be created to allow relay of transactions with the same inputs and outputs, but it wouldn't be easy.  The possibility of additional inputs in light of a higher fee has to be considered, as well as a differing change address or a differing amount going to the change address.

[ProfMac]

If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.

Create a double spend transaction with the same inputs and outputs, but a different "confirmation urgency bid"

Currently most clients in the network will block/not relay this second transaction though.

And rightly so.  If clients relayed double-spend transactions, it would make 0-conf transactions (which are used in things like digital download services) utterly useless.

However, I'd like to think that a particular set of rules could be created to allow relay of transactions with the same inputs and outputs, but it wouldn't be easy.  The possibility of additional inputs in light of a higher fee has to be considered, as well as a differing change address or a differing amount going to the change address.

Perhaps changing the bid after the fact is not the correct approach.

Is there enough information under control of the Satoshi reference client -- what do we call this, just bitcoind, SRC, or what --- to predict how many blocks later the transaction will be processed, based on work already in the queue?

[SgtSpike]

If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.

Create a double spend transaction with the same inputs and outputs, but a different "confirmation urgency bid"

Currently most clients in the network will block/not relay this second transaction though.

And rightly so.  If clients relayed double-spend transactions, it would make 0-conf transactions (which are used in things like digital download services) utterly useless.

However, I'd like to think that a particular set of rules could be created to allow relay of transactions with the same inputs and outputs, but it wouldn't be easy.  The possibility of additional inputs in light of a higher fee has to be considered, as well as a differing change address or a differing amount going to the change address.

Perhaps changing the bid after the fact is not the correct approach.

Is there enough information under control of the Satoshi reference client -- what do we call this, just bitcoind, SRC, or what --- to predict how many blocks later the transaction will be processed, based on work already in the queue?

Not at all, because each mining pool has different rules by which they include or disclude transactions.  And if higher-priority transactions are created at any time while the transaction is waiting, they take precedence.  There isn't any sort of queue, only priority.  Any sort of estimate wouldn't be at all reliable.

[ProfMac]

If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.

Create a double spend transaction with the same inputs and outputs, but a different "confirmation urgency bid"

Currently most clients in the network will block/not relay this second transaction though.

And rightly so.  If clients relayed double-spend transactions, it would make 0-conf transactions (which are used in things like digital download services) utterly useless.

However, I'd like to think that a particular set of rules could be created to allow relay of transactions with the same inputs and outputs, but it wouldn't be easy.  The possibility of additional inputs in light of a higher fee has to be considered, as well as a differing change address or a differing amount going to the change address.

Perhaps changing the bid after the fact is not the correct approach.

Is there enough information under control of the Satoshi reference client -- what do we call this, just bitcoind, SRC, or what --- to predict how many blocks later the transaction will be processed, based on work already in the queue?

Not at all, because each mining pool has different rules by which they include or disclude transactions.  And if higher-priority transactions are created at any time while the transaction is waiting, they take precedence.  There isn't any sort of queue, only priority.  Any sort of estimate wouldn't be at all reliable.

A different question comes to mind.  Is there any interest in a product that lists the top n pending transactions sorted by their transaction fees?

[Mjbmonetarymetals]

Fee=stamp?

[blablahblah]

Hmm OK, so I guess that that's not so controversial then

Never underestimate how much semantics affect people's ability to think clearly.

Your suggestion is extremely valuable, in my opinion, and there are quite a few other misnomers in the Bitcoin world and especially surrounding the blocksize issue. Using accurate terminology is crucial for arriving at sound judgments.

...
Currently most clients in the network will block/not relay this second transaction though.

And rightly so.  If clients relayed double-spend transactions, it would make 0-conf transactions (which are used in things like digital download services) utterly useless.

However, I'd like to think that a particular set of rules could be created to allow relay of transactions with the same inputs and outputs, but it wouldn't be easy.  The possibility of additional inputs in light of a higher fee has to be considered, as well as a differing change address or a differing amount going to the change address.

Perhaps changing the bid after the fact is not the correct approach.

Is there enough information under control of the Satoshi reference client -- what do we call this, just bitcoind, SRC, or what --- to predict how many blocks later the transaction will be processed, based on work already in the queue?

Not at all, because each mining pool has different rules by which they include or disclude transactions.  And if higher-priority transactions are created at any time while the transaction is waiting, they take precedence.  There isn't any sort of queue, only priority.  Any sort of estimate wouldn't be at all reliable.

Hmm, this is getting more interesting... (And incidentally I'm starting to feel bad for some of my responses to Mr Bigg's Satoshi-Dice-spamming threads recently. Sorry Mr B! ...)

Zangelbert, I'm guessing that one of those other misnomers might be "0-confirmation transactions", when they're really just transaction requests?
And some services operate by using these TX requests as a rudimentary messaging scheme in its own right (and they don't care about the actual payload)?
I think I used the term 'queue' earlier, when it seems more like a heap, is that correct? I recall from other threads that the memory size for these TX requests is essentially unlimited.

Something doesn't sound quite right there.

• If the memory and bandwidth really is unlimited, maybe someone could (at least in principle) painstakingly build a UDP layer on top of Bitcoin, treating the TX requests as individual bits, and create an extremely inefficient file-sharing network?! Clearly there must be some cap on the memory and bandwidth, even if it's quickly growing.
• Based on the responses here so far, a proper bidding process for transactions is possible, but it would require multiple TX requests -- a multitude of those so-called "double-spend" requests. Apparently this is incompatible with some existing services, whose behaviour relies on treating TX requests as the real deal.
• It seems the "memory heap" part of the system might be a bit loosely described at the moment, and tightening that definition could cause some problems for some people...

[gourmet]

1)
Block space is extremely abundant and there's always enough for everyone. Why pay? Even if 100 miners keep rejecting transaction requests to encourage users to cough-up higher bids, the 101st miner might sign all the 'free-loaders' regardless. Since the network difficulty must match the "resource reward" (made up of new coins and winning bids), low rewards would tend to force the difficulty down.

In such a case, if the 100 miners had major hashing power over the 101^st one, they could just ignore his block and build on the previous one, "their good" block...

[cointoss]

If it's possible to bring about this bidding interface for transactions, I wonder if there is a way to integrate bidding for freshly mined bitcoins?