Transaction Fee Clarifications - page 2.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: genjix on November 07, 2011, 12:04:57 AM

I don't use a fee and my transactions send/confirm fine.
http://blockexplorer.com/tx/f5cffc95a4a83c23cb9f666c7cf552f27d9845778bb09a98d5169c461483ba41#i3150376

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...

Quote

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.

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.

theymos

administrator

Activity: 5222

Merit: 13032

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.

genjix

legendary

Activity: 1232

Merit: 1076

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

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

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: theymos on November 06, 2011, 07:16:53 PM

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?

theymos

administrator

Activity: 5222

Merit: 13032

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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

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?

Topic: Transaction Fee Clarifications - page 2. (Read 3274 times)