why transactions with zero fee are preferred above one with 0.000139 fee?

[grau]

I have a transaction pending in the mempool since hours because it pays less fee than required, not zero. The fee should be 0.0002 but it pays 0.000139.

I would understand that it takes longer than those paying the right amount, but am pissed to see that transactions with zero fee are getting included but not this one.
This is just not logical.

[dserrano5]

I have a transaction pending in the mempool since hours because it pays less fee than required, not zero. The fee should be 0.0002 but it pays 0.000139.

I would understand that it takes longer than those paying the right amount, but am pissed to see that transactions with zero fee are getting included but not this one.
This is just not logical.

My understanding is that a tx with less than required fee is equivalent to a zero fee one, so it isn't more eligible to be included in a block than free ones. Agreed, doesn't sound very logical, but I think that's how it works.

[grau]

I have a transaction pending in the mempool since hours because it pays less fee than required, not zero. The fee should be 0.0002 but it pays 0.000139.

I would understand that it takes longer than those paying the right amount, but am pissed to see that transactions with zero fee are getting included but not this one.
This is just not logical.

My understanding is that a tx with less than required fee is equivalent to a zero fee one, so it isn't more eligible to be included in a block than free ones. Agreed, doesn't sound very logical, but I think that's how it works.

Yes, I think this is some case of premature optimization or socialist thinking. Transactions should be simply sorted by fee/KB and stuffed into the blocks until they fit.

[grau]

Two transactions with zero fee and ten times the size of mine (20KB each) are confirmed, but not mine with a fee of 0.000139.
This sucks.

[Abdussamad]

I have a transaction pending in the mempool since hours because it pays less fee than required, not zero. The fee should be 0.0002 but it pays 0.000139.

I would understand that it takes longer than those paying the right amount, but am pissed to see that transactions with zero fee are getting included but not this one.
This is just not logical.

What transactions require or don't require a fee is determined by a formula:

https://en.bitcoin.it/wiki/Transaction_fees

This means that if you have old coins you don't have to pay any fee at all. It is not a simple case of pay a fee and get confirmation, don't pay a fee don't get confirmations.

You should let the software decide what fee to pay because it takes all of this into account.

[grau]

I have a transaction pending in the mempool since hours because it pays less fee than required, not zero. The fee should be 0.0002 but it pays 0.000139.

I would understand that it takes longer than those paying the right amount, but am pissed to see that transactions with zero fee are getting included but not this one.
This is just not logical.

What transactions require or don't require a fee is determined by a formula:

https://en.bitcoin.it/wiki/Transaction_fees

This means that if you have old coins you don't have to pay any fee at all. It is not a simple case of pay a fee and get confirmation, don't pay a fee don't get confirmations.

You should let the software decide what fee to pay because it takes all of this into account.

I am fully aware of the rules and wrote the program that created the transaction. Yes, the program did not round up to 0.0002 as it should have. Still the behavior of the network sucks. Here the transaction for your reference. It's not beginners stuff:

https://blockchain.info/tx/a423f46be27389e966b82254cdc8c264dac485be4f66f16f7a7ddf9029d59e21

[DannyHamilton]

I am fully aware of the rules and wrote the program that created the transaction. Yes, the program did not round up to 0.0002 as it should have. Still the behavior of the network sucks. Here the transaction for your reference. It's not beginners stuff:

https://blockchain.info/tx/a423f46be27389e966b82254cdc8c264dac485be4f66f16f7a7ddf9029d59e21

As I'm sure you are already aware of,  if you don't like the current fee system, all you have to do is provide mining pools with an alternative block building algorithm and convince the pools that your algorithm will result in higher profits for the pool and the pools miners.

The reason pools use the current algorithm is because it is easy (has already ben created for them), and they have been convinced that it is the best solution.

[justusranvier]

Transactions should be simply sorted by fee/KB and stuffed into the blocks until they fit.

This isn't going to happen until the transaction volume gets much, much larger than it currently is.

Right now miners don't care about transaction fees because the block subsidy distorts their incentives.

[grau]

Transactions should be simply sorted by fee/KB and stuffed into the blocks until they fit.

This isn't going to happen until the transaction volume gets much, much larger than it currently is.

Right now miners don't care about transaction fees because the block subsidy distorts their incentives.

I agree miner do not care.

What pisses me off is that the 'reference' implementation yet again features a complex rule set with disastrous side effect if violated,
where a simple rule one would work better.

It is a serious blow to the reliability of the network that by missing some target fee with a few satoshi's confirmation does not get gradually slower, but just stops (in the subjective view of the user) working.

[justusranvier]

Actually full node operators will probably care about this before miners will. What if the relay rules were like this?

For paying transactions: Track fee/KB statistics over the last 24 hours and calculate what percentile new transactions fall into based on that data set. Refuse to relay the lowest 5% (configurable in bitcoin.conf).

For free transactions: Track bitcoin-days statistics over the last 24 hours and calculate what percentile new transactions fall into based on that data set. Refuse to relay the lowest 50% (configurable in bitcoin.conf)

[NanoAkron]

Actually full node operators will probably care about this before miners will. What if the relay rules were like this?

For paying transactions: Track fee/KB statistics over the last 24 hours and calculate what percentile new transactions fall into based on that data set. Refuse to relay the lowest 5% (configurable in bitcoin.conf).

For free transactions: Track bitcoin-days statistics over the last 24 hours and calculate what percentile new transactions fall into based on that data set. Refuse to relay the lowest 50% (configurable in bitcoin.conf)

Any system that implements a reward as you suggest will create a positive feedback loop with transaction fees racing to be as high as possible without any upper limit.

[justusranvier]

Any system that implements a reward as you suggest will create a positive feedback loop with transaction fees racing to be as high as possible without any upper limit.

No, it won't.

[NanoAkron]

Any system that implements a reward as you suggest will create a positive feedback loop with transaction fees racing to be as high as possible without any upper limit.

No, it won't.

Well, that's clearly a well-though out and thorough response.

I have a pile of transactions with fees. The bottom 50% don't get relayed. Everyone bumps up their fees slightly to ensure transmission. The bottom 50% don't get relayed. They try again with slightly higher fees. The bottom 50% don't get relayed. They bump their fees up again.

Lather, rinse, repeat.

[justusranvier]

Well, that's clearly a well-though out and thorough response.

I don't feel particularly obligated to give a reply that is more thought out and thorough than the message that proceeded it.

I have a pile of transactions with fees. The bottom 50% don't get relayed. Everyone bumps up their fees slightly to ensure transmission. The bottom 50% don't get relayed. They try again with slightly higher fees. The bottom 50% don't get relayed. They bump their fees up again.

Lather, rinse, repeat.

Spenders get more than one attempt per transaction. If we assume they aren't going to behave moronically, they'll move their bid in both directions, up and down, in order to hit their desired price/speed point.

[grau]

Well, that's clearly a well-though out and thorough response.

I don't feel particularly obligated to give a reply that is more thought out and thorough than the message that proceeded it.

I have a pile of transactions with fees. The bottom 50% don't get relayed. Everyone bumps up their fees slightly to ensure transmission. The bottom 50% don't get relayed. They try again with slightly higher fees. The bottom 50% don't get relayed. They bump their fees up again.

Lather, rinse, repeat.

Spenders get more than one attempt per transaction. If we assume they aren't going to behave moronically, they'll move their bid in both directions, up and down, in order to hit their desired price/speed point.

Unfortunately sender only have one shot. Should they underestimate the fee needed (as I just did), they face arbitrary delay during which funds are locked, since a subsequent attempt will be rejected by relay nodes as double spend. One can only wait until it confirms or drops out of the mempool. Both could be days.

I am also afraid that an automated adjustment will create a positive feedback loop in transaction fees, but think that it is inevitable, since hard coding some fee/KB can't keep up with changing environment.

[gmaxwell]

Because there are several trivial DOS attack against honest users of the network / nodes that arises if you prioritize non-zero-but-effectively-zero-fee transactions over high priority ones.  Miners are free to customize the threshold defined as effectively zero— it's a published and supported configuration setting.  Personally, I turn it up a bit— I think I am better rewarded in total for doing so.

[justusranvier]

Unfortunately sender only have one shot. Should they underestimate the fee needed (as I just did), they face arbitrary delay during which funds are locked, since a subsequent attempt will be rejected by relay nodes as double spend. One can only wait until it confirms or drops out of the mempool. Both could be days.

Only until 0.9 comes out. After that senders will receive failure messages that tell them why their transaction was rejected.

I am also afraid that an automated adjustment will create a positive feedback loop in transaction fees, but think that it is inevitable, since hard coding some fee/KB can't keep up with changing environment.

If markets were not a (the only) successful method of price discovery, we wouldn't be having this conversation because we'd be dead or living as hunter-gathers.

[ahmedjadoon]

May I ask how long it takes to process payments with zero fees?

[grau]

May I ask how long it takes to process payments with zero fees?

Just as long as it takes with insufficient fees. That was my OP point. Practically between 1/2 and 3 days (now).