Not enough profits with 25 BTC reward to include more tx's?

[CIYAM]

Apart from the problem of recently slow block discovery times, on average the new blocks are only around 200K (containing around 200-300 tx's) despite a large queue of unconfirmed transactions.

As BTC is at record highs is it not possible for miners to be a little more generous and include more tx's (so the blocks are closer to the 1MB limit)?

Many are now waiting days for their first confirmation and it certainly doesn't look good for talking about scaling (if we want to keep saying zero or little fees - and I am not talking about dust or invalid transactions due to no fees when the spec requires them).

At least if there were some way to "add a fee" to an existing tx one could get it to process but instead now if you didn't set your client to include a mandatory fee you just wait, and wait, and wait.

[1715181427]

1715181427

[CIYAM]

Pool operators - a suggestion:

Create a pushtx equivalent so someone can send a TX *alternative* (that pays much more than the minimum fee) which you then decide to mine *despite* the existing non-fee (or very low fee) paying TX.

I would use this service and I am sure I am not alone.

EDIT: see the next post for an even simpler idea

[payb.tc]

an easier method for less advanced users would be to simply let the original 'free' transaction go through, but for a seperate payment to the pool.

(i.e. you pay the pool 0.001 btc and tell them which free tx you want them to include in their next block)

that way novices don't have to figure out how to resend a transaction (which as far as I know, bitcoin-qt won't allow)

[Barek]

Are those no-fee transactions that get ignored?

Because the minimum fee is what now? 0.0001 btc? I would call that little.

Where can you see the transaction queue and the unconfirmed transactions?

[mprep]

an easier method for less advanced users would be to simply let the original 'free' transaction go through, but for a seperate payment to the pool.

(i.e. you pay the pool 0.001 btc and tell them which free tx you want them to include in their next block)

that way novices don't have to figure out how to resend a transaction (which as far as I know, bitcoin-qt won't allow)

That sounds like a great idea. I read many threads complaining about non confirmed transactions for weeks and this would solve all of them as well as bring a bit of profit to the pools. Come one, pool operators - golden idea right here.

[CIYAM]

Are those no-fee transactions that get ignored?

Because the minimum fee is what now? 0.0001 btc? I would call that little.

It's mostly no-fee transactions - but understand the protocol does *not* require a fee depending upon the size of the TX and the age of it's UTXO's (so if you've set your bitcoin-qt client to not pay any mandatory fee then it won't unless a fee is *required*).

Where can you see the transaction queue and the unconfirmed transactions?

You can get this info from blockchain.info here http://blockchain.info/unconfirmed-transactions (currently nearly 3000) and the beeping of the confirmations may make that link more than a bit annoying (they should probably drop that *feature* from that page).

[greyhawk]

As BTC is at record highs is it not possible for miners to be a little more generous and include more tx's (so the blocks are closer to the 1MB limit)?

Generous? I ask you: What is the difference between a man and a parasite? A man builds. A parasite asks 'Where is my share?'

[deuce22]

is this mean bitcoin will be useless ? if no one are mining bitcoin are useless

[CIYAM]

is this mean bitcoin will be useless ? if no one are mining bitcoin are useless

Mining is happening - the problem is simply the delay of low (and no) fee transactions (which is basically needless if the miners would put in more low or no fee paying tx's into their blocks - we can't force them though which is why the suggestion to be able to "add a fee").

[Barek]

It's mostly no-fee transactions - but understand the protocol does *not* require a fee depending upon the size of the TX and the age of it's UTXO's (so if you've set your bitcoin-qt client to not pay any mandatory fee then it won't unless a fee is *required*).

To my understanding the transactions will eventually be included because the priority is a function of wait time? I can understand the miners. They eventually have to live on fees, so it is in their interest to train the users to include at least a tiny one.

You can get this info from blockchain.info here http://blockchain.info/unconfirmed-transactions (currently nearly 3000) and the beeping of the confirmations may make that link more than a bit annoying (they should probably drop that *feature* from that page).

Thanks, I missed that. You can disable the sound by clicking the speaker icon.

[DannyHamilton]

an easier method for less advanced users would be to simply let the original 'free' transaction go through, but for a seperate payment to the pool.

(i.e. you pay the pool 0.001 btc and tell them which free tx you want them to include in their next block)

that way novices don't have to figure out how to resend a transaction (which as far as I know, bitcoin-qt won't allow)

Great idea.  I'd love to see the largest pools implement this.  I'd definitely use it.  The great thing about his solution, is that it allows the receiver of the transaction pay the fee if they want to.

[Barek]

The great thing about his solution, is that it allows the receiver of the transaction pay the fee if they want to.

Seems complicated. The sender could just deduct it from the sent amount?

Besides, we are talking about fewer than 5 cents here.

[DannyHamilton]

The great thing about his solution, is that it allows the receiver of the transaction pay the fee if they want to.

Seems complicated. The sender could just deduct it from the sent amount?

Sure.  The problem is if the sender didn't realize this and has already sent the transaction.  Why should the receiver have to suffer from the sender's mistake.  The solution suggested would allow the receiver to receive the bitcoins quickly even if the sender screws up.

Besides, we are talking about fewer than 5 cents here.

Which is why many receivers and/or senders might be willing to pay the fee if there was a method to do so once they realized the mistake.

[Barek]

I understand what you mean. Agreed, a way to hurry transactions would be nice.

Just to help me understand. Isn't the default setting the inclusion of the fee? So a sender would actively chose not to include it, probably followed by a warning about the consequences. In that case, I would count the waiting as a learning experience.

[DannyHamilton]

I understand what you mean. Agreed, a way to hurry transactions would be nice.

Just to help me understand. Isn't the default setting the inclusion of the fee? So a sender would actively chose not to include it, probably followed by a warning about the consequences. In that case, I would count the waiting as a learning experience.

It depends on the wallet they are using.  Some wallets are better about encouraging a required fee than others.

Even so, the reference client, Bitcoin-Qt, defaults to no fee if the fee isn't required for spam filtering.  These transactions are relayed, but can still be queued up behind fee paying transactions resulting in extended confirmation times with no warning to the user at all.  As I understand it the next version of Bitcoin-Qt should be better about suggesting fees, but for now there are many transactions that are being created without a fee and without a warning to the user.

[CIYAM]

I understand what you mean. Agreed, a way to hurry transactions would be nice.

Just to help me understand. Isn't the default setting the inclusion of the fee? So a sender would actively chose not to include it, probably followed by a warning about the consequences. In that case, I would count the waiting as a learning experience.

There is no warning (assuming that there is no *required* fee) using bitcoin-qt.

[DannyHamilton]

There is no warning (assuming that there is no *required* fee) using bitcoin-qt.

An echo?  

Even so, the reference client, Bitcoin-Qt, defaults to no fee if the fee isn't required for spam filtering.
- snip -
there are many transactions that are being created without a fee and without a warning to the user

[IsaacGoldbourne]

Are those no-fee transactions that get ignored?

Because the minimum fee is what now? 0.0001 btc? I would call that little.

It's mostly no-fee transactions - but understand the protocol does *not* require a fee depending upon the size of the TX and the age of it's UTXO's (so if you've set your bitcoin-qt client to not pay any mandatory fee then it won't unless a fee is *required*).

Where can you see the transaction queue and the unconfirmed transactions?

You can get this info from blockchain.info here http://blockchain.info/unconfirmed-transactions (currently nearly 3000) and the beeping of the confirmations may make that link more than a bit annoying (they should probably drop that *feature* from that page).

I accidentally forgot to attach a fee. Wow.
https://blockchain.info/tx/da4ee56063e5ed03d957090c6b12f0490efbc67e7c5b908d0ca82ac3e8692eb3

[CIYAM]

An echo?  

Must have missed that amongst the other replies - but yes same point.

[TTBit]

an easier method for less advanced users would be to simply let the original 'free' transaction go through, but for a seperate payment to the pool.

(i.e. you pay the pool 0.001 btc and tell them which free tx you want them to include in their next block)

that way novices don't have to figure out how to resend a transaction (which as far as I know, bitcoin-qt won't allow)

Taking the fees out of the tx itself would also allow for pool subscriptions. I pay 0.01 to "BTC Miner" and get a set amount of transactions. It would allow for economies of scale, i.e. bit-pay could get a better rate per tx than the guy that processes 1 per month. Dust transaction sites would have a different agreement.

edit: sites like btc guild could also "guarantee" transaction times (say 60 minutes or your tx fee back) based on their hashing power relative to the network.