The minimum transfer fee is not trivial anymore

[Stephen Gornick]

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?

[1715299467]

1715299467

[1715299467]

1715299467

[1715299467]

1715299467

[1715299467]

1715299467

[tvbcof]

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.

[bitlancr]

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.

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.

[tvbcof]

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.

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.

[Insti]

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.

[caveden]

Miners are free to tweak their fee rules whenever they want. The real issue is the fixed anti dos rules.

+1

There should probably be a signed alert style message to update those outside of the regular release cycles.

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

[Rygon]

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?

[nonnakip]

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.

[justusranvier]

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!

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

[DeathAndTaxes]

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?

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.

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

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

[nonnakip]

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!

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

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.

[nimda]

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

[caveden]

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

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.

[DeathAndTaxes]

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

bitcoind only needs to make it configurable.

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.
 

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.

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.

[jgarzik]

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.

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.

[jgarzik]

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

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.

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?

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.

[jgarzik]

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!

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

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

[justusranvier]

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

[Gavin Andresen]

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.

[DeathAndTaxes]

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!

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

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

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.