Topic: CreateTransaction: suggest/enforce fee for big low-priority transactions - page 3. (Read 7919 times)

What would stop a well funded, bad actor from using a super computer to create blocks with only a few of it's own transactions in it?  Someone that wanted to undermine bitcoin?  I think it's a very bad idea for the network to not set some criteria regarding transaction inclusion into blocks.

Also, regarding another question (from twobitcoins) about whether there should be free transactions at all: first, I'd say that regardless of fee or no fee, dropped transactions are bad...it opens up a possibility of fraud and it will undermine confidence in the system (see the various postings of people wondering and worrying about what happened to their bitcoins if you doubt that).  It is correct that block generation is not free, but people will pay to get transactions into block sooner rather than later and these paying transactions will subsidize the free transactions and free transactions increase the overall value of the bitcoin network.

As for spam transactions, well, there is already a good solution that was proposed years ago to solve the spam dilemma...proof-of-work.  If you want to issue a free transaction, the network could require a small proof of work for such transactions.  The proof of work required for free transactions could even be linked to the current mining difficulty...the higher the difficulty for mining, the higher the difficulty require for free transactions.  There could even be a correlation between the transaction fee and the required difficulty (such that paying a small amount wouldn't eliminate the proof of work, but might let you buy down the difficulty).  And, you could even link that required fee to the average number of transactions in recent blocks such that a block containing only proof-of-work free transactions would amount to some total (say 50 btc)...so, for example, if the average number of transactions in recent blocks is 100, the transaction fee required to completely eliminate the proof of work requirement on any individual transaction would be 0.50 btc.  If the average number of transactions was only 10, then the fee would be 5 btc/transaction.  Clients wouldn't even forward transactions that didn't have the required fee or proof of work.  People could even offer services to compute the proof-of-work on behalf of users on less powerful clients (for a fee of course...or it could be a part of some larger account or hosting service that a user purchases).

The current client has default fees, but they are not enforced, so miners can change them if they like.  My proposal is the same.  Is that price fixing?

The current client has a hard limit on block size to prevent spamming by miners.  My proposal is the same.  If we ever bump into the hard limit, it becomes an artificial restriction on the rate of transactions, driving up prices.  Is that essentially equivalent to price fixing?

I guess I do worry that miners might allow block sizes up to the hard limit while charging no fees or too low fees (too low to compensate the rest of the network for storing that block for all eternity).  I'm not sure what to do about that.  The only solution seems to be for other miners to reject blocks that charge too little fees, which definitely seems like price fixing.

I would like to second this idea, or one like it. A consistent (small) fee for all transactions is ideal, then there's no problems with accepting some transactions as free, etc.

In the future when bitcoin is heavily used, I don't see any value in a "free transaction lottery".  It adds complexity for no apparent reason.

If bitcoin is underused, sure, free transactions are nice.  I just don't see any good solution to the spam problem, and it already seems that micropayments from pools are bumping into the limits.  I'm not sure it makes sense to invest in a system of free transactions that works in the short term if it will be obsolete in the long term anyway.

You're not suggesting price-fixing the fees, are you?

It is a natural consequence of the system that any free TX space will be used up, quickly, once bitcoin is popular.

Therefore, it is expected that adding a transaction fee will be strongly recommended simply to have one's transactions confirm in a reasonable amount of time.

"free tx" is just a nice feature while the bitcoin system is under-utilized.  Once bitcoin network sees more transactions on a daily basis, getting a slot in the free-tx area will be like winning the lottery.

I think gavin already has a 'refund transaction' patch in his repo somewhere.

Overall, I think transactions should have a maximum lifetime outside of a block.  If they exist past 24 hours or 150 confirmations, clients should drop the TX from their cache.

Hi,  I was affected by this issue too.

I'm totally new to bitcoin;  installed the Debian bitcoin-cli package yesterday, created a separate address from the default one (14mX4LPATYGqHqN16egft9dzwbjGy8j1Zc) and requested 0.05 from the faucet (txid e5017a6831e7034432ca033258254f3fda37ebae9c0de9765918380160d690cd) which has remained pending for almost 18 hours.

When investigating this I noticed lots of errors in ~/.bitcoin/debug.log like this:

Some of these partial txid's seem to 'cascade' on from one another, so I figured there was a dependency chain forming here.  I've managed to render this in the PDF below;  maybe that helps people to visualise what's going on.  If anyone else has transactions not completing, they may try searching for the transaction ID in the PDF document.  I found my transaction in there with at least 5 preceding it.  I count about 275 transactions in total at the moment, but I don't currently have the means to check if any of the displayed transactions eventually got processed.

• http://pyro.eu.org/stuff/bitcoin-txqueue.pdf

Hope this is somehow helpful!

Why do we think there should be any free transactions?  Of course free is nice, but is it workable?

First, even assuming there is no transaction spam, we must somehow choose an appropriate amount of free space per block.  If we make it large enough that all free transactions get into blocks, adjusting periodically as transaction volume increases, there will never be any fees, which doesn't seem sustainable.  If we limit it, we have usability issues.  How do people know when to include a fee?  An ever-increasing queue of free transactions seems likely.

Second, whatever free space we do allow will be consumed by spam.  It doesn't seem possible in general to distinguish spam from legitimate micropayment use cases.  And do we actually care?  If legitimate micropayments generate huge transaction volume, we probably don't want to allow them for free anyway.

Including transactions in a block has a real, non-zero cost.  If we charge a fair price, a lot of problems go away:

1. No more spam.  Or at least, spam is paid for.  If the price is fair, who cares?

2. No need to increase fees with block size.  If all transactions are required to pay a fair price, we can just include all transactions in a block immediately.

3. Everybody knows what fee to include to have their transaction processed promptly.

Granted, we still need some upper limit on block size to prevent block generators from spamming 1 TB blocks.

We just need to come up with a fair fee.  Filling 1 MB with 5000 200-byte transactions at 0.01 BTC each would cost 50 BTC, or about $50.  Perhaps that's reasonable.  At 0.0001 BTC, it would cost about $0.50.  That seems too low.  I was hoping we could tell people "transactions cost a hundredth of a cent" -- but maybe "transactions cost a penny" is good enough.

It wouldn't be expected confirmation speed, it would be expected block insertion speed.

Confirmations always happen every ~10 minutes, since they are blocks created after the transaction is inserted into a block.

I believe the network currently does not enforce that any certain transactions be placed into a block.  Miners already have the option to pick and choose which transactions to include according to whatever criteria they wish.  All they have to do is modify their software to do so, and it would still be fully within the rules of the bitcoin network.  The network only cares that the blocks and transactions are valid, not that the block includes transaction X and transaction Y, etc.  I'm not sure it's even possible to enforce that miners include all/certain transactions, since not every node is always aware of every transaction when a block is generated.

Most miners (including slush's pool) use Bitcoin's getwork, so default fees are important. The ability to modify fee rules would be nice, though.


Setting aside space for free transactions is needed because otherwise someone could waste lots of disk space by sending endless free transactions. The 4kB priority limit should be removed, though -- let the 27kB free space be sorted by priority. The free space should also be increased to 50kB, IMO.


Good idea. There should also be a manual reclaim ability.

I agree with caveden: I think fees should be entirely up to the miners.

I like the idea of offering a small (฿0.0001) fee for every transaction, but wouldn't that just lead to more dust and wallet fragmentation?

Alternatively, we could greatly raise the limits for free transactions, or raise their score if they're old so they can get outside the free transaction space. What are the problems with that approach?

Oh...one other thing...I would think it should be fairly trivial in the client to come up with suggested fees for desired verification speeds based on the recent block statistics...I could imagine a selection list in the GUI like:

   Transaction fee (expected confirmation speed):
       0.00 btc (>4 hrs)
       0.01 btc (~1.5 hrs)
       0.05 btc (~30 min)
       1.00 btc (<15 min)

I think this is a bad idea, possibly very bad...the network has to set the rules regarding what are acceptable blocks and what are not...and with that, what transactions those blocks must include.  If it's easy to create transactions that the issuer can be confident the network will drop, it opens the whole system up to rampant abuse and fraud.  If this were possible someone could easily craft bitcoin transactions designed to be abandoned and use those for payment...a person could obtain some good or service long before the unsuspecting victim realizes what has happened.  This is not a recipe that will engender confidence in the system.

Furthermore, this would put too much power in the hands of miners...it's the responsibility of the network to validate blocks and transactions and to decide what is acceptable and what is not.  Not the miners.  I cannot stress this point enough.  The miners will still have an equal role in setting the market rate for transactions (which is what I think you're after here).  Setting aside the current 50btc payout for blocks, if the predominate fee that people are offering is low enough, there will be little incentive to mine (based solely on the transaction fees)...so, mining activity will plummet as will the difficulty.  I think what you'd find is that it would get low enough that some merchant would realize they need their transactions verified and would press some old spare PC into service to do the mining (with the difficulty being low, it would be a very cheap thing to do).  They would be generating blocks for their own transactions and because of the rules enforced by the network, everyone else's as well.  He would prioritize his own transactions (but would have to remain within the guidelines of the network)...other merchants, needing the same service would either run a miner themselves, or start attaching a fee to their transactions.  And, soon, anyone wanting to see their transactions clear a little sooner than 4 hours (again, arbitrary number I picked) would start attaching a small transaction fee.  Conversely, if everyone is competing to have their transactions verified quickly and bidding up the fee for that, then more people will enter the mining business to capture a piece of those profits.

Ok, that makes sense. Changing the pool payouts would mitigate it, but people could still end up with fragmented wallets for any number of other reasons. How about a feature in the client to consolidate one's wallet. It would bundle up many of the small wallets and send them to itself. I really dislike the idea of changing the rules at this point.

You can generate a 1MB block with only free transactions in it and it will get accepted (maximum block size is 1MB, although the standard bitcoin client will never generate blocks larger than 500K).


The problem isn't the pool payout-- the problem is that people participating in the pool end up with wallets full of tiny (e.g. penny-size) transactions.  When they go to spend those tiny transactions, they're bundled up together to make a transaction that is small in value but large in size.

Pools can mitigate the problem by requiring larger minimum payouts (e.g. 1 BTC instead of 0.01 BTC).

That sounds like the pool needs to do it differently, not the network. If this is a pool payout to 500 people in a single transaction, then the pool needs to break it down into smaller transactions. I sent a few regular transactions yesterday and they were immediately included in solved blocks.

By the way, an important question: if I generate a 500KB block with only free transactions in it, it will be accepted by the network, right?
Or this current "default fee policy" is not just for the default client, but for the protocol as a whole?

Gavin, IMHO, transaction fee policy is a business to miners. You shouldn't care, unless you're developing a miner.

I think that the miner that comes with the default client should just be discontinued and removed from future versions. This way, there's no "default policy" and miners will create their own. If they want to accept free transactions they will, otherwise they won't, and they'll find their ways of prioritizing them.

The only thing that the client should be capable of doing is resending a transaction, with a higher fee.

It would also be nice too if the user could specify the transaction fee per transaction. The GUI could also allow different kind of inputs (absolute value, relative to the transaction size, relative to the amount etc)