Bitcoin Forum

I have read a lot of posts about Tx fees, and I've been doing quite a lot of C++ diving into the Satoshi client to try to figure them out.  Here's what I have concluded, and I am hoping someone can verify/correct me.
 

• (1) I see lots of calculations concerning current blocksize.  If I ignore those calculations and simply focus on the tx-based fees, then even if my fee is lower than what would be computed with the blocksize info, the tx will still be relayed and put into other clients' memory pools, for inclusion in the next block that doesn't have such high volume.  In other words, if I don't mind waiting a block or two for inclusion, it's perfectly okay to ignore the blocksize components of that calculation.
• (2) MIN_RELAY_TX_FEE and MIN_TX_FEE are each set to 10,000 and 50,000 respectively (0.0001 and 0.0005 BTC).  I assume that MIN_TX_FEE is for miners to decide whether to include in a block, and MIN_RELAY_TX_FEE is for regular nodes/miners to decide whether to forward the block to its peers.  Is this a correct interpretation?  If so, then what happens to a Tx that doesn't meet the MIN_RELAY_TX_FEE when it is broadcast during a block with high tx-volume?  It seems that a tx that would otherwise be free on the next block, might have MIN_RELAY_TX_FEE enforced due to large blocksize and not forwarded to peers...?
• (3)  There are three conditions for a tx to qualify to be put into the free space of one the next blocks.  Those three conditions are:
    -- Sum-of-priority-of-inputs > COIN*144/250   (i.e. > 1 BTC, one day old)
    -- All outputs are >= 0.01 BTC
    -- Tx size is smaller than 4kB (or 3500 to be safe)
  If my tx satisfies all three of those conditions and I don't mind waiting a block or two, it's perfectly safe to send the Tx without a fee.
• (4)  Along the lines of (3), as long as my Tx satisfies those three conditions above, it doesn't actually matter whether it is 250 bytes, or 3000 bytes, it will still get into the free space of the next block if its priority is high enough.  On the other hand, if it doesn't qualify as a free tx, then I should pay MIN_TX_FEE or MIN_RELAY_FEE for each kB that transaction is.
• (5) Consider a 5kB tx with one output of 0.0001.  If I try send this tx with 0 tx fee, it will just be DOA at the first peer, even my own client won't add it to its own memory pool.  Then, it will be as if you never even tried to send a tx in the first place.  How does the client deal with this?  (or does the client even let you send such a tx?).
• (6) Has the tx-purgatory problem been fixed?  Is it possible to still send a tx that gets stuck in network indefinitely?

Sending/relaying a transaction never takes blocksize into account.

The latest version won't let you send transactions with incorrect fees. It can happen with old/modified/alternate versions that don't know the current fee rules, though. Transactions with too-low fees will be stuck at 0 confirmations for a long time.

Do you know the exact conditions under which that happens?  Is it just those transactions will never satisfy AllowFree() and don't include a fee? Or , a fee that is greater than MIN_RELAY but less than MIN_TX?  Does "relaying" a tx mean that it is added to the node's memory pool?

At the moment, I am relying on those three conditions to declare that a tx is fine to send without a fee.  Otherwise, I multiply MIN_TX_FEE by the number of kB (rounded down) to determine the appropriate fee.  Is this a safe strategy to use with a network full of 0.4.0 and 0.5.0 nodes?

I don't use a fee and my transactions send/confirm fine.

http://blockexplorer.com/tx/f5cffc95a4a83c23cb9f666c7cf552f27d9845778bb09a98d5169c461483ba41#i3150376

When Bitcoin sends a transaction, it makes sure the fee is greater than or equal to GetMinFee() with blocksize=1 and fForRelay=false.

It's probably pretty rare for a transaction to get stuck, since many miners rarely require fees. I never send a fee for my personal transactions.

Actually, that transaction was 0.01, which is the minimum output size not considered to be "dust."  You've have to send 0.00999999 or less to trigger the fee logic...

I recognize that what happens in practice is a lot different than what is in the Satoshi code. It does seem there will always be miners that will accept no-fee transactions, but there's also a history of txs getting stuck, too, so it's not impossible (unless some core logic changed, somewhere).  I'm developing a client for other people to use -- if there's a chance of this happening, I want to give the users every opportunity to avoid it.   Ideally, I implement the minimal logic that avoids tx-purgatory 100.0% of the time, and allow the "advanced" users to turn it off if they're willing to take the risk.

Take a look at about every single transaction on blockexplorer. Most of them have fees.

And to avoid the tx-purgatory, we have the sequence numbers.

Well, default behavior of the Satoshi client is to include a fee, unless the user explicitly selects otherwise -- which is why I think most of them have fees.  If the default fee is too low, they are notified that their tx may require a higher fee, and are given an option to include a fee more appropriate than the default.  I think most users just accept the fees because they are so small.

If I understand sequence numbers correctly, you would need a non-in-the-past locktime, and replacement would have to be enabled.  And in order to leverage it, you'd have to send all your transactions as not-final.  For a "standard" tx that is expected to be final from the moment it hits the network, I don't think sequence numbers do anything to alleviate the issue.

Again, all I'm trying to do is clarify that my interpretation of the client code is correct so I can offer fail-proof recommendations for when to include fees and how much.  I don't want to end with pissed off users that their 100 BTC tx has been sitting at 0 confirmations for 2 days, and it turns out it was because they combined 50+ inputs to create the tx with no fee, and the network relayed it but no miner will include it.

An answer I posted in a noob thread, what I gathered from the Wiki, how many confirmations required before resending coins is TX-fee-free:

Transactions need to have a priority above 57,600,000 to avoid the enforced fee in the official client. Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes:

priority = sum(input_value_in_base_units * confirmations)/size_in_bytes

For sending 0.05 BTC (5,000,000 base units) from one address, in 225 bytes (a minimal size, a one input, one output transaction with no remainder)

free when confirmations > 57,600,000 * 225 / 5,000,000 -- 2,592 confirmations

Having Bitcoins from multiple payments fund the transaction is where the "sum" in the formula above comes into play.

A more informative dialog in the Bitcoin client could be "This transfer requires a minimum .0005 bitcoin fee due to recently receiving the source funds, and the size of the transaction in bytes. This transfer would be free after xxx more confirmations (approximately xx days)"

Very interesting thread. OP, please update the wiki on transaction fees (https://en.bitcoin.it/wiki/Transaction_fee) with your findings.

By the way, I just tried to send 0.007 BTC without a fee and it didn't show up in the blockchain, even after 12 hours.  I then created a competing transaction, using the same outputs but not requiring a fee, and it went through immediately.  So it would seem that nodes didn't even add it to their memory pool without the fee (which is good, otherwise that output would've been in purgatory).

The client won't let you do this at all, so you have to construct the tx by hand in order to test test.  It looks like the client is using these rules, or something very close to determine when to allow a free tx through. 

One other question about this is:  what is the deal with zero-confirmation txs?  I didn't see anything about those requiring a fee.  Or is it only that they contribute nothing to your priority, so it would be okay as long as you have other inputs with priority above COIN*144/250?

You need to send it straight to a miner who is accepting no fee transactions. Your transaction didn't get propagated by the nodes who experienced it. Doesn't mean it can't get into the blockchain.

Well then, that answers my question -- these tx fee rules need to be followed, unless you plan to seek out specific miners who will accept these transactions.  For a regular client, there's no guarantees you will be connected to a node that accepts them, and thus the user will be very confused when their tx says "Sent!" but then an hour later nothing has happened.

If I am not in a position to calculate whether the a transaction could be in fact free, and I want to be 100% sure that it went through, would this be a simple/safe rule to follow?
fee = 0.0005 BTC * min(1, kbSizeRoundDown(tx))

You're close:  it is:


Which is like roundUp(txSizeInKb), using nBaseFee==MIN_TX_FEE(==0.0005).  However, if I understand correctly, that is the min fee for Satoshi-based miners to accept your tx to be included in a block.  You only need nBaseFee==MIN_RELAY_TX_FEE (==0.0001) to get the tx propagated through the network: and that should be enough for it to find its way to a miner that will accept sub-standard transaction fees.  Depending on what proportion of miners accept this fee, it could take a few blocks to get into the blockchain.  If you make 0.0005 the base fee, then all miners should try to include your tx in the next block.

Also, if you have any outputs that are strictly less than 0.01, you will need to include that MIN_TX_FEE or MIN_RELAY_TX_FEE regardless of tx size.  Similarly, if the size is small but not sub-cent outputs, you will still pay a fee for low-prioirty transactions (summing to less than 1-BTC-1-day old).

You are also close, it is more like ;)


OK, but this will also be covered by the above formula.

Actually, that's not correct.  I copied that equation directly out of the source code.  wallet.cpp:985.  For whatever reason, the source code uses 1000 instead of 1024.   Although in their defense, they never mention "kB" or "kilobytes", so they can easily argue they never intended to measure kB.

WHY THE FUCK ARE WE ALREADY SENDING FEES?

the idea about fees, are when miners does not get a high enough reward. they will not accept txs without fees.
miners are fucking getting 50btc, every fucking block. AND THEN YOU WOULD PUT FEES ON IT TOO?
FUCK NO!

wait till the block reward is about 12.5 btc, before even discussing fees. and how to implement them.

/sorry for my bad behavior.

That's just not feasible.  Remove all fees and then there's nothing stopping 'bad people' from flooding the network with millions of tiny transactions.  With the current limits in place, they could add about 1 GB of data to the permanent blockchain every week (about 150 MB per day).  It's not just for rewarding miners, it's also a security thing.  The current fee schedule is actually designed for this purpose, instead of for rewarding miners. 

hmm. im not paying, using a modified version of the client. and my txs are going though.

Yeah don't pay fees. They're a fucking scam and totally not needed. We already have measures in place to stop flooding such as prioritisation of txs. This whole fee business is the mainline client trying to set network policy instead of the miners who run the hardware.

i does not agree with the scam thing, but anything else: +1

If you read the previous posts in this thread, you'd see the exact conditions under which you are required to pay a fee.  Most casual users do not run into this case very often, and can get away without ever paying a fee.  

Wow people vs logic, sad to say which side I was born into

So, you're volunteering to come staff IRC and help people recover their unspendable funds when the priortization leaves their txn unprocessed for weeks, thus locking the inputs?

This isn't speculative, every once in a while some poor sod takes some bad advice given on this form and confuses it for an opinion by someone competent— they get away with it for a few weeks (after all, the overwhelming majority of txn don't get asked to pay any fees) but inevitably they show up on IRC asking for help recovering their wallet and we get to play the hex editing game.  Perhaps you're stitting on a stock pile of old inputs which have enough age that it's completely inconsequential for you. Great for you, but you'd also be unaffected by the fees.

This has absolutely nothing to do with miner's fee policy and everything to do with providing software which doesn't invisibly fuck over it's users.  Yes, better handling of stuck transactions is important and will reduce the need for the fee safety net, but it's not very clear how to do this without creating other kinds of traps and confusion— thus why no one has submitted patches to handle it yet. But if fees which are applied only rarely and only to TXN which look objectively like DOS attacks and which are less than the rounding error of a typical USD transaction (due to truncation to cents) are a problem for your bitcoin business dealings, then I don't think anyone can help you.

@gmaxwell, just about what I wanted to say. Thanks.