What's wrong with this picture?

[organofcorti]

I don't think DeepBit or Eligius are the problem - the problem is people want to use the network for free.

If that attitude doesn't change at some point and if paid transactions aren't given highest priority, then when block rewards cease the network hashrate will probably fall significantly and network security will suffer.

[1714060828]

1714060828

[1714060828]

1714060828

[1714060828]

1714060828

[1714060828]

1714060828

[eleuthria]

I don't think DeepBit or Eligius are the problem - the problem is people want to use the network for free.

If that attitude doesn't change at some point and if paid transactions aren't given highest priority, then when block rewards cease the network hashrate will probably fall significantly and network security will suffer.

The problem is the re-definition of "Free".  My understanding is that Tycho is looking at changing his pool's settings to include transactions that were being ignored.  As of right now, Deepbit only allows a small number of "free" transactions, BUT Deepbit considers transactions using 0.0005 BTC/KB  to be "free" currently, thus limiting how many it will put into a block.  At this stage of the network, that seems like a problem since the DEFAULT value is 0.0005 BTC/KB.

There are other problems with redefining what a "free" transaction is at the current stage of Bitcoin development:
1) There is no easy way to add a fee to a transaction with bitcoind or bitcoin-qt.  Basically bitcoin does it in the background, using the fee per KB you specified in configuration.
2) There is no easy way to know what fee your transaction will include (if any) until you try to send it using bitcoin-qt.  Using bitcoind will send it and just tack on the fee without telling you in advance.

[kano]

... and at this point right now when I post there are 4100 outstanding transactions in my memory pool ...

Edit: and after the last LP 20 minutes ago the count was 3426

Edit2: and after a '50BTC' block just now - still 3719

[Tittiez]

... and at this point right now when I post there are 4100 outstanding transactions in my memory pool ...

4400 Now.

[organofcorti]

I don't think DeepBit or Eligius are the problem - the problem is people want to use the network for free.

If that attitude doesn't change at some point and if paid transactions aren't given highest priority, then when block rewards cease the network hashrate will probably fall significantly and network security will suffer.

The problem is the re-definition of "Free".  My understanding is that Tycho is looking at changing his pool's settings to include transactions that were being ignored.  As of right now, Deepbit only allows a small number of "free" transactions, BUT Deepbit considers transactions using 0.0005 BTC/KB  to be "free" currently, thus limiting how many it will put into a block.  At this stage of the network, that seems like a problem since the DEFAULT value is 0.0005 BTC/KB.

There are other problems with redefining what a "free" transaction is at the current stage of Bitcoin development:
1) There is no easy way to add a fee to a transaction with bitcoind or bitcoin-qt.  Basically bitcoin does it in the background, using the fee per KB you specified in configuration.
2) There is no easy way to know what fee your transaction will include (if any) until you try to send it using bitcoin-qt.  Using bitcoind will send it and just tack on the fee without telling you in advance.

I follow that. Thanks for the explanation.

Going OT for a moment, I think transaction fee use might be easier if, as well as the current 'pick a fee' system, the client had an option that just listed "Priority 1", "Priority 2" .. etc which a user could select when sending a transaction and each "Priority" level corresponding to a particular fee/kb.

This would make it easier to judge how much of a fee should be considered for a given priority, and will make it easier for mainstream use.

[eleuthria]

I follow that. Thanks for the explanation.

Going OT for a moment, I think transaction fee use might be easier if, as well as the current 'pick a fee' system, the client had an option that just listed "Priority 1", "Priority 2" .. etc which a user could select when sending a transaction and each "Priority" level corresponding to a particular fee/kb.

This would make it easier to judge how much of a fee should be considered for a given priority, and will make it easier for mainstream use.

There definitely does need to be some work done on the current way fees are handled, and how they are shown to the user.  Ideally, the client would be able to show the following:

1) Currently known TX queue - How many transactions total, and how many have fees
2) Fee to send a transaction with low priority (current 0.0005/KB system)
3) A place to enter a higher transaction fee manually for the single transaction.  Ideally the client would give a suggestion of a fee to give the transaction a high chance of confirming.

[DeepBit]

Usually I'm including 50 Kb of free TXes in each block. That was more than enough until the recent flood.
Sometimes this free zone was enlarged to quickly clean the queue, but at this moment I don't think that current queue can or should be cleaned that way.

[Gladamas]

Usually I'm including 50 Kb of free TXes in each block. That was more than enough until the recent flood.
Sometimes this free zone was enlarged to quickly clean the queue, but at this moment I don't think that current queue can or should be cleaned that way.

Why is 0.0005/KB not sufficient for a transaction to be included in your blocks? At a rate of 10 minutes/block, and 35 BTC transaction fees/day, that equates to ~0.243 BTC transaction fees per block in extra income for you.

[DeepBit]

Why is 0.0005/KB not sufficient for a transaction to be included in your blocks? At a rate of 10 minutes/block, and 35 BTC transaction fees/day, that equates to ~0.243 BTC transaction fees per block in extra income for you.

Sadly I don't have enough hashrate to mine one block per each 10 minutes.
I think that including more free transactions is not worth the risk for me, especially for ~0.06 BTC per day (according to your numbers).

0.0005 BTC was set as default fee when USD/BTC was somewhere around $22, so it was at least one cent. Now it's not.
If people think that confirmation of their transaction worths less than one cent, then may be it's not that urgent and may wait a bit more ?

[Gladamas]

Why is 0.0005/KB not sufficient for a transaction to be included in your blocks? At a rate of 10 minutes/block, and 35 BTC transaction fees/day, that equates to ~0.243 BTC transaction fees per block in extra income for you.

Sadly I don't have enough hashrate to mine one block per each 10 minutes.

No, I was just saying that you would get 0.243 BTC extra per block you mine, you might not get every block, but for the ones you do mine you would get the extra money.

Just wondering, what is the disadvantage of including transactions in blocks? Internet transfer fees?

[Tittiez]

Why is 0.0005/KB not sufficient for a transaction to be included in your blocks? At a rate of 10 minutes/block, and 35 BTC transaction fees/day, that equates to ~0.243 BTC transaction fees per block in extra income for you.

I think that including more free transactions is not worth the risk for me, especially for ~0.06 BTC per day (according to your numbers).

No. 0.243 BTC extra per block. So if you Mine 40 blocks in a day your making a bonus of 9.72BTC approx.

[DeathAndTaxes]

0.0005 BTC was set as default fee when USD/BTC was somewhere around $22, so it was at least one cent. Now it's not.
If people think that confirmation of their transaction worths less than one cent, then may be it's not that urgent and may wait a bit more ?

This.

Bitcoin will need to move to a pay for performance model.  Paying a quarter penny (USD) for a tx should get you a quarter penny service level (which is we will do it when we get around to it).  While I am not as large as Deepbit I exclude all tx with fee less than 0.002 fee.  I also add 0.01 to all my outgoing txs.  Never had a problem with a slow or delayed tx for "some reason".

[Gladamas]

So, what is the problem with including low-fee transactions in blocks? Just want people to pay more so you can get more coins? Or are >2 MB files (block downloads) a problem for you?

[DeathAndTaxes]

So, what is the problem with including low-fee transactions in blocks? Just want people to pay more so you can get more coins? Or are >2 MB files (block downloads) a problem for you?

So what is the problem with not including a fee to ensure your transaction is in the next block?  Just want people to do more work for less so you can keep more coins?  Or is a fraction of a penny a problem for you?

[DeepBit]

So, what is the problem with including low-fee transactions in blocks? Just want people to pay more so you can get more coins? Or are >2 MB files (block downloads) a problem for you?

Actually yes, block size is important, otherwise I wouldn't care.
It's not like I want to get real profits from TX fees.

[organofcorti]

So, what is the problem with including low-fee transactions in blocks? Just want people to pay more so you can get more coins? Or are >2 MB files (block downloads) a problem for you?

Actually yes, block size is important, otherwise I wouldn't care.
It's not like I want to get real profits from TX fees.

... yet.

[kano]

They haven't needed to ... yet ... due to the fees they charge.

[organofcorti]

They haven't needed to ... yet ... due to the fees they charge.

I actually meant that when Tx fees make up the lion's share of miner earnings, DeepBit will want to get real profits from Tx fees.

[zvs]

They haven't needed to ... yet ... due to the fees they charge.

I actually meant that when Tx fees make up the lion's share of miner earnings, DeepBit will want to get real profits from Tx fees.

in addition to the fees they charge

[-ck]

I started a thread regarding the pool orphan rate and high transaction volume issue here:
https://bitcointalk.org/index.php?topic=88302.0