Bitcoin Forum

When one pays a so-called "fee" for a transaction, it's not really a fee at all. It's a bid! It's simply bidding for space in the next available block.

So-called miners are the entities auctioning block-space to the highest bidders.

I've been wondering why there has been so much confusion surrounding the whole "increasing the block-space" thing, and I think it at least partly boils down to a highly misleading nickname. They're not fees, they're bids!

The way I understand it, every time a new block is discovered, an auction occurs and individual kilobytes of that block are auctioned off to the highest bidders. However, at the moment there's a problem because it seems like such a crappy opaque process with very little market transparency. This needs to be improved. Before requesting any transaction, I want to know the "going rate" and the estimated delivery time depending on how much i BID.

Agree? Disagree? Please discuss. :)

Totally agree.

Agree.

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

Following up on that: is it supposed to be part of Bitcoin's core functionality to manage this "block-space bidding" market?

Price history -- core Bitcoin thing or 3rd-party widget/add-on?

Is it possible to withdraw bids?
-I suspect it is, but is there a user interface for it?

Is it possible to see what others are bidding for the same block?

Maybe I'm just behind the times and some of the light-weight clients provide more bidding features than bitcoind?

All the information's publicly posted, so I don't see why it would be too difficult for a client to pull this information.

It should be noted that a .0005BTC bid is not equal among miners, core rules ignored for a minute. Certain pools create certain allowances, bans, and modifiers for different transactions, as well as perhaps certain entities. The SDice patch is a good relevant example. The worrisome spat of no-tx blocks a while back is also a good example of "the rules" being modified - because the rules are more default settings than rules, as I understand it. If you made Luke-Jr really mad, for instance, he may have Eligius ignore all transactions coming from addresses known to be yours., and IIRC, Eligius is known for having irregular bid rules.

Thus, there probably isn't particularly accurate information on whether or not the particular tx you send out will be included in the next block. But, you could get a fuzzy idea using simple information, assuming everyone uses the default bid weight settings.

Change in semantics here might lead to a change in behaviour.

First of let me say how much I like the general idea of what
is commenly know as fees to be called bids.

I wonder when this becomes the rule - will the day of
bitcoin state of the art come when we have special developed
clients for each "nolonger called mining- but now payment
announcementpool" so that we bid in there personally
held auction? :D

Thanks for that! I don't imagine for a moment that I could sway everyone single-handedly, but I hope this discussion helps! Until recently I wasn't 100% certain about the 'fees' really being bids -- perhaps there was some special trick or unique behaviour that made them different? But it never added up -- a 'fee' that you could alter or choose to not pay altogether, and then the request might or might not not get accepted regardless?? So now I've made this thread and hope that as many people as possible start using the more standard terminology.

Yep. Scraping data from the block-chain / blockchain.info etc. I think I've already seen a site that shows a bid vs confirmation time scatter-plot, so I think it would be nice to have something along those lines integrated into a wallet client.


I guess people could even investigate individual Pools' pricing policies, so that you end up with per-pool price indicators... It just all requires time and effort, I guess.


Quite possible. With multi-sig transactions starting to come out, I can imagine all kinds of cool possibilities e.g.: miners gain loyal customers who have their transactions cleared exclusively through them. It's just that calling bids 'fees' so confusing!

a very astute observation

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-

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.

Then I guess we need to have this discussion! It's my understanding that the bitcoind client automatically rebroadcasts transaction requests if they don't go through. At first glance it seems like it shouldn't be that hard to allow users to increase their bid, as you say. It shouldn't require any modification to the protocol, just a better GUI that gives more control over the bid size that gets rebroadcast. :)

Why is there need for much discussion at all ?
Garvin and related devs should be offered a look at the situation and see if they wish to just change the label in the official client.
Or in the alternative clients devs should be informed about this thoughtframeshift.

Increasing the bid should be part of the core functions of the official client - i imagine that your unconfirmed transactions should have the ability to update the bid higher - never lower.

I really like this idea, and it's a feature I've wished since I first started using btc back in 2010.  I can' t count the number of times I've send a fairly important transaction, only to realize that I had fees set on 0 for whatever reason (newly installed client, just send unimportant transaction, etc.).

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

I always understood that they were bids.  It's not clear to me how anyone could view them any differently.

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

From a user perspective this is incomprehensible. Although I don't expect the classic "full node" to start implementing lots of additional GUI functionality, I would expect that the light-weight GUI clients make the bidding process convenient, or at least functional.

I'm going to take a wild guess and say it's because they're called ”fees” in the Bitcoin client.

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!

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.


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.


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.

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

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

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

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.

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.

You spelled "bribe" wrong.

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

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.

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

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?

Fee=stamp?

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

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

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?

What I would like is for the receiver to be able to "bid".

e.g. Acme Corp is willing to pay 1 mBTC for every transaction regardless of what the sender buyer pays.

But I imagine that would require some changes to the protocol. Maybe if the payment address starts with a 1 there is no fee taken from the receiver, if the payment address starts with a, say, z - then then the minor is automatically allowed to take 0.5% of the transaction. Hell - just put z1 at the beginninging instead of 1. Or something.

Businesses that want higher odds of fast confirmation can use it as the payment address, potentially saving money in customer service queries.

Technically: I agree.
Otherwise: I disagree, because if you look at the satoshi client as a whole, much of the terminology is based on how the real world used to think about money:
Wallet instead of keychain
Address instead of publickey(hash)
and therefor also fee instead of "bids that the miners accept to get your transactions into the magical blockchain-voodoo stuff *techbabble continues*".

I think that its easier to get people to use bitcoin, because the terminology is similar to what people are used to when they talk about cash. maybe its a bit off to call it fees, but it greatly eases the _basic_ understanding of whats its doing.

No changes to protocol are necessary.  There are two options that can be done but would require some client/node changes (much easier than extending the protocol)

Option 1: Respend
One can (by protocol) spend 0-confirm transactions the client prevents this by that can be easily changed (we modified our bitcoind for this exact purpose).  The larger issue is that currently miners can't "see" the downstream transaction.  They should and when they can it will allow you to get confirmations by simply creating a new tx with a fee (this potentially could be done automatically via a sweep process).  This sweep process could even be designed to periodically only grab the "slow pays".  The node logs incoming txs and every hour looks for tx older than x minutes with no confirmations.  Those tx are bundled up into one sweep.

Example:
customer A sends 1 BTC (w/ no fee) to payment address X (A->X).  Your system detects this and creates a tx spending the entire output to X in a new tx (X -> Y) which includes a fee.  Mining pool has rejected tx A->X for insufficient fees but detects your paying tx (X->Y) meets criteria for inclusion in a block.  The mining node adds BOTH txs (A->X AND X->Y) into the next block.  The node has to add the A->X because the block will be invalid if X->Y is only included as a block can't include tx with unconfirmed inputs however there is no rule against both tx being in the same block.


Option 2: Off-blockchain fee payments (contracts)
A pool (or collection of pools) could make an agreement with a merchant to include all txs to their addresses (merchant could either provide a list or a deterministic public key seed) either on a per tx basis or potentially a monthly contract (i.e. up to 1,000 tx for Y BTC).    The mining node software would simply look for this "premium" txs and always include them first.

I was looking through satoshi's posts, and even he said something like "same inputs, same outputs, larger fee."

Unfortunately that doesn't work, because the fee is sum(inputs) - sum(outputs). The only way I can see it working is "same inputs (and one more), same outputs (and one more), larger fee," but that still doesn't seem as optimal as adding the "Respend" scenario to the default miner code.

I do agree with what your saying, however the term Fee's fits the wording for the one transfering the coins better.

For the person transferring coins its not really a BID, its more of a set price you have to pay to send the coins.