Pages:
Author

Topic: Transaction Fee Clarifications (Read 3274 times)

Jan
legendary
Activity: 1043
Merit: 1002
November 11, 2011, 02:12:18 AM
#26
@gmaxwell, just about what I wanted to say. Thanks.
staff
Activity: 4172
Merit: 8419
November 11, 2011, 01:20:50 AM
#25
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.

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.
member
Activity: 70
Merit: 10
November 11, 2011, 01:08:18 AM
#24
Wow people vs logic, sad to say which side I was born into
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 10, 2011, 03:27:11 PM
#23
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.  
legendary
Activity: 1050
Merit: 1000
You are WRONG!
November 10, 2011, 03:26:25 PM
#22
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
legendary
Activity: 1232
Merit: 1076
November 10, 2011, 03:24:56 PM
#21
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.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
November 10, 2011, 03: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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 10, 2011, 03: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. 
legendary
Activity: 1050
Merit: 1000
You are WRONG!
November 10, 2011, 02: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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 10, 2011, 11:37:45 AM
#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.
Jan
legendary
Activity: 1043
Merit: 1002
November 10, 2011, 11:18:59 AM
#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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 10, 2011, 11:05:34 AM
#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).
Jan
legendary
Activity: 1043
Merit: 1002
November 10, 2011, 10:56:49 AM
#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))


legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 10, 2011, 10:45:22 AM
#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.
legendary
Activity: 1232
Merit: 1076
November 10, 2011, 10:36:06 AM
#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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 10, 2011, 10:24:16 AM
#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?
Jan
legendary
Activity: 1043
Merit: 1002
November 08, 2011, 08:37:43 AM
#10
Very interesting thread. OP, please update the wiki on transaction fees (https://en.bitcoin.it/wiki/Transaction_fee) with your findings.
legendary
Activity: 1512
Merit: 1028
November 07, 2011, 10:22:19 PM
#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)"
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 07, 2011, 12: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.
legendary
Activity: 1232
Merit: 1076
November 07, 2011, 10:31:04 AM
#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.
Pages:
Jump to: