Transaction fee?

[MoonShadow]

Satoshi's client version 0.3.20 (and all previous ones) does not impose any fee.

Choose your favorite from here: http://sourceforge.net/projects/bitcoin/files%2FBitcoin/

You've got to be careful. The fee isn't 'imposed' to harm you. If you send without a fee when the current version wants it other nodes may consider your tx to be spam and not forward it.

The current vanilla client doesn't refuse to forward the transaction, but most miners are not going to include the transaction until it's old enough to qualify as a free transaction.  I believe that the current client defaults to a transaction fee, but that can be changed in the settings.  The vanilla client will refuse to create a transaction based upon an input transaction that is newer than 6 confirmations old.

Oh, my bad. I was sure that it was the others won't forward it. So a modified client can flood the network? Everyone will forward? Reference to a thread about the current state of this would be much appreciated.

I can't give you a reference, because I'm no more inclined to use the search function than you seem to be.  A modified client could only flood the network to a point, because there is a limit to the number of unique transactions any given client could produce from any given wallet.dat before it was forced to attempt to double-spend (which an honest client will not even try to do) and any transaction that attempts to spend coins that another transaction before it has legitimately tried to spend will be rejected as invalid, and not forwarded for that reason.  Since even a modified client can't send coins to himself that he has already sent to himself without the first transaction being included into a block, the 'spamming' of the network can only proceed at a pace dictated by the rate at which blocks are created and miners include free transactions into blocks.  Since free transactions generally require aging, such costless spamming is severely restricted.  A fee paying transaction would likely be included in each block, but the costs of spamming would be born by the spammer, and eventually he would run out of funds.

[1713527792]

1713527792

[1713527792]

1713527792

[giszmo]

The exact time depends on the value of each address and time.

The formula the client uses is:

Code:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

If priority is >57,600 there is no transaction fee.

This is an interesting detail for me. Is there a discussion going on somewhere on how to develop on this mechanism? How does the fee count into the equation?

For the network it is bad to have too many transactions and this priority is an effective flood protection ... to a certain extent. With 1M BTC I can still produce 1M transactions per day which is about 50MB  (if I don't do weird 1000 addresses to 1000 addresses transactions which might cost the basic fee) per day. For free.

Wouldn't it make sense to completely ignore the input value and take the transaction size for a fixed fee? From the user perspective we want to charge for the service which does not depend on the wealth being transferred but only on the effort to note down some numbers.

Each kB (which is about 2 transactions) will get stored forever on at least 10k computers and not only on the one miner's computer that accept it in the first place. 1kB*10k equals to something like 10MB web space which in turn would justify to charge 0.001$ or 0.0003BTC wouldn't it?
(A TB costs about 20BTC. A kB therefore costs 0.00002BTC=20uBTC.)
Which arguments go against such a fixed fee? With the 50BTC reward we have now, you can easily make it 2uBTC with both a flood-protection effect and a long time model removing all this uncertainty about fees.

Although I myself promoted Bitcoin as a tool for micropayment, it is and will never be fit to be that on a large scale. With 10uBTC fee for my transactions I could still do pretty small payments.

Continuing on that thought why should only the miner who packs a ridiculously large transaction into the block chain be rewarded while all miners have to live with it? I suggest to add all fees to a fee pool in the block chain and miners are allowed to reclaim 1% of that fee pool. Miners would then have an incentive to not build on chains containing blocks like this one. 330kB for 46 transactions and 0.24BTC fee mostly from old clients 0.02BTC as I suppose.

[DeathAndTaxes]

Wouldn't it make sense to completely ignore the input value and take the transaction size for a fixed fee? From the user perspective we want to charge for the service which does not depend on the wealth being transferred but only on the effort to note down some numbers.

The Bitcoin network has no idea what the useful portion of the transaction size is.  It only knows a transaction has x as the total input and y as the total output( including the unidentified change address).  The fee is x -y.

[giszmo]

The Bitcoin network has no idea what the useful portion of the transaction size is.  It only knows a transaction has x as the total input and y as the total output( including the unidentified change address).  The fee is x -y.

I don't understand. Ok, there is no "<fee>xy BTC</fee>" in the block. Maybe. Still the fee exists and clients and miners can calculate it.
Right now
the miner can decide what to do with any coins left over from all the transactions in "his" block, including the generation "transaction".
My suggestion was that
the miner can decide what to do with 1% of the coins left over from all the transactions in "his" and all prior blocks, including the generation "transaction". Within each transaction, the input must be bigger than the output by a magnitude of 20uBTC per kB the transaction takes in raw format.

[DeathAndTaxes]

I misunderstood what you were saying.

Yes that would work.   Gavin has indicated the current fee structure isn't intended to be "fair" or generate sufficient revenue to run the network.  Fees will need to change and the block subsidy declines.  The current fee structure is just intended to prevent malicious use of the network.  Think of it as a "payment captcha".

Longer term a more robust fee structure will be necessary.  The network has "real" and significant costs.  Those costs have to be paid for.   Currently it is 99% paid for by block subsidies but that will continually decline and by 2030 there will be no block subsidies.  A fee structure that is low but fair and generates sufficient revenue is a necessity.

[barbarousrelic]

It was my understanding that miners were not required to include any transactions in the blocks they process - they like to process fee-paying transactions for their own financial benefit, and that they process no-fee transactions only out of the goodness of their hearts (and a desire to see Bitcoin flourish.)

Is this accurate? And if so, is the 'priority' of older transactions only a recommendation, or are miners eventually required to process old, no-fee transactions?

[DeathAndTaxes]

It was my understanding that miners were not required to include any transactions in the blocks they process - they like to process fee-paying transactions for their own financial benefit, and that they process no-fee transactions only out of the goodness of their hearts (and a desire to see Bitcoin flourish.)

Is this accurate?

Yes

And if so, is the 'priority' of older transactions only a recommendation, or are miners eventually required to process old, no-fee transactions?

Miners are not required to process anything.  Technically if a miner wanted to be an ass they could mine empty blocks.

One thing is that if a transaction requires a fee because its priority is too low many miners will exclude it, also nodes will not forward transactions they consider invalid and thus many miners may never see the transaction.

The problem w/ fee structure longer term is there is absolutely no reason for a miner to exclude even a 1 satoshi transaction (unless the block is full).  Including = 1 satoshi in revenue, excluding = no revenue.  Nodes not forwarding isn't much of an issue as one could write a client that sends transactions directly to the major pools and bypass any nodes which would block the transaction.

So under current fee rules the fee per transaction will aproach 1 satoshi.  Current block subsidies are about 2,628,000 BTC per year.  If fees aproach 1 satoshi then to support the current network in fees would require 2.6M / 1E-8 = 260 trillion transactions per year.  That is about 8M tps (transactions per second).  To put it into perspective VISA average volume is ~4K tps and peak volume is ~10K tps. 

Obviously fees need to be higher than 1 satoshi per transaction to support the network.  We have plenty of time but some equitable solution to share the cost of running the network needs to be devised.  That is at a high level what we are talking about with fees.  What set of "rules" most fairly distributes the cost of running the network among the participants.

[Jan]

Satoshi's client version 0.3.20 (and all previous ones) does not impose any fee.

Choose your favorite from here: http://sourceforge.net/projects/bitcoin/files%2FBitcoin/

You've got to be careful. The fee isn't 'imposed' to harm you. If you send without a fee when the current version wants it other nodes may consider your tx to be spam and not forward it.

The current vanilla client doesn't refuse to forward the transaction, but most miners are not going to include the transaction until it's old enough to qualify as a free transaction.  I believe that the current client defaults to a transaction fee, but that can be changed in the settings.  The vanilla client will refuse to create a transaction based upon an input transaction that is newer than 6 confirmations old.

Oh, my bad. I was sure that it was the others won't forward it. So a modified client can flood the network? Everyone will forward? Reference to a thread about the current state of this would be much appreciated.

Clarification here: https://bitcointalk.org/index.php?topic=51081.0

[barbarousrelic]

It was my understanding that miners were not required to include any transactions in the blocks they process - they like to process fee-paying transactions for their own financial benefit, and that they process no-fee transactions only out of the goodness of their hearts (and a desire to see Bitcoin flourish.)

Is this accurate?

Yes

And if so, is the 'priority' of older transactions only a recommendation, or are miners eventually required to process old, no-fee transactions?

Miners are not required to process anything.  Technically if a miner wanted to be an ass they could mine empty blocks.

One thing is that if a transaction requires a fee because its priority is too low many miners will exclude it

But how can it even be known if a fee is "required" ? Isn't that dependent on the policy of whoever mines the next block, so it is unknown?

And since miners can choose for themselves which transactions they will include, and they will most likely make their decision based only on what gets them the highest fees, what is the function of "priority" as mentioned in this thread?

The exact time depends on the value of each address and time.

The formula the client uses is:

Code:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

If priority is >57,600 there is no transaction fee.

Basically it works out to 1 day for 1 BTC.   Larger addresses (not total wallet value) require less time, smaller addresses require more time.

I don't understand this - so the priority will increase when the transaction hangs around longer without getting into a block? Aren't transaction fees paid when the transaction is first sent, when you have no idea how long it is going to hang around before getting into a block?

[btc_artist]

There really needs to be a way to re-submit a transaction with a different (larger) fee, and have the previous transaction(s) ignored.

[DeathAndTaxes]

There really needs to be a way to re-submit a transaction with a different (larger) fee, and have the previous transaction(s) ignored.

There is.  It just isn't implemented in the mainline client.  The protocol supports multiple versions for the same transaction. 

[btc_artist]

There really needs to be a way to re-submit a transaction with a different (larger) fee, and have the previous transaction(s) ignored.

There is.  It just isn't implemented in the mainline client.  The protocol supports multiple versions for the same transaction. 

I did not know that.  Thank you.

[DeathAndTaxes]

But how can it even be known if a fee is "required" ? Isn't that dependent on the policy of whoever mines the next block, so it is unknown?

I mean required per the mainline client rules.  Sure miners can put free transactions in blocks that should require a fee but honestly why would miners do that again?

And since miners can choose for themselves which transactions they will include, and they will most likely make their decision based only on what gets them the highest fees, what is the function of "priority" as mentioned in this thread?

Currently the only purpose for fees is to avoid malicious transactions.  Period.  Bitcoin is a work in progress (including the fee structure).  The purpose of priority is to organize transactions of the same fee size in the event their is insufficient room in the block.  For example if there isn't enough room in a block for all free transactions those with higher priority will be confirmed first.

Today block subsidies are massive compared to fees and blocks are 99% empty.  There is no reason to every pay a fee for anything other than if the transaction has insufficient priority and thus miners won't include it for free.  Period.  Obviously that will change in the future but today fees exist solely to prevent malicious transactions.

I don't understand this - so the priority will increase when the transaction hangs around longer without getting into a block? Aren't transaction fees paid when the transaction is first sent, when you have no idea how long it is going to hang around before getting into a block?

The age in the formula is the age of the COINS not the transaction.  Yes coins keep getting older until transferred but at the time you submit a transaction you know exactly how old they are.  If the priority (based on age & coin size) is too low you need to pay a fee.  If you don't pay a fee then miners may exclude your transaction.

Remember this exists solely to prevent malicious transactions by making spam too expensive to be used effectively.

[giszmo]

The protocol supports multiple versions for the same transaction. 

Oh! Interesting! So I can broadcast several transactions that are in conflict and clients will not drop those that arrive later?
While at first I thought that sounded like facilitating double spending, it is actually pretty decent in order to detect double spendings

(I love bitcoin. Something to learn every day.)

[MoonShadow]

The protocol supports multiple versions for the same transaction. 

Oh! Interesting! So I can broadcast several transactions that are in conflict and clients will not drop those that arrive later?

Yes and no.  The versioning of a delayed transaction is only possible with the scripting mech, which doesn't actually exist in the mainline client yet.  So at present, the answer is no.  Also, scripting won't ever be free, becase you are asking miners to actually process something for you personally.  Expect higher fees for scripted transactions, but once implimented, scripted transactions will be able to do a great many cool things, many of which don't really have any direct equivilant in the real world.  Multiplely addressed coins is one of them.  You will be able to send the same coins to more than one address, and dictate to the future network that those coins can only be used again under your stated conditions.  For example, you could send them to a set of addresses, and require that the claiming address have an additional keycode; so it's like you are putting up a prize for a compatition.  Or you could require that more than one of the addresses must sign the next transaction, requiring that more than one of the recipents have to get together to spend the coins.  There are a number of ways that this scripting mech can be used to create escrowed transactions.

[barbarousrelic]

Sorry to threadbump, but I still have a question about this:

The purpose of priority is to organize transactions of the same fee size in the event their is insufficient room in the block.  For example if there isn't enough room in a block for all free transactions those with higher priority will be confirmed first.

Are the following statements true?

Priority is not meaningful at all right now, as blocks are nowhere near full.

The priority calculation is a thing that is built into some mining software, but not necessarily used by all miners.

A transaction paying a higher transaction fee will never have a higher priority than a transaction paying a lower fee.

[MoonShadow]

Sorry to threadbump, but I still have a question about this:

The purpose of priority is to organize transactions of the same fee size in the event their is insufficient room in the block.  For example if there isn't enough room in a block for all free transactions those with higher priority will be confirmed first.

Are the following statements true?

Priority is not meaningful at all right now, as blocks are nowhere near full.

No, because there is a minimum priority level for a transaction to be included into a block at all.  In practice, this means that a fee paying transaction gets a much higher priority than a free transaction, and a free transaction must have inputs of a certain age in order to be processed.  This not only limits spam, it encourages senders to add a small fee to the transaction for speed, particularly if the inputs used are very recent.

The priority calculation is a thing that is built into some mining software, but not necessarily used by all miners.

True, miners are not required to honor the priority system to process otherwise valid transactions.

A transaction paying a higher transaction fee will never have a higher priority than a transaction paying a lower fee.

False, I think.  I'm pretty sure that the priority number is something along the lines of ((number of confirmations for the newest input transaction included in the present transaction) + (transaction fee in BTC * arbitrary priority multiplier)) in which case, the higher the fee paid, the higher the priority number.

[barbarousrelic]

Thanks, Moonshadow.

I mistyped my last sentence - I meant to say "A transaction with a lower transaction fee will never have a higher priority than a transaction with a higher transaction fee."

[BTCurious]

Thanks, Moonshadow.

I mistyped my last sentence - I meant to say "A transaction with a lower transaction fee will never have a higher priority than a transaction with a higher transaction fee."

A transaction containing tenthousand inputs with a small fee, might have a lower priority than a 1-to-1 transaction with no fee.

[MoonShadow]

Thanks, Moonshadow.

I mistyped my last sentence - I meant to say "A transaction with a lower transaction fee will never have a higher priority than a transaction with a higher transaction fee."

Well, this is also false.  It's possible for a free transaction with all inputs very deep in the blockchain to have a higher priority than a transaction that pays the minimum fee with very recent input transactions.