Bitcoin Forum

I've been thinking about mining pools, the future for miners as Bitcoin block rewards drop, and transaction fees.

My hypothesis is that fees are currently quite low, supported by the 50 BTC reward for successfully finding a valid block.

I wonder if it would be useful for miners to publish their transaction rules somewhere? This could happen in the blockchain if we were to keep the messaging very short, or coinlab would be happy to host an API that let miners publish what sort of fees they require.

Thoughts welcome.

 

There's a pubsub mechanism built into the Bitcoin protocol. I think publishing some kind of standard fee rules template via it would be a reasonable use case for it.

All kinds of policies are possible, so that data structure would have to be quite flexible. Presumably miners would prove their hashpower by signing with keys from recent block coinbases.

That said, I'm not convinced user-provided tx fees will be how the network is funded in future. It's what Satoshi envisioned but it has the problem of network security being a public good - it's only strong if everyone works together, and individual fees do not incentivize that. I've been researching how to use assurance contracts to incentivize mining instead, which I think is a better route forward.

Before mining pool based fees become standardized the hardcoded fee rules need to change.


Currently there is no reason to pay any fee because most blocks are empty.  Lets say blocks are getting close to full.

There is no economic reason for anyone to pay more than 1 satoshi in fees.
There is no economic reason for a pool to reject any transaction w/ a 1 satoshi fee.

Thus under current fee rules (other than spam transactions) fees would be 1 satoshi per transaction. 

At even Paypal scale volume (100 tps) that nets about 30 BTC per year.  That is global (non spam, non young coin) fees for the entire year.
Current block rewards are ~2.6 million. 

The issue becomes that the network considers any fee to be a valid fee.  Likely there will need to be some "minimum fee".  This doesn't mean you can't send a transaction with no fee (free transaction) but if you DO include a transaction the fee must be at least x.

Until network fee rules are reworked it makes no economic sense for any pool to reject any transaction with any fee (even 1 satoshi).

Why do you assume that?

A pool operator will have hardware capable of validating X transactions per second.  Right now, with low transaction volume, X is much bigger than current transaction volume, no matter what kind of hardware the pool operator is using.

If we assume Bitcoin is successful, eventually the number of transactions to be processed will be bigger than X.

The pool operator will have an incentive to sort transactions by the fee minus how expensive they are to process, and drop transactions that cost too much.   (or maybe implement some more complicated strategy like Mike's assurance contracts-- I have no idea how it will evolve).


Miners have an incentive to lie about transaction fees to clients-- they want higher fees, so even though they might accept 0.001BTC for a transaction they might tell clients that the fee is 0.005BTC.

Clients should be able to get a pretty good idea of what transaction fees are needed (if any) to get a transaction into the block chain just by watching 'tx' and 'block' messages and seeing what miners are actually doing, instead of trusting miners to tell the truth about what they are doing.

Validation cost would be negligible per transaction.  Currently validation is done via un-optimized code.   OpenCL for CPU or GPU could be used to allow millions of transactions per be validated per second.  I don't see transaction volume growing in excess of Moore's law in order to create a bottleneck which would lead to pricing rising.

Correct me if I am wrong but the issue is there are two "steps"
A) validating transactions, creating merkle tree, creating block header
B) hashing headers until small enough hash is required.

Even w/ 100 tps task A is trivial.  A single GPU could handle a magnitude more.  The amortized cost per transaction is negligible.

Task B is computationally intensive HOWEVER there is no additional cost per transaction.  Meaning finding a block hash for 1000 transactions is just as easy as finding one for a single transaction.

Don't those two situations conspire to create a dynamic where a miner will accept all non-free transaction (as global transaction volume isn't a bottleneck).

If clients can submit transactions w/ 1 satoshi fee and have high confidence that all (or significant fraction of network) will include them in the next block then there is no incentive to pay more.  Why 1 satoshi?  Simply because they can't pay any less without transaction being free.


Simplistically I would argue the "cost" is less than 1 satoshi.  While transaction volume will grow the cost to validate a transaction (not solve a block) will actually decline due to Moore's law and improving pool software.

This is wrong.

If a user wants a >99% chance of his tx being included in the next block he'll need to pay more than the minimum required by the most expensive 1% of hashing power. This means that a pool with 1% has pricing power with respect to that user.

You assume having 99% hashing power vs 98% hashing power has value to some user.  With variance in block times 99% hashing power working on problem has no utility over 98%. 

Also a high cost miner STILL pays the same cost.

Say you make a pool which requires a 0.01 BTC fee per transaction.  ok so nobody pays a fee that big.  It still costs you the same amount to hash the block as the person who included the 1000 1 satoshi fee transactions.   Now you could say I won't hash blocks when there are no fees > 0.01.  Right?

What if you get 1 transaction?  Your revenue 1 x 0.01 BTC.  Your cost ... whatever your cost to hash a block.

If you are already deciding to hash a block the cost to include all non-free transaction (no matter how low the fee) is negligible.

Unless the pool is operated by an exchange or other service provider. Exchange will have at least two streams of fee income and cross-subsidize each other. This will break any simplistic calculations made with the assumption that Bitcoin is the only medium of exchange in the universe.

I'm not clear how we can just assess the blockchain to determine imputed fee structures as things stand, which I think is where Gavin was headed.

I suppose we could count up blocks that have only transactions < x btc fee, or x btc fee / kilobyte, and bucket them. That would give a sort of cumulative distribution function for how quickly you're likely to get a transaction out.

As things stand, BTC issuance matters most to miners, but I think we'll see fees go up when BTC issuance drops to 25 BTC. If I ran a mining pool, I would be considering posting speed 'guarantees', deterministic 'waiting times' for trannsactions... That is, 0tx fees will be processed on the bulk timeline -- daily. 1 BTC / kilobyte would get put through right away.

One comment here about miners and marginal value -- actually, transactions do cost mining pool operators a bit; they create new getwork responses, and those have to get pushed down to clients, and this adds latency, network and compute cost to the cluster. Mining pool customers talk a lot about stales, these are real costs to the network. A mining pool operator is probably currently incented to ignore nearly all transactions, honestly. I would guess that large pool operators are still largely motivated by maintaining the integrity of the blockchain, (although you might not think so if you read the complaints their customers have, yeesh!)

no, because the pool can simply verify the transaction, and include it in the next getwork. no need to get every worker new work.

I think this is a non-issue until we reach a point in time where the block reward is less than what we deem required to secure the network at an acceptable level.  Which means, acceptable network security should be determined.

Is the Bitcoin network "secure" enough for everyone at 8 TH/s?  Is it overly secure or under secured?

We pretty much bottomed out at about 8 TH/s when the price of BTC was hovering around $2.50.  So, one can extrapolate that in order to maintain that same level of hashing power when we reach 25 BTC block rewards, the price needs to double.  If the price is at $2.50 when block rewards hit 25 BTC, then we will likely drop to 5 TH/s, give or take (some more efficient miners may stay in the game to an even lower price point, so it wouldn't be directly halved).  So, is 5 TH/s acceptable to secure a $50M mini-economy?

Basically, a bottom-line "security" level needs to be determined.  It might be a linear or non-linear equation, given that computing power will increase year after year, thus it would be easier and easier for a potential attacker to obtain terahashes of power to stage an attack.  It might also be based on price, given that an attacker would have more incentive to stage an attack if the coins were more valuable.  But until we know how much computing power is actually necessary to secure the currency given a certain price and certain availability of computing power, we can't really determine how much transaction fees *should* be.

The good thing is, we have plenty of time to figure this out, because the network is vastly oversecured already (and with the recent price increase, will be further secured in the coming months).

I suppose someone needs to think hard from a criminal perspective, about how a potential hijack of the blockchain would be profitable.  Obviously, the price per BTC would tank directly after such an attack, so whatever was done would have to be done quickly, be untraceable, and be worth more than the cost of setting up such an attack.

I wrote a BIP on fees and how they could improve security a while back: https://bitcointalk.org/index.php?topic=51778.0. Unfortunately, it seemed like there were many unresolvable security flaws in it. I believe the concept of fee stablization is necessary to ensure security in event of attack.

What do you mean by "fee stabilization"?  Do you mean finding the right minimum fee to ensure a certain minimum level of security, then trying to get all of the major pools to agree to use it?

If we need $125/block (50 BTC * $2.50/BTC) to keep the same level of hashing power that we currently have if there were no block rewards, then we'd need 50 BTC in fees per block on average.  If we currently have an average of 25 transactions per block, then each transaction would require a 2 BTC fee.  And if that's the case, it essentially kills the currency's usefulness, which kills the value, which kills the miners.

So, we must eventually accept a lower level of hashing power relative to currency value.  Even at 1/10th the hashing power, we'd need 0.1 BTC per transaction to keep 800 GH/s online at $2.50/BTC.  Or, essentially, $0.50/transaction.

But, back to 8 TH/s.  We'd need $5.00/transaction to continue hashing 8 TH/s per $50M of total BTC worth with only 25 transactions per block.  With 500 transactions per block, we could drop that to $0.25/transaction.  I think most people would be willing to pay $0.25/transaction on most transactions.  But, this is assuming a requirement of linear growth in hashing power compared with total BTC worth.  If we said that hashing power didn't have to grow as quickly as the total BTC worth, then the fee per transaction could be dropped even further with a price increase.  And I think it's safe to make that statement, since the cost to stage an attack grows non-linearly with each increase in hashing power (larger datacenter needed, more MWatts needed, etc, and those aren't linear costs).

As it is now, if block rewards were replaced entirely by transaction fees, then transaction fees would have to be $5.00/transaction in order to maintain the same level of hashing power as we had when hashing power stabilized at $2.50/BTC.  To have fees lower than $5.00/transaction, we'd need to do one or more of the following:
- Accept a drop in hashing power
- Increase the price per BTC (by a good lot)
- Increase the number of transactions per block

All those models assume a system whereby fees are attached directly to transactions.

In the assurance contract model, people with an interest in network security club together to directly incentivize mining by creating transactions with nLockTime set to a future block number that contain only fees (output values of zero). For example, exchanges have an interest in secure, irreversible transactions because they could lose a lot of fiat money if a Bitcoin transaction is reversed. But MtGox/Tradehill/etc don't want to be the sucker who funds network security for everyone. By forming an assurance contract, the mining incentives only kick in once everyone has contributed. There are some nice contract protocols that allow you to do this in a zero-trust manner.

At that point, all you need to be included in a block is a fee that is slightly higher than the cost of verification, which is so close to zero that I doubt any miners will seriously bother to enforce it.

The level of network security would stabilize at whatever level the participants who care about security need.

Can you explain more about how this would work?

What do you mean by "everyone" contributing?  How is it determined who has to contribute and how much?

(edited to simplify this down to a better proposal: it was previously too complicated)

That's up to the participants.

A security assurance contract system could take the form of a new p2p network. Nodes (academics might call them "intelligent agents") are run by people with an interest in network security, like exchange owners and merchants. They are given some coins and configured with policies that say, for example, what the targeted network speed should be and how independent the agent should be.

A fully independent agent would simply observe that network speed has fallen below the target and then start broadcasting nLockTimed incentive transactions until speed picked up again. The problem with this configuration is you end up being the sucker who carries everyone else on his back. All other merchants and exchanges benefit from the security you're paying for. This makes you less competitive.

A more likely configuration is one in which the agent is not fully independent. When network speeds are too low, it calculates a guesstimate of how much extra incentive per block is required to get back to the target speed, and then proposes an assurance contract (broadcasts a message). The contract incentivizes a single block, so typically agents would propose them and agree to them constantly.

The proposal states what the size of the incentive is, and what block it will incentivize. The size is calculated by the agent according to how much money it thinks is needed to hit its target (it can look at incentives per block and historical network speeds/difficulties to calculate that), and any pre-configured limits set by its owner. The block is some block in the future for which the incentives are currently too low.

Other agents decide how much they are willing to contribute according to their policies. Most would have a simple policy - spend the money you are given as quickly as possible to achieve the target speed, but don't contribute more than X%. They announce their participation by providing an outpoint of some value. Once enough outpoints are announced to sum up to more than the total contract value, the contract is closed to new participants and each contributing agent provides its signature. The completed contract is then broadcast on the Bitcoin network, where miners will compete to claim it.

I still don't understand why anyone would contribute.  I understand that exchanges have incentives to continue operations, but if they can't cover the whole reward amount themselves, they may as well give up.  Trying to get a bunch of companies contributing in shares more or less equal to their marginal benefit from miners protecting the network is just going to be a mess.  Besides, you'd get stuck with a bunch of freeloaders who didn't contribute anything.

Also, even with 200k BTC/day volume, MtGox only makes 2,600 BTC/day in commissions.  That's less than 1/2 of the current block reward.  No way they're going to give up even close to that amount in "rewards" to the miners.

Sorry, I just don't see your theory working well.  It is still a bit confusing to imagine exactly how it would work to begin with though, so maybe I am missing some key details.

MtGox isn't the only entity that cares about network speed so they don't have to give up all their income. That's the point of the assurance contracts. It says "I agree to pay, if everybody pays". If not enough others agree to contribute, the people who were up for it lose nothing.

It may be that current speeds are too high. We haven't seen (as far as I know) any complaints about successful double spends. That implies to me that inflation is driving network security too high - we're effectively wasting energy. I'd expect to see occasionally successful double spends on a network funded entirely by fees, when people misjudge how much work an attacker is willing to do.

Ok, that was the part I was missing - that no one pays if not enough is contributed.

But, what happens to Bitcoin if the assurance contract doesn't go through?  Miners aren't paid, so transactions can't happen anymore (or at least happen VERY very slowly, as only the idealists who don't care if they lose money on mining would continue to mine).  If that were the case, people who still believed in Bitcoin might up and donate some BTC themselves to the contract, but then we're right back to where we started - the people paying the mining fees.

A successful double-spend would be disastrous, and cause most people to lose all confidence in Bitcoins.  I don't think it is something we should be wishing for (though I do see where you are coming from on it).  I do believe the network is over-secured by a vast amount, but that is why I also believe that, so long as the number of transactions per block picks up some and people are willing to accept higher fees in the $0.25/trans range, fees can pay for a sufficient number of miners to secure the network.

Again though, I don't think we need to worry about fees sustaining the miner network until we reach the 6.25 BTC/block point, because I think even 1 TH/s is enough to secure the network if all BTCs are only worth $50M.  And that's going to take a number of years yet, during which a number of miner-incentivising variables may change, such as transaction volume and BTC price.

I really doubt fees need to be that high.

Paypal for example is ~100 tps.  That is ~ 3.2 billion transactions per second. 

At 1% of that volume (320M transactions per second) we are looking at a transaction cost on the order of 0.08 BTC to generate current annual block subsidies.

If after 5 years Bitcoin can't even sustain 1% of the transaction volume of Paypal well it likely doesn't need much protecting.

I mean, that's kind of my point - this is really a useless conversation until we get closer to the time of block rewards being potentially unsuitable for maintaining enough hashing power on their own.

That said, I don't think it is safe to look at Paypal and how many transactions they process, then deduce future Bitcoin transactions based on that.  Bitcoin could forever be a niche method of wealth exchange.

But it really doesn't matter until we get closer to the 6.25 block reward (in my opinion, anyway).

I don't think we should set ourselves up for "a double spend is the end of the world". Payment reversals are so common in every other form of payment that "no reversals ever" is a standard far higher than it really needs to be. Miners are a way of managing risk. For instance, I think it'll be common in future for people to pass around free transactions without broadcasting them, until somebody in the chain of payments decides they can't totally trust the sender and broadcasts the entire chain, using the miners to lock it down.

Any given assurance contract is relatively small (for just one block). If the contract fails because nobody cares about that level of security, speeds will fall a bit until enough people care. It's self adjusting in that sense.

I think you mistake a double spend w/ a persistent 51% attack.

A single isolated double spend wouldn't even make a headline.

An attacker w/ 51% of the hashing power could build an attack chain in private for days or even weeks generating thousands upon thousands of independent transactions worth millions in economic value which would all suddenly be reversed. 

An attacker which wasn't seeking economic benefit could even widen the damage and chaos by using unwitting pawns.  Make a website offering free PS3, get names & addresses.  Find a merchant selling PS3 for Bitcoins.  Pay for them in the legit chain and reverse them in the attack chain.  Merchant waits for 6 confirms and ships these "independent" purchases and then a week later (when the product is gone) the Bitcoins "disapear".  Now multiply that by hundreds of other merchants over the course of weeks.

Tell me that isn't "the end of the world for Bitcoin".  It would be like VISA telling all merchants around the world they won't get paid for any transactions the week before Christmas due to a security glitch.

Yes, if somebody does repeated double spends with a large value, that would make the headlines indeed. But there are unlikely to be so many merchants with high value attacks that are possible.

I think your VISA analogy is flawed. VISA routinely tells merchants they are the victim of fraud and then fines them for the privilege. There isn't much they can do to protect themselves from such fraud other than invest in expensive risk analysis solutions that try to spot repeated abuse attempts. If you're the victim of a double spend on Bitcoin, you at least don't get fined, and you have the option of ramping up your contributions to network security via the assurance contracts (assuming such a system is built and becomes widespread).

A double spend is the end of the world for Bitcoin in my book.  One of the key features of Bitcoin is that it can't be messed with or manipulated.  As soon as a double spend happens, then anyone who thinks about submitting a large transaction has to worry about it being reversed, either maliciously by the other party, or as a side effect of someone else doing a double-spend elsewhere.  You (and any companies that deal with Bitcoin) would have to start tracking all spends and receipts to make sure none of it gets reversed.  And with a blockchain that is lightly and very variably defended, as it would be in the case of assurance contracts, it'll be all the more easy for someone with malicious intentions to overtake it.  If you only get 1 BTC per block in donations for your contract, then we suddenly only have 200GH/s protecting the network, which is a heck of a lot easier to attack and double-spend against than 8 TH/s.

I really don't think you'd find enough people volunteering to give up their Bitcoins to secure the blockchain.  That's like allowing people to send in whatever they feel like contributing to the government come April 15th.  There's a reason why taxes are forced, not voluntary.  We all benefit from the uses of tax money, but we're not all willing to contribute towards those benefits voluntarily.  Too many people just like to freeload on whatever is given to them.

Anyway, I'm still of the opinion that transaction fees will be the only way to support miners in the future.  Hopefully, the number of transactions per block will have increased greatly by then, and the fee per transaction won't have to increase by much.

On that note, I wonder what would happen if someone released a modified Bitcoin client that doesn't drop the block reward, ever?  Would more than 50% of people gravitate towards it and use it?  I doubt it, but it's possible...  IMO, that would be the best route to go, but it would surely be a disappointment to everyone who was looking forward to Bitcoin being limited to 21M coins.

Clients would need to upgrade.  Clients who may not mine and know inflation reduces the value of the coins they hold.
Also unless the change is nearly unanimous both networks will continue to exist and that will create huge usability issues and new user confusion.

I don't think we will ever see a breaking change to the protocol with maybe the exception of a flaw being discovered in one of the algorithms used by Bitcoin.

It would certainly take an epic campaign to try and convert as many users as possible.  And yes, it would fork things badly, cause a lot of disruptions ("are you using the old Bitcoin or the new Bitcoin?"), etc.  The only way to do it seemlessly is to get nearly everyone to upgrade their client before the block reward drop in 2012.

But, too many people believe in a deflating currency to make such a change.  Despite the fact that a currency that neither inflates nor deflates is the best way to go, and having the block reward stay the same would eventually create perfect non-flation.  Oh well.  :P

Oh dear. Then I think you will be disappointed at some point. I think a successful double spend resulting in some merchant losing money is inevitable. It's just a question of when, not if.


Bitcoin clients already track all this for you. The moment a reversal happens the software can notify you (within seconds, if need be).

I don't see why you believe the assurance contracts model is guaranteed to result in insufficient security. Not enough people care about network security? Well, then not enough people care, so being sure there won't be a double spend means waiting a long time (increase the attackers costs by forcing them to keep up with the best chain). Or just using a bank wire ;)

Switching the rules of the system to result in "indefinite inflation" won't happen and wouldn't solve your problem anyway. Right now the security of the system is derived from the entirely arbitrary exchange rate. If there's a crash in Bitcoin value, the system still has utility because people treat BTC as a proxy currency. But the network security would fall a lot. Fee based security is more adaptive in the long run.

Come on man.

1 merchant getting double spent via finney attack is a problem of one scope.

A persistent 51% attack involving hundreds of merchants and thousands of transactions which hit the network simultaneously causing significant real world losses, paralyzing future commerce, and dropping exchange rate 90% (or more) is a problem of an entirely different scope.

Nobody is going to spend the resources to 51% the network to steal a single pair of Alpaca socks.

Yes, and as I said, I don't think it will happen, for the reasons outlined in Satoshis paper.

Your proposed scenario results in the attacker gaining a lot of either physical goods or fiat currency (other stuff can't really cause huge losses to the seller), which takes significant effort to hide your tracks, and taking back the original Bitcoins. That's the point of a double spend attack.

But executing large, simultaneous double spends against lots of merchants simultaneously means you get the goods you bought .... and now have a pile of worthless Bitcoins, having destroyed confidence in the currency. In other words you bought the goods legitimately and destroyed Bitcoin in the process, meaning there's nothing else you can double-spend on. You also have a lot of fairly useless hardware, unless you plan to flood the second hand video card market.

The point of a double spend attack is to double spend. It by definition requires repeated abuse. An attack so successful it wipes out the system is a pyrrhic victory.

At any rate, I'd like to see more frequent checkpointing (downloading signed blocks of head blocks from a trusted server) to act as a backstop against gigantic re-orgs.

Well that is the whole point. 

There is no economical 51% attack.  The nature of the network, the huge cost, and limited direct financial benefit means the "danger" of an economical 51% attack is pretty much non-existent.

However the danger of a non-economical 51% attack still remains.  If it happens then Bitcoin is over.  The chaos, and economic losses will end this "experiment" forever. 

"An attack so successful it wipes out the system is a pyrrhic victory."
Unless your intent was to wipe out the system.  :)

I would definitely be gone from Bitcoin if there was a 51% attack.  It would kill value (down to the pennies of BTC) because no one could trust that their transactions wouldn't be reversed.  And once that happens, nearly all mining activities would cease (it would no longer be profitable, at all), making it incredibly easy to continue 51% attacks down the road.  Bitcoin would be pointless if anyone with malicious intentions was ever able to acquire more than 51% of the hashing power put towards Bitcoin, because it would just snowball into non-existence.

And you think it is inevitable?  Based on what?  Who has > 10 TH/s of hashing power they could stage an attack with?

I think you misunderstand a non-economic 51% attack.  There is no "bad" chain.

For example I spend 1000 BTC w/ you (you ship 1000 BTC worth of goods)
In the attack chain I spend 1000 BTC w/ SgtSpike (he ships 1000 BTC worth of goods)

Even if you can determine the second chain is the bad one do you honestly think Sgt Spike is going to support the chain where his 1000 BTC payment "disapears"?

Really?  Now imagine thousands of transactions across both chains. 


Which is why hopefully we will see the rise of "split pools". 

Similar to p2pool except w/ traditional payment system & pool infrastructure.

What makes deepbit an attack vector?  The fact that they had 3TH of hashing power?  No.  It is the fact that a single server gives ORDERS to 3TH worth of utterly stupid miners (the hardware not the people).  If the server tells them to double spend they double spend.

Take same deepbit but each miner generates block headers locally.  Deepbit is no longer a threat.  Hell they could have 7TH and still wouldn't be a threat.  Granted p2pool is even better because it is DDOS resistant but there is no reason that a larger pool HAS to be a threat.

True...

I don't see it as very likely, but probably more likely than someone procuring their own hardware to stage an attack.

Absolutely.

If a large government were to successfully disrupt Bitcoin via a 51% attack even just once, using their own hardware to do it, I can't imagine continuing to use it.  Governments just have too many resources to continue attacks, so I wouldn't be able to trust any future transactions made in the system.

If a 51% attack originated from deepbit with a DDOS on the other major pools, then miners would probably stop using any major pools to begin with.  Lots of mini pools would crop up, as the importance of the issue would be fully realized.  I can see continuing to use the currency afterward, provided there were no longer any pools that could be used in a similar attack.

Right, I understand.