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

Hi, I made some further observations regarding the stalled transactions that started off this discussion (so hopefully this is on-topic) :


I then realised these transactions are being processed sequentially, only one per block:

• tx 8074fb67ce... was in block http://blockexplorer.com/b/111257
• tx 8ec51bbaf5... was in block http://blockexplorer.com/b/111258
• tx f9ccaa5e8b... was in block http://blockexplorer.com/b/111259
• tx 7dddd55332... was in block http://blockexplorer.com/b/111260

Any guesses tx dafce7d622... makes block #111261?

I find it very odd that exactly one transaction from this 'dependency chain' is being included into block.  Is this really the expected behaviour?  A mere coincidence?  Or something to be worried about?

My graph of 'dependency chains' I've observed in my debug.log is here:  http://pyro.eu.org/stuff/bitcoin-txqueue.pdf

Update: I think it's okay... in #111261 block, a huge chunk of items from that 'chain' I was looking at, made it into the block.  I guess there's nothing to be worried about.

Well, the quickest solution to the current problem would be raising the free space, I guess. Say, 3 times the current values... ?

Also, stop picking which transactions to relay based on fees... the transaction memory pool size is another matter*, but at least relaying all valid transactions should be the default behavior. But this I don't know if it would be quick to develop...

*By the way, why should a client which is not mining keep a transaction pool? Shouldn't we just leave it to the interested parties (sender and receiver) to rebroadcast the transactions once in a while if they look like "forgotten"?

Can we make it easier to create multi-output txn for peole like slush to distribute to large lists?

 That could save a lot of bytes both network and disk in the long run. pudinpop had custom ways of making them in his miner.

RE: limitfreerelay:

Agreed, that's better.  I think we should start soft-coding the amount that is considered "free" instead of hard-coding CENT, and make the default less than 0.0001 BTC.

Separate subjects:

The entire transaction memory pool should be size-limited, with lower-priority transactions dropped.

I agree with Steve-- free transactions are a HUGE selling point, and I think rational miners should realize that their bitcoins will be more valuable if there are more users.  And there will be more users if "free transactions" is a feature.  I think we can come up with a solution where "normal" transactions are free, but spam or abnormally complicated transactions (yes, like those bitpenny rewards pooled mining participants are currently getting once a day) "require" a fee (where "require" is really "if you don't include a fee your transaction will probably never be confirmed.")

And finally... we've got a problem right now; lets think about what fix(es) move us in the right direction quickly, or think about fixes that will solve the current problem (that we may need to undo/rework later).

It's not up to the client - specially, not up to the default implementation of it - to decide what are "useless" transactions or not. It's up to the miners. The clients should reject only illegal transactions, like double-spending, wrong signatures etc.

The block size wouldn't reach 100MB unless that was really needed. And if it's needed, clients would need to adapt anyway (ligthtweight clients or banks, whatever).
And such increase should be gradual, somebody there in the topic suggested making the maximum limit something like 110% of the average size from the last N blocks. It might be a good approach, in order not to increase too fast.

Anyway, I understand your concern.
Any chances of having the blockexplorer data provided via JSON and/or RPC/RMI/etc? Having an interface like that could make it easier for the development of such lightweight client.

This is pretty simple:

Agreed x 2

Lack of that size limit is really an unfixed DoS issue.

Having a memory pool size limit where transactions are removed based on priority would solve that, I think. Enabling the -limitfreerelay switch by default might also help (with lower minimum fees).

It needs to be simple for the user, yet effective for controlling spam.

How about a single setting in the standard client, that controls the fee per transaction input. The default can be something very low (0.0001 per transaction input).

That will also incentivize someone to write code to make the client's input coin selection more optimal, to the benefit of the network as a whole.

After IRC discussion, I became aware of transaction rate limiting as a means of mitigating the spam problem...I hadn't realized that before, but I think it's a pretty simple solution to the spam problem (much simpler that the proof of work suggestion I made earlier).

I don't agree with eliminating free transactions...in fact, I believe the likely trajectory of things is that transactions will be remain free (I mean just look at all the unprofitable mining that's happening now).  Merchants, exchanges and many others have an interest in facilitating transactions and will always step in to ensure they get processed, even the free ones.  In fact, everyone using bitcoins has an interest in free transactions.  It's a good selling point and a way to attract new users (and without new users, this experiment will fail).  I know this doesn't come as good news to those of you hoping to strike it rich through mining (though maybe there is a future for you in collecting fees from those merchants willing to subsidize the cost of mining).

Other than that, I agree with molecular's other proposals.  I will add that clients need to become smarter about prioritizing the transactions they forward to ensure the p2p traffic remains manageable and clients need to have a strong role in deciding which blocks are accepted and which are rejected (it would be bad if an attacker with a very large budget could buy the resources necessary to dominate block creation and prevent almost everyone's transactions from getting through).

My humble opinion - there is no free lunch. Every transaction must have a price. This price should be a constant, bound to current definitions of COIN and CENT.

Anything else is just a dream.

I disagree.  You cannot change that without vastly increasing the ability to spam the network with useless transactions.

I'm still against that. Until there is some out-of-band method for lightweight clients to be notified of their own transactions, the max block size must be kept low enough for everyone to keep up with blocks. It's not reasonable to expect every client to download 100MB per hour (or whatever).

Automatic adjustments might be OK if lightweight clients can find their own transactions without downloading full blocks. Then only miners would have to worry about network and disk space usage. But when the max block size is over 10MB, the massive disk space requirements (500GB per year) will cause there to be only a handful of miners, and at that point all the miners will be able to come to an agreement about block size with relative ease due to their small number.

Really? This is bad! It's not up to the client to decide that... at most, relay and then forget about them, but don't ignore them.


No, what I suggest is making such limit adjustable just like the difficulty factor, as a "network rule", not something a user could change. There in the topic I explain more: https://bitcointalksearch.org/topic/block-size-limit-automatic-adjustment-1865

The client has to do all the verification and processing for blocks/transactions, anyway, so I don't see the harm in providing the necessary info to separate mining software. It's certainly not something every mining program should have to handle.

Currently clients will not even relay transactions if their fees are "too low". This needs to be changed for the fee market to work.


The user should never be able to change the max block size without significant effort. You're pretty much guaranteed to end up on a separate chain sooner or later if you change this value.

Can't this code be just separated from the default client?
I don't see a reason to have a miner in the default client anymore... It's useless, since CPU-mining is useless, and besides, things like fee policy for instance are really arbitrary and may change during time. It would be better if the default client was there just to set up the "protocol rules" and nothing more.

Anyway, if we really need to set up a default fee policy, then definitely these free transaction limits should be raised.

By the way, I still think it would be a good idea to make the maximum block size variable, instead of a hardcoded constant as it's right now.


Yes, manual reclaim and manual resending, that should do it.

Digesting all comments, maybe this could a workable consensus:

 1.) remove "free transaction space" altogether. Argument (by many): free transactions are not going to make it in the long run anyways, where probably never intended to. This would generate a market for transaction processing by miners, which was intended from the beginning and will be their main income after generation ends. Regarding the pool issue: This moves the problem to the originator (where it belongs): the pool-miner receiving very small payments has to either pay the price by using higher tx-fee to spend it or avoid the problem by increasing his payout treshold. This also mitigates DoS attacks.

 2.) make smaller transaction fee (down to 0.0001) possible. Argument: 0.01 might be too much as minimum fee. There are poor people.

 3.a) Client should also warn about low priority transactions and suggest a fee to increase chance for inclusion.
 3.b) Make it possible to increase transaction fee of an already broadcast transaction. Argument: this would obsolete 3.a) and introduce transaction fees to users in a nice fashion (user sees transaction not being confirmed, user sees the fee is 0.00, some gui hint tells him he can speed things up by increasing fee)

 4.) Let existing backlog trickle in slowly, don't automatically expire or allow reclaiming of transactions in any way. Argument (by Steve): Expiring transaction would open up the possibility of clients deliberately crafting transactions to fail (in order to get something for nothing)

If someone can flood the network with free transactions to/from their own addresses, and there's no way to make sure legitimate transactions are unaffected, there'd soon be no such thing as a free transaction any more.  Would it be so bad to disallow them to conserve resources?  The difficulty I imagine, would be in enforcing a minimum fee that would be remain sensible as BTC's value varies.


As for requiring 'proof of work';  requiring a BTC value inherently does that (they could join a mining pool to do the 'proof of work', then use their earnings to pay the fees).

If you have enough CPU power to dictate specifically which transactions into a block, we have bigger things to worry about (double spending).

There are plenty of validity checks on blocks and tx's in the client.  It's just that fees are not one of those checks, permitting miners to choose their own policy.