Bitcoin Forum

Bitcoin adherents once advertised transfer of value "for free or trivial fee". This is no longer the case. The higher USD rates and standard Bitcoin transfer fee amounts make the minimum fee about 5 US cents. It makes micropayments effectually nonfeasible, and for a transfer as high as $0.50 that's 10% overhead, which is hefty.

Certainly that's far lower than Paypal minimums for instance, but average 1% per transaction for ordinary amounts above micro level is nothing to sneeze at.

Do the transaction fees currently offer significant addition to miners' incentive? If not, with the rising profits already from finding blocks, could they consider collectively lowering the standard minimum fee for the benefit of the network, even better adoption rates (if it needs any in the current crazy momentum :))? Would this become a more potential option when the block size is increased (because of transaction rate requirements -> miner profits)? The perfect fee amount for equilibrium of expansion rate vs. fee income is high science, and needs to be found by trial and error.

You are not required to pay any fee. It is up to miners to set the fee they will accept. I would think that competition for the fees will lower the minimal fee.

If I change my transaction fee to 0 in my client right now, how reliable would it be?

Sorry but that claim has proved to be hypocrisy. Nobody wants their transactions delayed by indefinite amount of time, possibly stuck in limbo. Knowing that, everyone who wants to transact successfully must include the minimum fee.

Instawallet (.01 BTC) and BTC-E (.1 BTC) need to fix the whole minimum withdrawal thing too.

It's true, the minimum transfer fee is no longer peanuts. I think this is here to stay. Check out this thread:

https://bitcointalk.org/index.php?topic=140233.msg1503129#msg1503129

Basically, they're saying that as the block sizes continue to increase due to increased transaction volume, there's going to be a sort of "market"  for getting your transaction accepted. If your fee isn't high enough, miners won't accept it. It's anyone's guess as to what the market-clearing value will be once this change hits home, and it will undoubtedly change over time.

It could be viewed as a good thing; ensuring that major blockchain users like satoshidice pay for their share of transactions. It also (in my view) leaves space for an alt-chain to step up as a leading space for micropayments; though said alt-chain would need to demonstrate that they won't run into the same problem as soon as e.g. sdice starts using them.

Hmm...  if the fees were explicitly in USD, everyone would be screaming it's a cartel between mining pools requiring higher and higher fees. And unlike a 51% attack, such a thing wouldn't be harmful enough to bitcoin to cripple mining's future profits. Thoughts?

Sorry if this is a clueless newbie question.

Incidentally making the market for limited blockchain space more visible to users is fairly high on the developers priority list. Basically that includes tools to determine how much of a fee the user needs to pay to get their transaction confirmed in a given time as well as ways to change their mind and resubmit transactions to increase the fees attached to a transaction if required.

Yes, I was implying that with the discreet suggestions for improvement before the yelling turns up...

That is no fluent way of making transactions. It is blackmailing people who need to transfer value, like the banks do nowadays.

Can anyone do an experiment right now where you send with a .0005 fee, then with a .0004 fee, and so on until .0000 and see if how long it takes for each transaction to go through.

Correct (mostly), if "microtransactions" is a transaction in the amount of a couple dollars or less.

A decentralized, proof-of-work based cryptocurrency is a very expensive network to maintain compared to a centralized system with a single "master node" / authoritative source.

With Bitcoin, each transaction (and microtransaction) gets transmitted to and stored on tens of thousands of nodes around the world.  Fees are the mechanism to regulate how much bandwidth and storage will be needed to operate a node.  

These fees do make business models that rely on microtransactions crossing the blockchain to become unfeasible.  There are remedies however.  Services that require microtransactions (e.g., online wagering, gaming, media consumption, etc.) can still use bitcoin units internally and then employ accounts so that the only blockchain transactions are deposits and withdrawals.   Most online wagering sites that use bitcoins already work in this manner and it seems to not be an undue burden.

Wallets with BTC redeemable codes are one way to move "off the blockchain".  Because these wallet services are centralized, these "redeemable codes" (electronic tokens) can be offered at a much lesser expense making it possible for a wallet operator to allow bitcoin-denominated microtransactions to be available without charging a fee.

Does anyone know how transaction fee cost-creep has been affecting SatoshiDice in recent weeks/days?

Thanks Gornick - however that doesn't answer our concerns of the miners using their authoritative position to squeeze an unhealthy fee out of the users. Unhealthy as from the viewpoint of the community coherence and project progress.

Oh well, I'd better be asking this from the miners' association, if there ever was one...

I changed my fee to 0.00001 BTC, only 1hour to get confirmated  ;)

Miners are free to tweak their fee rules whenever they want. The real issue is the fixed anti dos rules. There should probably be a signed alert style message to update those outside of the regular release cycles.

Where can we discuss these rules? A slow and bureaucratic process to lower them is not sufficient having the current situation as an example.

it's a little more complicated than that since miners might be looking at fees per kilobyte of data with some minimum thresholds for bitcoin-age.


Not as complete as what you're looking for, but:
http://bitcoinstats.org/

You can discuss them right here.  The rules are here:
https://en.bitcoin.it/wiki/Transaction_fees

Understand the purpose of the anti-spam/DOS fees are not to generate revenue, they generate a trivial amount of revenue.  The purpose is to protect an attacker with a modest of amount of funds (say $100,000) causing massive economic damage to the project by spamming nodes, and bloating the blockchain.  Bitcoin is somewhat unique in that everyone pays the "cost" of all tx (in the form of storage, bandwidth, CPU, etc).  The fee is designed to prevent someone from maliciously exploiting that characteristic.

It gets confusing but there are essentially two fees:
a) min mandatory fee (aka anti-spam, anti-DOS fee) paid ONLY on low priority tx
AND
b) the optional fee paid on any tx for faster confirmations

0.00001?  that's strange, i think very few nodes would relay that

you can change in the source code the cost of creation from .0005 to .0001 and it will be confirmed within a few blocks most likely.    0.0001 is the minimum relay fee, 0.0005 is the minimum creation fee.   0.0001 is 9/10ths of a cent

Has anyone had ideas about if/how a user could choose a particular miner, or basically somehow influence transactions to go to a particular pool with a statistically relevant preference?

The reason I ask is that there really are far fewer mining organizations than I would have hoped to see at this phase of Bitcoin's lifecycle, and few enough so that collusion seems like a distinct possibility under the right set of circumstances.  If the userbase could punish mining organizations who might be discovered to be engaging in collusion or otherwise acting against the best interests of the economy it could be a balancing force.  And possibly a healthy one.

Transactions are relayed to all peers, so I'm trying to figure out what you are asking.

Are you looking for a way to broadcast a transaction only to a particular pool and hope that the one particular pool will not relay your transaction with its peers and instead be the recipient of the fees when that pool eventually includes that transaction in a block?   Thus your "punishing" is simply denying the other pools of the fees?

You've described something along the lines of what I was asking, yes.

As a participant who is paying a fee for services rendered, it would not bother me to be able to influence who does the work and thus enjoys the fee I pay.  Philosophically at least.  More than that, though, I am interested in the potential to NOT have my fee going to a participant who is acting against my best interests.

Many of the (relatively few actual) transactions I've made are ones which I don't really care that much how fast they are confirmed, and ones which are large enough that I could justify a pretty hefty fee.  If I wished to support a particular pool for some reason, or wished to NOT support a different one, it would be kind of nice to select those for special treatment along the lines of what you describe.  Possibly through a proxy which handles the relay hack details or whatever.

Maybe you could do that with a clever transaction script, like a transaction output that can only be spent by a particular miner if your transaction is included in a block mined by that miner. If the block isn't mined by that particular miner, the transaction output could be sent back to you. Guess this would work like a conditional tip. Not sure if it's possible with the current implementation though.

I was thinking of something more along the lines of delivering the transaction to a miner, or set of them, through some back-channel.  Maybe they could include them in their block and if they got a solution, then transmit the trx slightly before advertising the block.  My understanding of the details of how timestamps and such work is to limited to understand if there is potential along these lines.  And, or course, I figure that if people have been thinking about it there are likely better ways along entirely different paths.

Create a transaction A
Output - To whoever
Change - To you.
Fee - To Random Miner.

Send change in transaction B
Output to Mining pool you want to support.
Change - None.
Fee - To Random Miner.


This way the mining pool is incentivized to make sure both your transactions end up in blocks, but it doesn't really matter who puts them in.
You'll just need to set your fees low enough to get your transaction relayed, and if you can submit your transaction directly to a miner you might even be able to avoid needing to do that.

+1


Wouldn't it be even better to stop using fees as anti-DoS?
Why can't we detect DoS by simply measuring the amount of data a peer is sending? If it goes beyond X KB/s, we stop storing and relaying transactions coming from this peer, eventually we disconnect from it and temporarily ban its IP locally. X could be configurable, in case there's a strong need to change the defaults without a release.

Would that be too difficult to implement?

I never liked this "fees as anti-DoS" thing....

In light of the rapid increase in value of BTC in other currencies, we’re gonna have to look at the fees and how to scale up the network to deal with smaller transactions. Right now, the standard 0.0005 BTC fee is about $0.05. It’s not that big of a deal yet, but it makes sending anything less than a dollar (0.01 BTC) somewhat expensive. And that’s before accounting for higher transaction volume

What will happen when the value of BTC gets to $1000 USD? The minimum transaction fee would be $0.50, possibly twice as high with additional traffic, which would make a $10 transaction have fees of 5-10%.

What I’m saying is that the definition of “microtransaction” changes as the value of bitcoin goes up. What the network sees as a small transaction could be a normal transaction for someone selling something like pizza for BTC.

There are some solutions like using codes (Mtgox codes), but those still have risk from a centralized location being compromised. Eventually even Satoshi dice will move to their own sub-network for transactions. But we're still eventually going to bump into the issue once the user base is large and value of BTC is high.

Perhaps the solution can also be a de-centralized sub-network that works similarly as BTC that deal with smaller transactions and only charge the standard fee when pulling out?

It is obscene that minimum tx fees are fixed BTC/KiB recommendations. This must be determined by individual miners! Miners must decide for themselves how much tx fees they accept. Miners need to be competing with each other on this. That was the original idea of Bitcoin. This will solve the problems of variable Bitcoin exchange prices by itself!

The clients have the blockchain. They can see what tx fees are being accepted how fast. Clients can use this as a measure to decide what tx fee should be used.

The problem is current client/relay/miner software has no automation to evaluate what is actually happening in the blockchain so users are forced to manually set tx fees. This must be improved. Let the Bitcoin marketplace decide minimum tx fees. Not developers with fixed-guess recommendations. And certainly not with fixed default settings in the software.

Miners can already do this. Most of them just haven't chosen to do so yet.[/quote]

Incredibly easy to bypass.  Ok so I want to spam (and by spam I mean bloat the blockchain by TB per week and make the unconfirmed memory pool run into the dozens of GBs) so I just make 20,000 new nodes (like say a botnet) and each on of them send for free a number of tx below the "limit".

If it worked for protecting the network it would also work for consensus of the blockchain.  There is a reason we have proof of work.  We can't trust a malicous user won't run more than one node.  If we could then you could replace the PoW with a simple vote.  If 51% of nodes say a block is good then it is good.

Then come up with a better solution however do understand we aren't just talking about "spam" in the traditional sense (i.e. a node blast the network with 10,000 tx per second) we are talking  spam in the sense of wasting critical resources which all users pay (in terms of CPU, storage, and new node sync times).

Correct. Because most users are sending tx fees based on recommendations. We must stop sending tx fees based on recommendations! Client/Relay/Miner software should default to 0 tx fees and use real miner demands to determine tx fees to use. We must force miners to start deciding what tx fees they want and stop giving them handouts.

If you do it correctly, you will only pay fees on microtransactions (sub 0.01 outputs). See http://blockchain.info/tx/bf2856852afba172a4c59fdd53e2f6630c4713981a78f4ab0d25c5228357fbea

The blockchain would not get that big since these transactions would never be included in a block. For block inclusion, miners have a strong interest in setting their own anti-spam rules, bitcoind only needs to make it configurable.

The problem is relaying. If your transaction doesn't follow the hard-coded anti-DoS fees it might never reach a miner which would be willing to include it.

Maybe the priority calculation should only come into place if you're receiving more transactions than you can relay without breaking the max KB/s value, or if your memory pool is full (configurable max size for pool).
But the priority calculation should not be "binary" (has enough fees, doesn't have enough fees), but rather a way of knowing which transactions to discard first (normally the attacker's transactions would be the firsts discarded, unless he's willing to spend money on his attack, in which case it'd be more of a donation to miners than an actual attack).

Do you see my point? I realize it would shift from "hardcoded minimum fee" to "hardcoded max bandwidth/memory consumption", but at least the latter seems more coherent with anti-DoS purposes. It would also need to be updated once in a while to reflect increases in available resources, but that happens less often than bitcoin's price movements IMHO.

bitcoind is already configurable however miners have never been very good at looking at true cost.  Also Bitcoin is somewhat unique in that the miner gets the profit but the cost is shared by all users globally forever.  This leads to a scenario where miners can make very poor decisions that affect all users.  There is no free market, one can't boycot a particular miner so "bad" decisions are at least partially rewarded.

For example many miners would happily include spammy garbage tx as long as they pay "something".  The true cost is externalized but the miner making the bad decision increases his/her bottom line.

I think this is a common misconception miners can already configure block inclusion rules using bitcoind.

the min fee (on low priority tx for nodes to RELAY the tx is only 0.0001 BTC (about 1 US cent at time of writing).
the min fee (on high priority tx) for nodes to RELAY the tx is 0 BTC.

miners are free to include any tx they wish in a block.  A miner could even advise users sending spammy, bloated, free tx to send them directly to the miner to bypass min fees for RELAY.  Of course no miners has an incentive to do this but if you wanted you could start mining and have users send you their garbage tx directly.
 

I never said that FEES MUST BE USED TO FIGHT MALICIOUS USE.  I simply said your initial proposal was lacking.  Remember Bitcoin is like a car in motion.  The developers are like mechanics forced to fix and upgrade the engine without cutting off the ignition first.  When thinking of an alternative it is better to start with "how can this be abused" rather than thinking "how can this be used".  The min mandatory fee is inelegent (in the software design use of the word) but it does work.  It makes malicious attacks on the network non-economical.  

You seem to be indicating that fee & priority should be combined.  There should just be one priority and it can be based on a lot of things (coin age, UXTO set reduction, fee paid, etc).  That likely is a start however some other components are necessary.  
a) miners need a way to be able to see downstream fees (allows receiver to spend 0-confirm with a fee to get both tx included)
b) clients need to provide an accurate prediction for users otherwise the end result is lots of cheap users just spamming network w/ tx which never confirm (which helps nobody not even the user)

Gavin has indicated that the fee model needs to be improved however until now it hasn't been a high priority.  The min-mandatory fee on low priority tx isn't perfect but we should be cautious in changing it.  It does currently act as a safeguard and also prevents users from doing something foolish.

Because we are a decentralized network :)  You can instead connect to 20,000 peers, and send one tiny spam through each.

Requiring some minimal cost to send a transaction, even if 1 satoshi, is a very elegant solution to spam.

However, as many others have noted, having a fixed fee schedule is too rigid, too inflexible.

It is widely agreed that the default fees need to be adjusted.

However, standard disclaimer:  bitcoin is not, and never will be, a micro-payment or micro-transaction network.


Yes, this is called "off-chain transactions" and it is a very good, very realistic solution.  No matter how much bitcoins scale up, there will always a market for micro-payments and micro-transactions.  It is predicted that micro-payment services, bots and networks will appear to handle this use case.

Yes and no.  Miners select which transactions appear in a block...  but clients choose which transactions to relay to other peers.  Most clients will not even relay spam transactions (for obvious reasons... they are spam).

Nothing stops a pool from running a subscription-only bitcoind instance via which users can submit any transaction they want directly.

Here's the thumbnail sketch on the code that I think needs to be written to handle fees properly:

1). Memory-limit the memory pool-- the set of transactions waiting in memory eligible to be included in a block. Matt Corallo has been working on that.  The limit should be a small multiple of the median block size of the last few hundred blocks.

2) Use the same algorithm/parameters/etc for adding transactions to the memory pool that we use to fill blocks.

3) Only relay transactions that fit into your memory pool.  This is the DoS prevention, your transaction won't get relayed if your node doesn't think it will end up in a block soon.

4) Estimate minimum transaction fee / priority needed to get into a block, based one:
    a) At startup:  the transactions in the last few blocks
    b) If you've been running long enough to "warm up" your memory pool:  transactions in the memory pool

5) Expose the estimate in the GUI's "suggested transaction fee" dialog.

All of that will give a floating fee that will change based on how many transactions, at what priorities/fees, are currently waiting to get into blocks.

There is one more change I'd like to make that is independent; re-define "dust" based on the floating transaction fee (e.g. a dust output is any output with a value of less than 1/4 the minimum fee-per-kb required to get into one of the next 6 blocks).  And make any transactions with dust outputs non-standard, so they're not included in the memory pool or relayed.

However the min-fee to relay low-priority (spam) tx is much lower 0.0001 BTC (0.1 mBTC) which is currently about 1 US cent.  There probably is no reason state there is a "min-mandatory" fee for inclusion in a block (0.0005) as it isn't exactly mandatory.  Miners are free to ignore that.

Certainly.  Eligius will send non-standard transactions that include a certain set-by-Eligius fee.  Because non-standard transactions are not relayed, you must submit such transactions directly to Eligius.

I wish more miners would offer services like this.

D&T made the same remark, to which I responded above. You'd had to filter which you would relay, and then priority vs fees kicks in. The only difference is that it's not a binary decision (has/hasn't enough fees to get relayed), it's just a way of sorting what gets relayed from what does not. You may end up relaying a transaction that today would not be relayed if there's enough "room" for it.


That's nice, better than what is done today and better than what I was saying above. Much more flexible. Nice. :)


Why not applying the same logic you described above? (they only get dropped if they can't fit in your memory pool)

Because dust outputs are more trouble than they're worth. They bloat wallets, cost more in fees to spend than they're worth (unless you go to ridiculous lengths to spend them), and are abused as a side-channel-in-the-blockchain-communication-mechanism.

If I could go back in time, I would go back and try to convince Satoshi to make them non-standard to begin with....

It is not difficult to spend dust. The problem is how bitcoind chooses coins to include. I modify my bitcoind to ignore "dust coins" when choosing coins for a transaction. Then after choosing enough non-dust coins it adds as many "dust coins" to the input as possible without pushing the transaction to the next KiB in size. This allows my wallet to stay relatively dust free automatically and does not cause extra tx fees.

Because dust have a unique cost.  They likely will never be spent.  They just remain part of the UXTO forever.  So more dust is continually being produced but none (or very little) is being used in new tx.  Eventually on a long enough timeline the UXTO (pruned database) will run into hundreds of TBs.  It makes Bitcoin far less scalable than if the UXTO remained spendable outputs.

Well that isn't exactly true.  It is possible the inclusion of the dust input lowers the priority making it low priority and thus mandating the min mandatory fee.  While improvement in coin selection is a good thing each input uses roughly 200 bytes.  You can't include many dust outputs without increasing the tx size.   Merely removing one or two dust outputs from the UXTO every couple days is like emptying the ocean with a teaspoon.  A single martingale SD player can generate a thousand or more new dust outputs in an hour or so.

There is no realistic reason why someone would need to send an amount less than the min fee.  I mean it is like mailing a penny to someone (at a cost of 46 pennies).  That small limitation would make the UXTO more efficient (a higher % of the outputs in the UXTO will actually be used in a future tx).  Note I am not saying coin selection shouldn't improve and priority should take into account uspent output reduction but something bigger is needed.

Hopefully alt-coin developers take note of the lessons learned.  Or wait never mind there is no innovation to make a better coin they are just weak "I want to be richz" attempts.  Well someday someone will try to make a superior coin and hopefully they spend 6-12 months studying bitcoin to actually make a better coin.

What they're worth and how they're supposed to be used is not up to any single individual or group to decide.
Dust may be used as a way to send messages. Dust may be used in Smart Property contracts. Whatever.

My point is that what you're making here is a "judgement of value", and that's not up to the Bitcoin infrastructure to make. It's the users that should choose how they spend their coins. As long as they pay for the service being provided (and whether they're paying enough or not is up to miners to decide), and as long as the infrastructure is protected against attacks (DoS), everything is fine.

Please don't embed judgments of value in Bitcoin's backend.


I thought it was you that came up with the concept of standard and non-standard transactions.... it was there since the beginning?

Satoshi invented that concept later.

That said, I think we should be able to get wallets defragmenting themselves. Miners have an incentive to keep the output set small so there's no reason not to accept transactions that consolidate coins of their CPU is otherwise idle, which most of the time it is. It just needs smarter rules and software.

Then how would you know when sending a transaction if you need to include a fee or not?

edit... I hadn't yet read Gavin's first post. That does sound like a much more elegant solution.

+1.000001

I agree x10000! I was thinking the exact same thing just before  ::)

+1.000011

The developers agree with you.  Where is the code submission?  Pull requests to do this are welcome.

Oh, rest assured, I'm taking notes.

(Not that I'm an altcoin developer... yet.)

One suggestion here is to have an option in the GUI to add the dust created by a transaction to the transaction fee.

+1

The only way around that is to have some kind of charge for storage of coins in the transaction set. 

Maybe add a 1 satoshi fee to every transaction output into the mining fees.

This actually won't be that hard to work out.  The UTXO set is already held in memory as some kind of map.  You just add that count times 1 satoshi to the max allowable mining fee.

Second when a transaction is spent, you just have to look at what block the transaction was in to see how much value it has lost.

Another option would be to block old coins from being spent unless the network is notified first.  There could be a specific protocol message for that.

Having said that, miners probably would unload dust transactions to disk anyway, and not store them in RAM.  If you tried to spend them, miners might have to look for the input in a slower data store.