Bitcoin Forum
December 07, 2016, 02:47:19 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Transaction Fee Clarifications  (Read 2840 times)
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 06, 2011, 09:18:55 PM
 #1

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?

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
1481122039
Hero Member
*
Offline Offline

Posts: 1481122039

View Profile Personal Message (Offline)

Ignore
1481122039
Reply with quote  #2

1481122039
Report to moderator
1481122039
Hero Member
*
Offline Offline

Posts: 1481122039

View Profile Personal Message (Offline)

Ignore
1481122039
Reply with quote  #2

1481122039
Report to moderator
1481122039
Hero Member
*
Offline Offline

Posts: 1481122039

View Profile Personal Message (Offline)

Ignore
1481122039
Reply with quote  #2

1481122039
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481122039
Hero Member
*
Offline Offline

Posts: 1481122039

View Profile Personal Message (Offline)

Ignore
1481122039
Reply with quote  #2

1481122039
Report to moderator
1481122039
Hero Member
*
Offline Offline

Posts: 1481122039

View Profile Personal Message (Offline)

Ignore
1481122039
Reply with quote  #2

1481122039
Report to moderator
1481122039
Hero Member
*
Offline Offline

Posts: 1481122039

View Profile Personal Message (Offline)

Ignore
1481122039
Reply with quote  #2

1481122039
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 06, 2011, 11:16:53 PM
 #2

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 07, 2011, 03:52:16 AM
 #3

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?

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
November 07, 2011, 04:04:57 AM
 #4

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

http://blockexplorer.com/tx/f5cffc95a4a83c23cb9f666c7cf552f27d9845778bb09a98d5169c461483ba41#i3150376
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 07, 2011, 04:30:49 AM
 #5

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 07, 2011, 01:53:22 PM
 #6

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.


Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
November 07, 2011, 02:31:04 PM
 #7

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.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 07, 2011, 04:14:31 PM
 #8

Take a look at about every single transaction on blockexplorer. Most of them have fees.
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.

And to avoid the tx-purgatory, we have the sequence numbers.
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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
November 08, 2011, 02:22:19 AM
 #9

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)"

Jan
Legendary
*
Offline Offline

Activity: 1042



View Profile
November 08, 2011, 12:37:43 PM
 #10

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

Mycelium let's you hold your private keys private.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 10, 2011, 02:24:16 PM
 #11

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?

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
November 10, 2011, 02:36:06 PM
 #12

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.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 10, 2011, 02:45:22 PM
 #13

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Jan
Legendary
*
Offline Offline

Activity: 1042



View Profile
November 10, 2011, 02:56:49 PM
 #14

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



Mycelium let's you hold your private keys private.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 10, 2011, 03:05:34 PM
 #15

You're close:  it is:

Code:
int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;

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

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Jan
Legendary
*
Offline Offline

Activity: 1042



View Profile
November 10, 2011, 03:18:59 PM
 #16

You're close:  it is:

Code:
int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;

You are also close, it is more like
Code:
int64 nMinFee = (1 + (int64)nBytes / 1024) * nBaseFee;
Wink

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

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

Mycelium let's you hold your private keys private.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 10, 2011, 03:37:45 PM
 #17

You're close:  it is:

Code:
int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;

You are also close, it is more like
Code:
int64 nMinFee = (1 + (int64)nBytes / 1024) * nBaseFee;
Wink

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
November 10, 2011, 06:57:12 PM
 #18

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
November 10, 2011, 07:02:37 PM
 #19

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. 

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
November 10, 2011, 07:21:19 PM
 #20

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!