Topic: The minimum transfer fee is not trivial anymore - page 2. (Read 9984 times)

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

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

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.

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.

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.

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.

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

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.

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

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

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.

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?

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

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.

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.

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.

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.

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?

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.

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