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

I think I agree with carp on this point. After all, the amount in a spam transaction is not lost to the spammer, he can just self-send it. The fee however is lost to him.

I'm still not convinced we should remove amount from priority calculation, although I can't seem to find a good reason against it.

After all, we're not trying to maximize volume, are we? The goal is "merely" to have transaction processing that is effective and cost-efficient enough for users.

I'm quoting from #bitcoin-dev:

Less likely, but, I wouldn't completely discount the possibility.

The fee has the same effect though. If adding a fee gets faster processing, and you want faster processing, then you pay the fee right? Well, if you want to jump the queue with smaller values, thats fine but that means the fee will be a larger percentage of your total value.

That said, I doubt either of these effects is going to have much bearing on anyone's behavior in terms of what they send. If I make a transaction, it is either to consolidate btc into another wallet, or, its to pay someone for something. Either way, the amount I send is not going to be influenced here.... but the fee might be.

If sending a 10 BTC transaction has higher utility to me than sending a 10000 BTC transaction, why should the system care?

The only rational basis for fees is for the fee to reflect cost of processing (e.g. size in block chain, or number of inputs).

The Bitcoin faucet started paying this fee, to avoid the transactions being stuck. This has unclogged the blockage for other transactions too, by freeing up "free transaction" space.

The value of a transaction does have bearing.

People are far less likely to spam using 10000 BTC transactions.  Faster confirmations for bigger sums encourages use of bitcoin for larger amounts, which is always a good thing for the economy.  And as ArtForz pointed out, it encourages sending larger amounts per tx, which implies less block chain size for the same volume of currency flow.

How did all of those 0.0001 fees get into the transactions?

My thoughts exactly...the value of a transaction has no bearing on the cost to process it...so valuein has should have no bearing on priority.  I think the winning formula is to base priority on a combination of age, fee, size, and time since the last transaction involving one of the accounts in the transaction (to deal with the spam issue).  That last one should be carefully tweaked to better deal with the recent delay issues experienced with slush's pool.  This priority would govern the forwarding behavior of the clients.  In addition, clients should factor this priority calculation into the decision on whether or not to accept blocks.  Blocks that seem to be grossly out of alignment with these priority assessments should be treated with great suspicion.

I actually like this formula. Thinking about it in these terms, its basically similar to what I was trying to articulate, except with valuein added. Though, if you are going to use the fee, why not drop valuein? From a miner's point of view, why should a transaction moving 100 btc with a .01 btc fee be preferred to one moving 10 btc with a .02 btc fee? (assuming txsize is equal).

Otherwise someone with a lot of btc could dos the system with a bunch of large transactions that clog the front of the queue, and pay no fee at all. Admittedly this could require a lot of btc to accomplish, but it costs none, and the attacker could have stolen them or have some reason to invest alot in jamming the system.

On the other hand, if you drop valuein entirely, then he has to clog from the back of the line, or drain his attack fund with fees, which will go back to the miners.

Point taken.

A question: What would happen if we removed all special handling of "free" transactions, but still allow transactions with fee == 0.00 and somehow include the fee into priority value calculation (iirc fee is not part of that atm, it's currently "sum(valuein * age) / txsize").

Maybe "sum(valuein * age) * fee / txsize"?

In the current situation this might be better, because there's actually still space left in the blocks, just no "special space for free tx". So the network is not living up to it's transaction processing potential. If this is true (I might be missing something, though), this suggestion should actually be in your "tx should remain free"-spirit, because it gives more room for free transactions, right?

Another thought: I see in the code that after calculcation of priority value for each transaction, the dependencies of the ones that are included are pulled in. What about packaging transactions into groups by dependency first and then calculating priority values for these groups instead of single transactions? Would that change anything significantly?

So if I understand this right, you want to make "fee" actually "very very small sub-subcent fee". I do think that, in the interests of openness and truth, we should stop using the term free at that point. How about making it a very small percentage? That way, when (yes when... I become an optimist when I have a vested interest) the value goes up to the point that .0001 bitcoins is an average persons yearly salary (I can dream)... he can still use it.

Honestly, Bill Gates is known for having asked why a computer would ever need more than 640k. Early predictions on computers were that they would eventually take up even bigger rooms, 16 bit gave way to 32 bit, and now 64 bit architectures. Deciding on the limits of a system are notoriously hard.

I kind of like including some sort of time metric into it. Maybe a strict queue by score where the score starts at the base fee of the transaction, and adds that transaction fee again to the score whenever the client has drawn an increment of the max block size in bytes from the queue. Maybe instead of using the raw fee, the ratio of the size in k to the fee.

So low fee/byte transactions start out at the very back of the line, and slowly move up to the front. Then, the size of the backlog has a direct relationship to the size of fee needed to jump to the front of the line. Though, you can still buy your way into the middle easily, and that would end up being rather close to the front, since your tx would be in a "faster moving line"... which eases the drawbacks and just means, well yah.... shared resources are what they are.

And also from people who are abusing it, and are funneling cash back into their primary account, often without TX fee...

http://blockexplorer.com/a/8i3b7nXppE
(View transaction detail -- many 0.05 receipts.)

This came out just now in #111264 when someone 'unclogged the drain':
http://blockexplorer.com/t/APn3cXG9Z1

# Number of inputs?: 181 (Jump to inputs)
# Total BTC in?: 9.05  => 181*0.05
# Number of outputs: 2 (Jump to outputs)
# Total BTC out?: 8.72
# Size?: 32.661 kilobytes

IMHO though, if anyone could maliciously generate a comparable volume of free transactions, that's still a potential issue, even if the faucet is fixed.

Someone just unclogged the drain:

http://blockexplorer.com/b/111264

This is not about pool itself; pool is just one of the first case for large amount of tiny transactions. In my specific case, I can (in the future) include my own transactions into the next mined block for free (or with fees paid to myself .


I'll be happy with not spamming the network, but this is not the real problem; I solve my case somehow (rising sending threshold, including txes into my own block). But other people will hit the same problem later and maybe some of them won't be so kind to save Bitcoin network resources - so we're talking generally about general scalability of Bitcoin transactions and about the painless way how to avoid this. I think we all agree that current infrastructure for fee negotiation is not powerfull enough at this time.


I'm perfectly fine with that.

It would be also nice to allow specific fee for every single transaction using JSON RPC. Then I can quickly introduce new settings for pool users - they will be able to choose if they want to pay fees for their withdrawals or not. It effectively move the decision about spamming of bitcoin network from me to them. (I'm pretty sure that those people withdrawing every 0.1 won't select fees, but they can spam network from their clients with zero-fee transactions as well).

The pools contribute to the problem but currently the largest volume of transactions comes from the faucet.

I can see a possible use case for a "mass pay" feature, but that does not really solve the problem here, where slush is generating a bunch of free transactions.  The use of a mass-pay feature without paying a TX fee might result in creating a single transaction that is larger than the entire free-transaction area (27k).

You wind up with the same end result: stalled transactions.  The root cause of the problem is that the pool is generating a lot of work for the network, without paying for it.  This is called Tragedy Of The Commons, or less graciously, free-loading.

So, I would support the following tweaks,

• Convert 27k free-TX area to purely score-based, eliminating 4000-byte limit
• Make -limitfreerelay the default
• Add a mass-pay JSON-RPC method, provided that the user interface requires a TX fee parameter (NOTE: zero is a valid TX fee)
• Reduce dust-spam/fee triggers from 0.01 to 0.001

+1

It could also be the pool, which sends many little transactions that are dependent on each other. Ideally it would send them all in one transaction.


The protocol allows for a transaction and its predecessor(s) to be in the same block. The priority mechanism just prevents it from ever happening (for miners running mainline Bitcoin).

Transactions seem to be being processed 'up' the chain (the opposite direction of the arrows), albeit very slowly.  Usually only 1 in a block, but http://blockexplorer.com/b/111261 contained about 10 in a row (from the same chain).

ps. the green was my attempt to highlight transactions that have been confirmed, but my data for that was unreliable/wrong.

I'd suggest people look at this PDF, make sure we're fixing the right problem. This is a graph of orphan transactions showing dependencies. Note that there's a chain of 100+ transactions all dependent on the one before. Probablythis is the Faucet.

It goes without saying that a tx can't go in a block if it's predecessors are not in blocks. I wonder if a single faucet txn getting dropped could lead to a whole chain of them being blocked?