(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.
Topic: Appetite for fee-rules publishing from mining pools? - page 2. (Read 2963 times)
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?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.
What do you mean by "everyone" contributing? How is it determined who has to contribute and how much?
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.
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.
I wrote a BIP on fees and how they could improve security a while back: https://bitcointalksearch.org/topic/bip-fee-structure-and-fee-adjustments-51778. 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
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://bitcointalksearch.org/topic/bip-fee-structure-and-fee-adjustments-51778. 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. 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 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.
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.
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.
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'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!)
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!)
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).
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. 
Until network fee rules are reworked it makes no economic sense for any pool to reject any transaction with any fee (even 1 satoshi).
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.
Until network fee rules are reworked it makes no economic sense for any pool to reject any transaction with any fee (even 1 satoshi).
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.
There is no economic reason for a pool to reject any transaction w/ a 1 satoshi fee.
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.
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.
Quote
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).
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).
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.
There is no economic reason for a pool to reject any transaction w/ a 1 satoshi fee.
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).
I wonder if it would be useful for miners to publish their transaction rules somewhere?
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.
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).
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).
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.
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.
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.
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.
Jump to: