|
grau (OP)
|
 |
February 09, 2014, 05:51:59 PM |
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
dserrano5
Legendary
 Offline
Activity: 1974
Merit: 1029
|
|
February 09, 2014, 06:58:02 PM |
|
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 (OP)
|
|
February 09, 2014, 07:14:36 PM |
|
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 (OP)
|
|
February 09, 2014, 07:37:50 PM |
|
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
Legendary
Offline
Activity: 3612
Merit: 1564
|
|
February 09, 2014, 07:43:49 PM |
|
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_feesThis 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 (OP)
|
|
February 09, 2014, 07:53:42 PM |
|
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_feesThis 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
Legendary
Offline
Activity: 3388
Merit: 4615
|
|
February 09, 2014, 08:44:52 PM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 09, 2014, 08:54:33 PM |
|
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 (OP)
|
|
February 09, 2014, 09:30:34 PM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 09, 2014, 09:40:00 PM |
|
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
|
|
February 09, 2014, 10:49:59 PM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 09, 2014, 11:33:50 PM |
|
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
|
|
February 10, 2014, 12:56:27 AM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 10, 2014, 05:08:08 AM |
|
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 (OP)
|
|
February 10, 2014, 05:18:50 AM |
|
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
Moderator
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
February 10, 2014, 05:19:35 AM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 10, 2014, 05:26:27 AM |
|
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
Legendary
Offline
Activity: 1414
Merit: 1000
|
|
February 10, 2014, 05:28:21 AM |
|
May I ask how long it takes to process payments with zero fees?
|
|
|
|
|
|
grau (OP)
|
|
February 10, 2014, 06:26:20 AM |
|
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). |
|
|
|
|
|
