[RFC] New TX fee: 0.0005 BTC

[db]

If fees fall, mining will become less profitable, some miners will stop mining, difficulty will decrease, and mining will become more profitable. So?

Difficulty will decrease a lot, leaving Bitcoin without protection from attacks. (Unless users voluntarily donate fees way above market equilibrium, which they well might.)

[1714929772]

1714929772

[1714929772]

1714929772

[1714929772]

1714929772

[dust]

One of the the major selling points of Bitcoin is low transaction fees.  I few days ago I decided not to tip someone .1 btc because it required a .01 fee.  The minimum fee needs to be much lower,  .0005 sounds about right.

[BitterTea]

Difficulty will decrease a lot

[citation needed]

This seems to assume that most of the network's power will come from dedicated miners who are operating just above profitability. I don't see any reason to believe that this will be the case.

[db]

This seems to assume that most of the network's power will come from dedicated miners who are operating just above profitability. I don't see any reason to believe that this will be the case.

So the network's power will come from miners operating at a loss and this whole transaction fee thing - intended to incentivise block generation with profits - is unnecessary?

[SgtSpike]

This seems to assume that most of the network's power will come from dedicated miners who are operating just above profitability. I don't see any reason to believe that this will be the case.

So the network's power will come from miners operating at a loss and this whole transaction fee thing - intended to incentivise block generation with profits - is unnecessary?

Oh come on, you don't believe in everyone volunteering their time and resources for the common good?  Isn't that what socialism is so good at?   

[asdf]

The fees are competing for a time limited resource, inclusion in the next available block

If miners are accepting all transactions with fees, then fees are not competing for a time limited resource; They'll all get included in the next block. Why would a miner leave a fee paying transaction for the next block?

[caveden]

Oh come on, you don't believe in everyone volunteering their time and resources for the common good?  Isn't that what socialism is so good at?   

+1.
Bitcoin should not rely on that.

[sandos]

I don't see how the block size could ever be unlimited, I would think this is what actually costs money, big blocks? Transaction fees will naturally strive to optimize the block-size as a side-effect.

Millions of spam transactions today is no different from millions of legit transactions tomorrow. If the blockchain cannot handle spam today, how could it handle large transaction flows?

[MoonShadow]

The fees are competing for a time limited resource, inclusion in the next available block

If miners are accepting all transactions with fees, then fees are not competing for a time limited resource; They'll all get included in the next block. Why would a miner leave a fee paying transaction for the next block?

Because sometimes they will have to.  There is a set of rules that limit how large the block can be based upon the largest single fee.  Currently this "fee schedule" is so harsh that hitting the 'hard' blocksize limit of (currently) one megabyte is functionally impossible.  Off the top of my head, a block more than a third of megabyte would almost certainly have more bitcoin in fees than the block reward.  If the minimum fee, the max block size, or the fee schedule were to change in the near future (which I think is likely) then that is also likely to change.

[xf2_org]

Pull request created:

     https://github.com/bitcoin/bitcoin/pull/218

[Steve]

I get the fact that the transaction limit will eventually create competition for space in a block and that might help.  But the 2000 limit seems to place an arbitrary limit on transaction scalability.  One issue here is that the cost of mining (securely recording transactions) is associated with the block rather than the individual transactions.  This creates a free rider problem (or at the very least, a very heavily subsidized rider problem).  What if the hashing was done for each transaction in a block and the network enforced a minimum total block difficulty and a minimum transaction difficulty.  The total block difficulty wold be calculated based on the combined difficulty of the transaction hashes.  The minimum block difficulty ensures blocks still only get created once every 10 minutes.  The minimum transaction difficultly would be some ratio to the block difficulty (if it were 1/2000, it would mean that there is no incremental transaction cost until you exceed 2000 transactions...at 1/100 it would 101st transaction that would start to add incremental cost. 

Miners would rank the transactions based on the fee and always include the highest paying among them.  For the 101st (assuming a 1/100 difficulty ratio), the miner would have to weigh the additional hashing cost (which effectively slows down the miner or pool's generation rate) against the fee associated with the additional transaction.  At some level of fee, it would consider the cost to exceed the fee and not include the transaction.  Lower fee transactions would tend to get processed by the network during off peak hours.

There could also be an allowance for really old transactions to be included without meeting the minimum hashing requirement...and maybe a few other special rules to prevent spammy looking transactions.

Note, I'm still not sure whether this creates a situation where difficulty wouldn't start falling to dangerous levels...this would just deal with the free rider problem.  In the absence of a concern over the integrity of the network and without generation fees, the optimal difficulty level with the lowest costs per transaction would be 1.  Mining would trend toward the most efficient miners or the subsidized miners and drive out the miners with higher costs.  And eventually the power would be devoted to good connectivity and the power needed to handle the transaction volume rather than hashing.  Until of course people realize just how vulnerable the network is due to an attack.

Somehow, I think there should be a model of how vulnerable the network is at any given moment and for the network to factor that into difficulty adjustments and perhaps minimum transaction fees (where nodes don't propagate unless those mins are satisfied).  But I'm not sure how you'd do that algorithmically without someone actively trying to attack the network (where the network could somehow detect attacks and adjust transaction fee requirements higher to create the incentive to bring more mining power to bear).

Maybe, the problem of optimizing mining activity for integrity can't be solved algorithmically...perhaps insurance is the key.  Insurers could sell bitcoin systemic failure insurance to people for some premium (settled in, I dunno, gold or some other currency).  A portion of this premium would finance mining operations by injecting very high fee transactions into the network (with the objective of making mining profitable enough to sustain a certain difficulty level they deem sufficient to mitigate the risk of a powerful miner attack).  Businesses operating secure wallet operations might offer such insurance with their service.  Dunno...just some random thoughts.

[xf2_org]

Pull request created:

     https://github.com/bitcoin/bitcoin/pull/218

Pulled into upstream.

[Pieter Wuille]

I did a test transaction using the new rule: see http://blockexplorer.com/tx/f5c5b178fe876c291eb691616c58022166d8505fe6ebf6fca2b94cd5b748fa6a.

[asdf]

The fees are competing for a time limited resource, inclusion in the next available block

If miners are accepting all transactions with fees, then fees are not competing for a time limited resource; They'll all get included in the next block. Why would a miner leave a fee paying transaction for the next block?

Because sometimes they will have to.  There is a set of rules that limit how large the block can be based upon the largest single fee.  Currently this "fee schedule" is so harsh that hitting the 'hard' blocksize limit of (currently) one megabyte is functionally impossible.  Off the top of my head, a block more than a third of megabyte would almost certainly have more bitcoin in fees than the block reward.  If the minimum fee, the max block size, or the fee schedule were to change in the near future (which I think is likely) then that is also likely to change.

These are artificial limitations on the miners. As you say, the fee schedule will change in the near future: Miners will accept a transaction if the fee covers the cost of electricity to process it and reject it if it doesn't. Do you disagree with this?

Give the above supposition, there is no time limited resource! fees will converge to zero. (actually the cost in electricity to process, which itself converges to zero with hardware improvements)

Your argument rests on the assumption that miners will maintain a set of artificial limitations on fee acceptance policy for which they have no obligation or incentive to abide.

[just_someguy]

For the 101st (assuming a 1/100 difficulty ratio), the miner would have to weigh the additional hashing cost (which effectively slows down the miner or pool's generation rate) against the fee associated with the additional transaction. 

Adding the additional transaction does not slow the hashing since only the 80 byte header is hashed.
I would think any fee at all would make it worth including in the block.

[MoonShadow]

These are artificial limitations on the miners. As you say, the fee schedule will change in the near future: Miners will accept a transaction if the fee covers the cost of electricity to process it and reject it if it doesn't. Do you disagree with this?

I don't disagree, but I suspect that there are more factors than the obvious ones.

[Stefan Thomas]

Why? It translates to the payment of actual fees. If miners self-interestedly accept all profitable transactions that willingness will fall through the floor and with it the actual fees. That's normal competition and how all market prices work.

I was recently doing the business plan for a double-spend insurance firm. The firm would charge merchants who need protection from double spends and can't wait for lots of blocks a fee and in exchange would guarantee transactions. It's rates would be tiered based on delay, so there would be a fee for 2-sec guarantee, 5-sec guarantee, 10-sec guarantee, etc.

The costs for such a firm would depend heavily on the number of double spends, so it would seek to minimize them. The more double spends happen, the more money it would be willing to spend on double-spend defense. One of the measures it would do is to pay miners for guaranteed inclusion in their blocks. If double spends happen more, it would pay more miners more money, if double spends happen less, it would pay less miners less money.

Note that such a company would also watch very closely for network takeovers, as it would have to carry potentially significant costs if somebody takes over the network and starts double spending or rejecting transactions.

I think this is the missing feedback loop that connects mining income with network security.

[Mike Hearn]

Yeah, that sounds a bit like the plan I was proposing for people to submit their transactions directly to a miner without broadcast. The attached fee would pay for a certain amount of hashing, eg 0.01 BTC per 100 gigahash of work done. The more hashing you pay for, the faster your transaction gets buried in the chain.

One problem with my proposal is that "gigahash of work done" is a very technical unit that is difficult for people to understand in terms of business risk. Insurance measured by the second is a much more elegant approach because the insurance company can do all the work of finding out how hard it is to rent black-market reversal rigs, how likely that is to occur for any given client, etc. The merchant just has to find an acceptable premium from a free market of insurers.

In other words, I think you nailed it. IMHO this is worth a separate thread, how about we split it out and discuss it further there?

[marcus_of_augustus]

Small note here. Relating hashing power and transaction costs in BTC, i.e., MHash per BTC and MBytes per BTC might be introducing unnecessary confusion.

These costs, hash power and transactions, are actually more closely fixed in other currency units (for now) and with rapidly changing valuations e.g., BTC/U$, fixing those computational costs in BTC is always going to create moving targets for the 'relevant' size of fees.

[Steve]

For the 101st (assuming a 1/100 difficulty ratio), the miner would have to weigh the additional hashing cost (which effectively slows down the miner or pool's generation rate) against the fee associated with the additional transaction. 

Adding the additional transaction does not slow the hashing since only the 80 byte header is hashed.
I would think any fee at all would make it worth including in the block.

Each transaction has to have a hash computed...so each additional transaction would add to the total amount of hashing required (since there is a minimum difficulty associated with every transaction).  The minimum for the whole block just means that up to a certain number of transactions, there is no additional cost.