Topic: Why does everyone keep calling them fees? They're not fees, they're BIDS! - page 2. (Read 3018 times)

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

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

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.

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.

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!

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

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

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.

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

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

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

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

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.

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.

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.

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

-MarkM-

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.

a very astute observation

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.


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!

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?