It's to do with contracts, I think.
I've written up a description of how distributed contracts are supposed to work, but I wasn't 100% sure I got it right. So I mailed Satoshi and asked him to check my explanation. I'll give it a few more days as sometimes he is slow to respond. If I get no answer by the end of the week I'll post what I have anyway and we'll have to figure out the details together.
Topic: Post-inflation security - page 2. (Read 5030 times)
Yes, but it doesn't let you change the inputs. So you can't add more money into the transaction if it needs a higher fee, unless the recipient is OK with getting a bit less.
You're right, it seems. This seems strange to me - I would expect the outputs to remain identical instead of the input, so that someone who sees a payment coming in will know for sure it will either confirm, be replaced by something with the same effect (or remain in limbo forever...). Any reason why there is a requirement on the inputs remaining identical?
Yes, but it doesn't let you change the inputs. So you can't add more money into the transaction if it needs a higher fee, unless the recipient is OK with getting a bit less.
At any rate, there is still the problem of knowing how many fees to pay.
At any rate, there is still the problem of knowing how many fees to pay.
Payment to miners via fees has a number of problems. One is that you have to pick a fee up front and then broadcast the tx. If you pick too low and no miner accepts it your transaction stays pending forever. If you pick too high you waste money. There's no way to replace a transaction with a higher or lower fee one today and changing Bitcoin to allow it would be tricky.
The bitcoin protocol supports a version number in transactions, and there is code in the main client (though disabled) for handling this. I believe it should be possible to enable it again. This will allow you to create new versions of a transaction that override the old version as long as they are not included in a block.
I think it will be pools, who provide double spend protection for bitcoin billing: they will get payment in exchange on building block chain on blocks with "protected" transactions in case of double spending attempt. You make contracts with several pools to be sure you are well above 50%+, and you can accept bitcoins instantly.
And it's in the interest of such billing to publish transactions openly, so other miners could use them (or else they will be generating orphaned blocks in case of double spend attempts).
And it's in the interest of such billing to publish transactions openly, so other miners could use them (or else they will be generating orphaned blocks in case of double spend attempts).
Sure, I'm not saying the additional security is a bad thing. Just that if there was no inflation it wouldn't make much sense to have so much proof of work being done.
I agree that what will ultimately decide Bitcoin as a credible competitor to VISA et al will be fees. It's hard to know what they might be at this time.
Payment to miners via fees has a number of problems. One is that you have to pick a fee up front and then broadcast the tx. If you pick too low and no miner accepts it your transaction stays pending forever. If you pick too high you waste money. There's no way to replace a transaction with a higher or lower fee one today and changing Bitcoin to allow it would be tricky.
Another problem is that the most you can pay for with this is inclusion into a single block. It probably makes sense for important transactions to pay for more work than a single block would require, to bury it faster. You can't set up any kind of flexible business plan like this, eg, loyalty bonuses or whatever.
But the biggest problem is the race-to-the-bottom aspect of it.
I agree that what will ultimately decide Bitcoin as a credible competitor to VISA et al will be fees. It's hard to know what they might be at this time.
Payment to miners via fees has a number of problems. One is that you have to pick a fee up front and then broadcast the tx. If you pick too low and no miner accepts it your transaction stays pending forever. If you pick too high you waste money. There's no way to replace a transaction with a higher or lower fee one today and changing Bitcoin to allow it would be tricky.
Another problem is that the most you can pay for with this is inclusion into a single block. It probably makes sense for important transactions to pay for more work than a single block would require, to bury it faster. You can't set up any kind of flexible business plan like this, eg, loyalty bonuses or whatever.
But the biggest problem is the race-to-the-bottom aspect of it.
this model points the way toward evaluating bitcoin's capacity for success as the foundation for a payment system. if the double-spend insurance costs are lower for merchants in the steady state than the present transaction fees for visa and mastercard, it is likely a superior payments technology. if not, it isn't. the latter appears to be more likely without changes to the technology, but it is an empirical question.
Nice to see this important issue discussed.
Here is another (more simple, but maybe too simple... or unsound?) proposal:
Multiple bitcoin chains with different inflation rates, that enforce different security levels.
People could use a chain with high security (for faster transactions) and/or a chain with low inflation rates (to store gathered funds).
How does your proposed model compare with this one?
Looks like it provides a way to simulate the first option, but relying on a third party instead of another chain (and currency unit).
Here is another (more simple, but maybe too simple... or unsound?) proposal:
Multiple bitcoin chains with different inflation rates, that enforce different security levels.
People could use a chain with high security (for faster transactions) and/or a chain with low inflation rates (to store gathered funds).
How does your proposed model compare with this one?
Looks like it provides a way to simulate the first option, but relying on a third party instead of another chain (and currency unit).
I'm totally in favor of merchant insurance who take care of watching for double spends and insuring against them. IMHO it is pretty much the solution to the whole not-enough-miners problem. It allows merchants the security they have come to expect from more traditional sources and allows the merchants to "pay" the transaction fees on transactions sent to them instead of sent by them. I could also very much see such services rolled into a payment processor as part of the merchant contract/fees.
Recently there's been a lot of discussion of the "tragedy of the commons" with respect to mining when inflation gets low. It bothered me because it seems this is one part of Bitcoin that wasn't fully thought out ahead of time by Satoshi, which is unusual. I came up with the idea of miners being paid to work on a transaction by the gigahash, with more fees paid meaning quicker burial under blocks, but it wasn't a full solution for a bunch of reasons.
Yesterday Stefan posted this great comment in Jeffs thread proposing a smaller tx fee, I think it's worth pulling out into its own discussion.
"Paying miners for guaranteed inclusion" is another way of saying paying miners to work on a transaction, but this scheme builds on that idea to make it understandable for regular merchants. Rather than requiring people to understand what a gigahash of work means for them, a middleman handles those details along. They'd gather intelligence about what black market reversal miners are available, how much they cost, how risky any given merchant is etc. All the merchant has to do is find an insurer who charges a reasonable cost.
There are several differences in such a world to traditional Bitcoin:
Lately I became more and more convinced the difficulty is too high right now. Too much computational power is being expended to protect too little value, as a consequence of how Satoshi chose to distribute coins. It wouldn't surprise me if over time difficulty actually decreases quite a bit until it converges on the actual power needed to keep double spends to an acceptable minimum (not zero).
Yesterday Stefan posted this great comment in Jeffs thread proposing a smaller tx fee, I think it's worth pulling out into its own discussion.
Quote from: justmoon
I was recently doing the business plan for a double-spend insurance firm. The firm would charge merchants who need protection from double spends and can't wait for lots of blocks a fee and in exchange would guarantee transactions. It's rates would be tiered based on delay, so there would be a fee for 2-sec guarantee, 5-sec guarantee, 10-sec guarantee, etc.
The costs for such a firm would depend heavily on the number of double spends, so it would seek to minimize them. The more double spends happen, the more money it would be willing to spend on double-spend defense. One of the measures it would do is to pay miners for guaranteed inclusion in their blocks. If double spends happen more, it would pay more miners more money, if double spends happen less, it would pay less miners less money.
Note that such a company would also watch very closely for network takeovers, as it would have to carry potentially significant costs if somebody takes over the network and starts double spending or rejecting transactions.
I think this is the missing feedback loop that connects mining income with network security.
The costs for such a firm would depend heavily on the number of double spends, so it would seek to minimize them. The more double spends happen, the more money it would be willing to spend on double-spend defense. One of the measures it would do is to pay miners for guaranteed inclusion in their blocks. If double spends happen more, it would pay more miners more money, if double spends happen less, it would pay less miners less money.
Note that such a company would also watch very closely for network takeovers, as it would have to carry potentially significant costs if somebody takes over the network and starts double spending or rejecting transactions.
I think this is the missing feedback loop that connects mining income with network security.
"Paying miners for guaranteed inclusion" is another way of saying paying miners to work on a transaction, but this scheme builds on that idea to make it understandable for regular merchants. Rather than requiring people to understand what a gigahash of work means for them, a middleman handles those details along. They'd gather intelligence about what black market reversal miners are available, how much they cost, how risky any given merchant is etc. All the merchant has to do is find an insurer who charges a reasonable cost.
There are several differences in such a world to traditional Bitcoin:
- Forced chain splits/reversals could happen, potentially quite often. If the cost of security is higher than the value being protected taking the risk and occasionally losing makes sense.
- Transactions would often not be broadcast at all. Instead they'd be given directly to your insurer, who then passes them on to a set of miners of their choice along with fees calibrated to that particular clients risk.
- The fees charged would reflect the value of security to participants, not actually the cost of doing the proof of work. Miners might conceivably charge a fraction of the total BTC value, for instance, despite the fact that including the tx costs them virtually nothing. In a competitive market though, profitability of mining is likely to eventually converge on a bit under 10%, which is the average profitability across all industries.
- Mining barriers to entry in this world would not be cartels who agreed to only build on each others blocks, but the difficulty of getting contracts with the insurance companies, as most participants won't want to deal with miners directly.
- Many users have little or no need for security because pre-existing trust relationships are strong enough. These people should not need to pay fees, and can simply pass around transactions themselves outside of the P2P network.
Lately I became more and more convinced the difficulty is too high right now. Too much computational power is being expended to protect too little value, as a consequence of how Satoshi chose to distribute coins. It wouldn't surprise me if over time difficulty actually decreases quite a bit until it converges on the actual power needed to keep double spends to an acceptable minimum (not zero).
Jump to: