Topic: Necessary protocol improvement; dissent on future mining configuration (Read 6359 times)

I don't think doubling the natural fee will be anywhere near enough to create the necessary hashing rate. My guess for a sensible hashing budget to ensure security would be somewhere around two hundred times the transaction fees. Remember, we are assuming a world where transaction fees are no longer dictated by the client developers. They would be much lower than what they are now - an ECDSA verification does not cost 0.005 BTC, not even close.

The point is, arbitrary rules like this will result in hashing revenue that is too high (wasting money, electricity, etc.) or too low.

There are lots of impossible to predict factors such as the likelihood of government intervention that algorithms can't predict or incorporate. Therefore they will need changing from time to time. Miners will seek to influence this process. Gavin might be all idealistic now, but opinions change, invitations to exclusive sporting events get made, you know how it is. Certainly a little bit higher security wouldn't hurt, would it? There have been some double spends recently, haven't there? I mean we're not talking about a major change here, we'll just tweak this knob a little. See? This wasn't so bad was it!

I'm not sure if the lobbying of Bitcoin developers can be prevented in the long run, but in the short run let's at least not give ourselves outright control over miner income.

I'll use the rest of this post to explain why I think that users will be able to solve this problem quite efficiently themselves, without developers having to intervene at all.



This is exactly why I suggested an insurance model. It covers these differences - if you are a merchant who has a low rate of double spends because your customers are all very honest, you can get lower insurance premiums. If you're sending money to grandma, you don't need to pay insurance at all.



Sorry, but you're looking at it backwards. The security is additive. The chain security is the sum of what everyone using it is willing to spend on security. So if you send money to your grandma using Bitcoin and you don't get insurance, you don't contribute to the security level, but you don't detract from it either. (Note that even if you don't pay insurance you still carry the cost of hashing, because you still carry the risk of your transaction not getting confirmed. In other words, you benefit from insurance company's attempts at improving security. But, the risk you carry is a cost worth roughly¹ what you would've paid for insurance so it's not like you're leeching of of anybody or whatever.)

If someone transfers billions of dollars worth of coins at a time where Bitcoin's security is fairly low, he will have to pay high premiums. The insurance firm will try and figure out if it's better to raise the hashing rate or just shoulder a higher risk of an attack happening. If the risk is too great for whatever reason to use Bitcoin for such a transfer, the premium will be prohibitive and the transfer won't take place. If you think that's a bad thing and you advocate some minimum fee or other artificial way of raising the hashing level - what you're essentially advocating is my grandma and me subsidizing other people who do other kinds of transactions. Personally I think all types of transactions will be easily insurable in practice, but who knows. It's better to have a system where some extreme edge case transactions are too risky and uninsurable than a system where everyone else has to carry the cost for the riskiest transactions.

In a world with Bitcoin transaction insurance, the amount of money available for hashing at any given time is the total amount of money being transferred with insurance. In the short run, insurance companies will be willing to spend up to 100% of a transaction's amount in order to get it confirmed. For example they may do a contract with a render farm or super computing center to provide extra hashing in case of a large-scale surprise attack. They will contract with each other to coordinate such efforts - because that means lower risk from large attacks and that means lower costs.

A long-term attack like a government trying to shut Bitcoin down would cause them to raise premiums and at that point it's a matter of who is willing to spend more money overall: the global Bitcoin user base or the attacker. However, "more hashing" is not always the best defense. Imagine the US government attacking Bitcoin. Insurance companies could hire lobbying firms to stop that practice. They could advertise to get public support. They could help mobilize and fund Bitcoin's grassroots supporters and stakeholders.

In the event of a private company like a competing payment processor attacking Bitcoin, they might seek help from law enforcement. Hashing for the purpose of blocking all transactions or otherwise interfering with Bitcoin would likely be considered criminal hacking in most countries. Even if legal prosecution doesn't succeed, such practices if exposed would do tremendous damage to a company's image. So if you can find out who recently bought ten thousand high performance graphics cards, they would be in a lot of trouble.

Insurance is the tried and true way of dealing with risk. Whether it's a Bitcoin transaction or a money truck, if you want to be covered in case it doesn't make it, get insured. And the nice thing with Bitcoin is that money in transfer can't actually be stolen, only stopped/reversed. So Bitcoin transfers between trusted parties at least will be a lot cheaper to insure than any money truck.

And once again, I'm not advocating for doing anything. All I'm saying is that Satoshi's design will hold up as is. Regulation of the hashing level does not have to and SHOULD NOT be included in the protocol. Because doing so would be much less flexible and fair than letting people create suitable institutions themselves.

---

¹ Reality is a bit messy - the person getting insurance would pay a little bit more than the pure risk due to administrative overhead. But as the existance of other insurance companies proves, people are willing to pay that little bit extra in order to have certainty. It is likely that many transactions, if not most, would be insured. Convenience goes a long way.

Well it doesn't really peg fees to anything. Fees will naturally approach the cost of including a transaction, which means miners will have no margin. I'm merely proposing a simple change which will result in fees naturally approaching double the cost of inclusion.

I don't think doubling the natural fee equilibrium will eliminate micropayments.

Yeah, I think your proposal is better than some of the simpler solutions out there.

My point is that pegging the security level to some arbitrary value (and yours is still arbitrary as it's linked to something unrelated, verification cost) means either we'll exclude micropayments or Bitcoin will become uncompetitive with wire transfers for large, high risk transactions. It'd be nice to find a solution that makes Bitcoin suitable for everyone, and fortunately there are many years and even decades to find such a solution.

Well, that's a pretty important difference, isn't it?


min fees and constant inflation have problems. My solution is market based and scales with increased usage and change in electricity costs and the value of bitcoin. Which is exactly what we want. It ensures a sustainable market for mining, absent block rewards, and it's very simple to implement.

Your proposal means changing the voting rules (ie a global upgrade). At that point it doesn't seem much different to just setting a minimum fee, except that it adjusts slightly depending on how efficient the nodes are at verifying transactions.

There are several solutions that "solve" the problem like setting min fees, keeping inflation, etc. The question is, what solution allows Bitcoin to reach its full potential without restricting it to particular risk classes?

Thank you for so eloquently stating the problem. A solution I brought up in another thread goes like this (http://forum.bitcoin.org/index.php?topic=6284.msg134662):

Change the fee structure to pay 50% of fee proceeds to the block solver and 50% to the solver of the next block. This way, fees will approach 2 times the cost of including a transaction. So half the fees cover the cost of transaction inclusion and the other half goes to securing the network.

I didn't get a very positive response in the other thread, but as I can see how well you understand the issue, I would love your feedback on this proposal. Thank you.

For family and friends you don't even need to broadcast the transaction at all. That's not the problem. The problem is scaling it up.

The argument goes like this. If the cost of including a transaction is X (a small figure), why would anyone attach a fee higher than X + 0.00000001? Miners would include those transactions anyway unless there is some artificial minimum fee or scalability limit stopping them. Yet if all the fees are very low, there won't be much real mining done. The problem is that in the current model you're paying for block inclusion, not actually security.

You can say, well, attach a bigger fee if you need more security. It'll pay for mining on the current block and then future blocks too. More fees == more hashes of work piled on your transaction. But, you can't really pay for the security you need yourself. If you receive a payment for 1000 BTC in return for some goods which cost you 500 BTC, then guy paying you can easily spend 900 BTC to reverse the transaction (100 BTC profit for him), you can't spend anywhere near that much. In a 1-on-1 race the merchant always loses. The chain only works if everyone reinforces everyone elses security. Then the issue becomes, if there are a bunch of people paying for lots of mining to be done on some blocks, I can just pay whatever the minimum is to get into a block and benefit from the free work. The extra hard blocks paid for by others protect my transactions just as well as theirs.

So this is the argument as to why it won't work. Now, it's a theoretical argument, mind you. The free rider problem exists for copyrighted works too ... why would I pay for a {video,game,book,album} when I can download it for free? People do anyway. Relying on altruism and honesty isn't going to convince many people however.

How can the cost of transactions become arbitarily high? Mining is a competitive enterprise right now. There is a option in the client to select a maximum processing fee, doesnt this communicate to transaction processors how much they can make by securing your transaction? If clients pay less than it costs to secure the transaction, the transaction is not processed. But if the processor is too greedy and doesn't accept low fees, he will be driven out of the processing market by a processor who is willing to accept the lower fee. The key is that the software is open and free, so the market for processing is huge, and there will always be competition.

Bitcoin has many tangible benefits for its users in comparision to regular finance: anonymity, security, universal acceptance (eventually). The value transfered to processors is well worth the benefits to the client, or clients would not use the system. Some value MUST be transfered to processors, because processing takes energy to undertake, and energy is not free in any sense.

The a question posed is "how many miners do we want?", the answer is we don't want ANY "pro miners".

Currently there are people heavily invested in mining: "pro miners". This group is an anomaly, almost a cancer that has grown on the system. Will these "pro miners" shut down and dissapear once their business becomes anything less than lucrative? For sure. Will bitcoin transactions slow to a crawl? Eventually they will. Will the curency devaluate relative to dollars? Eventually it will. But the currency will always have non-zero value due to its scarcity and it is and always will be traded for other goods/currencies. We can sit back and watch the variance while the system takes time to mature and become a well distributed system where the only miners and payment processors are the users themselves.

What insight am I missing? Can't you just do very low tx fee with your family and friends to 'prove' you don't really need good and fast service? Then if you get it anyway no one is hurt by your riding because the tx is so cheap to process, if you have to wait that's a risk you take. If you can't afford the risk you pay more, the spillover benefit doesn't hurt you. In a tiny way it helps since people who use the same money as you benefit and you are better off when your (potential/statistical) trading partners are better off.

I kind of hope I live another 118 years just to see the system keep working without block rewards. :-)

Yeah. I guess my point is, we shouldn't close our minds to alternative designs.

I mean Vandroiy already convinced me the existing setup where all transactions are flood-filled to the network with attached fees won't work. The insurance/pay-per-gigahash model is a slightly different scheme, whether you think it's Bitcoin or not Bitcoin is, I guess a matter of opinion. Now I'm getting convinced the insurance/p-p-g model won't work (well) either.

The problem with a single chain is it sets a single speed and security level for everyone, though transactions have wildly varying tolerances to risk. For trading with my family I don't need any PoWs at all. For huge trades between people who don't trust each other you need way more than the average. Most trades are probably for internet type purchases today, probably less than a few thousand dollars worth of value.

Some people will over-pay, others will underpay (free riders) ..... it's not clearly the best solution.

However, I don't know what a better solution would be right now.

Absolutely, I don't need to pay a bunch of miners to facilitate trade between people I trust for more than the amount involved. Bitcoin just opens my trading world up from like 6 people to potentially 6 billion.

I think it's worth thrashing all this out, as these debates over the stability of a purely fee driven chain keep popping up in other places.

The current best proposal I've seen is to have people pay miners directly, by the gigahash, for work done on top of a transaction (ie the work paid may span multiple blocks and is thus not for inclusion). Insurance companies sit in the middle and calculate the risk of any given client being attacked, and charges them premiums for reversal insurance measured in time.

If a client starts getting attacked by people trying to outrun their transactions, the insurance companies will pay miners more to bury the transactions under more gigahashes of work done. Fees would not be provided via the current input/output value deltas but rather are paid directly to miners. It means you can't observe a high-fee transaction be included, pay for the minimum amount of hashing needed to enter the next block and then benefit from the next run of 6 accelerated blocks, because you don't know how much work has been paid for. Even if the network suddenly speeds up due to a high-fee transaction, the work might complete 5 seconds after you submit your transaction for inclusion.

In this world the minimum price for inclusion would vary and be essentially up to luck, you'd have to maintain accounts with a bunch of miners (how many is your choice) and keep draining your balance until a block is found. Overall your fees will be the average number of gigahashes taken to find a block multiplied by the current cost of a gigahash, set by market rates. That market rate prices in the benefit of the work done on top of your block. For a merchant if the average speed of the network is X gigahashes of work done in 24 hours, you need to dispatch your goods in 24 hours and X is enough work to avoid an attacker reversing the transaction after you dispatch, the only fees you need are whatever it takes to get into a block (ie you pay until you get in, then stop paying). If you need more security, like X gigahashes in 2 hours, you'd pay more and the network would temporarily speed up before reverting to the mean.

I've been debating this with someone and put the above system to them. They claimed the best strategy for people is to never pay anything, regardless of what you think anyone else will do. I don't really know how to convince him otherwise, as "paying nothing to anyone" is clearly not a winning strategy if you want to be a part of the chain!

I think it's worth keeping an open mind about the proof of work aspect of Bitcoin though. Satoshi wanted to design a system that didn't require any trust at all. Whilst we sometimes say Bitcoin doesn't have any middlemen, in reality it has a large number of middlemen who help people who don't trust each other trade. You don't have to trust the middlemen either, making it (theoretically) a very open and liquid market ... at the cost of burning a lot of electricity.

It may be that the zero-trust configuration isn't actually the best or most useful in the end, if the benefits of a fluid market aren't outweighed by the PoW costs. The proposal of using a web of trust to order transactions rather than PoWs has the disadvantage that it raises huge barriers to entry (how does a new node become trusted in such a system, without opening it up to easy attack?), but the advantage that the energy costs are very low.

@Vandroiy

There have been many people that have passionately said that 'Bitcoin was wrong’ back in early 2010, and they said that it would never get even close to where it is now.

The free market is much more flexible than what you describe.  Did you know that in a free market dominated by Bitcoin, that 'everyone' would be advantaged by its stability?  So the risk to attack may be very very small.  Therefore making Bitcoin more inefficient by artificially shifting more resources into mining may make Bitcoin even less secure as people will not use Bitcoin but something that is cheaper.

The fact is that 'we don't know' what is going to happen... We just know that bitcoin so far has been very successful, and that throughout history a free market has been very successful at predicting and working around any 'attack issues.'

Artificial restrictions are stupid and should be avoided.  I disagree that there should be a fixed fee schedule and block size... I think that it would be more accurately described by competition between the miners.  At some point, Bitcoin may be so cheap and fast, and require such a large amount of infrastructure to run that the people running the network would have a strong stake in keeping it secure.

Vandroiy, you ignore 'idle resources;' good people may have huge computational resources just sitting there for use as a deterrent to any attacker... Those resources could be sponsored by each the big bitcoin banks.  An attack will never happen, because it would be prohibitively expensive to undertake... not from the active network power, but from the potential.


In any case, there is so much about the future that we don't know... and this is all speculation.
We should focus on making Bitcoin as secure as possible NOW, not 50 years in the future.

This is a forum of strong opinions. I wouldn't be surprised to see everyone have a negative reputation on average!

Forget about it, that system went haywire much faster than I expected. There's already a majority voting inverse... lol I wasn't posting anywhere but here when I got the two negatives, and my post was fairly aggressive, so I guessed it's related. But I didn't want to accuse anyone.

Maybe someone who's not even talking in here voted negative on both sides to make participants in the discussion angry at one another. I feel like a loser now, having been successfully trolled, even if just for a sentence.

It's good I don't have 250 posts yet. I can prove my innocence in reputation wars.

I didn't do it.  Is it still a compliment?

@vladimir:

Sorry about that, but look at the size of the debate. I can hardly keep track of things as is, and it appears I can't keep the threads split either. I must admit that the split into argumentative and constructive part has failed. Think about it from my viewpoint -- I'm fairly convinced that the difficulty equilibrium needs a re-design, but how can I discuss what follows from that with those who believe me in the midst of the first discussion?



@creighto:

Now we're on the same page. What you describe is a hypothetical check of the exact kind I am asking for. But there is one very big problem: an attack can be very short. It might need no more than an hour of control to fool people into believing in the transactions that are to be reverted. The block sealing has to happen fast, within ten minutes or so. We can't wait for a new client version, also we don't want to put too much trust in a client author. So how can it be implemented? How can you be certain you have sealed the correct block, you have the correct hash? All attacks on a web of trust work against this, and more due to centralization. What we need is to formulate this idea to the end, so it can be implemented. That's just not an easy problem. On a side note, whether or not it is in the protocol is only a formal question. Since the clients would have to enforce it, any such rule-set becomes an effective part of the protocol.

The web of trust is one proposed possibility that might remain secure when your ISP or router is compromised. If someone manages to add the security enhancements you describe in a different way, this thread is obsolete and I'm happy with the outcome. I just wonder how exactly to do it, and would love to see it implemented sooner rather than later.



On the contradiction mentioned in my last post: I do not assume the size of an attacker be known in advance. I just assume there is some attacker of some size at some time. I will continue where I left off, showing that one statement must be false.

Statements:

• There is no link between the size of the biggest attacker and transaction fees.
• Any direct attack on the system is expensive relative to the expected gain.

Let me assume the second statement true. This means the amount of the attacker's BTC that can put into transactions simultaneously is worth more than the processing power required to execute the attack times some risk factor. The processing power required to execute an attack is obviously linked to difficulty.

But difficulty is effectively an expression for the amount of mining power present, and that is paid by the total amount of transaction fees: average fee times amount of transactions, put simply. I have now established a link between size of the biggest attacker and transaction fees, with one free parameter, namely the amount of transactions, or market size, if you wish to put it that way.

Thus, if statement two is true, statement one is false. I conclude that one of the statements must be false.



Interpreting this is a different thing. Yes, we need the link to keep things safe, so that's not bad in itself. But there is one free parameter, the market size, and absolutely nobody can tell me what to do with it. Now, if that's not a discomforting sign, what is? As stated before, I personally believe the first statement to be close to the truth, and the second to be false with the current client.

PS: I take the minus reputation as a compliment. At least I pushed hard enough that people feel to use this in place of arguments, displaying how the feature is now used for democratic truth-seeking. Too bad truth is not democratic.

It's not a contradiction, at least one of your premises is wrong.  Namely, that the size of an attacker can be known in advance.  It cannot.  But the proof-of-work system exists to make a brute force blockchain attack to be as expensive for the attacker as the network as a whole can afford.  What the total network can afford is always changing with the size and overall bitcoin wealth of the Bitcoin economy & userbase.  The beauty of the current system is that it associates a personal need of certain particular users to the collective need of the userbase.  Namely the personal need of well-heeled users to rapidly confirm large and/or high risk transactions with the collective need of the userbase to maintain as high a level of blockchain security as is reasonablely possible.  Your assumptions are that the current protocol cannot maintain the level of security.  I assert that you have failed to show this in any fashion.  Show me how you might guess the level of a future attacker, and I might be willing to entertain flights-of-fancy; but thus far this has all been about how you would have done things differently.  Feel free to go do it.  I'm sure others will try it.  Hell, I might even try it.  But based on what you have written thus far, you still don't really grok what Bitcoin is actually doing to protect itself.  There is more to it than you have expressed, and the smaller rules have an interlocking interplay with the major part of the protocol that actually makes the task of attacking, DOSing or spoofing the network so much more difficult to achieve in practice than it is written into the white paper as a matter of theory.  One such rule is the blockchain release benchmark.  With each new release, the new client contains a list of particular blocks whose confirmed hash number is recorded in a hard coded list in the source.  At present, that list is the same for each client because they are pretty much all the same client.  In the future, the benchmarks would be different for each independently maintained client.  The reason for this list is to protect the history of the blockchain from a successful brute force attack of the blockchain, because in order for an attacker to rewrite the history of the blockchain before the newest benchmarked block, the attacker would have to produce a forged block, that could pass the validity tests, that still had the same hash as the original benchmarked block.  In order for an attacker to continue to succeed, he would have to keep doing this for every benchmarked block in the list; because it's not something that can be changed in the running nodes.  This problem is compounded further if, in the future, alternative Bitcoin clients use an alternative list of benchmarked nodes; as the attacker would have to either do this magic with all the benchmarked blocks in all the alternative clients as well.  The mathmatical difficulty of doing this is probably quantifiable by some of the math geeks on this forum, but my back of the envelope numbers tell me that the odds of being able to do this is so astronomically against the attacker and in favor of the network that, (even ignoring all of the other problems with it such as the near impossible task of just getting back that far with the current ability of the network) the attack would be so many orders of magnitude higher difficulty than the simple single block rewrite that the cost of building such a supercomputer would likely exceed the total wealth of the top 20 wealthiest nations on the planet, and perhaps the entire wealth of the planet itself.  Which, of course, effectively makes such a thing a literal impossibility unless there is some alien race that arrives on Earth in the next 120 years bent on the task of breaking Bitcoin.

And that is just one of the checks beyond the protocol itself that exists within the Bitcoin client.

Good job on reading one of my arguments correctly, and the thread's topic: we lack a consensus on desired mining configuration. But you agreeing and adding difficulty as another free parameter makes your statement a blatant contradiction to another thing you said, namely


So the miner configuration is such that an attack does not pay, but there's no link between attacker size and both transaction fees and difficulty. That is a contradiction. At least one of those two quotes must be wrong. Please don't force me to formally prove this.



@vladimir:

I have been discussing why I do not believe in your "self healing and self regulating properties" for weeks. I am weary of arbitrary claims of "the" system configuration "being self organizing". Provide anything close to a model that has not been shown problematic, and I will regard it. Also, please do it in the appropriate thread. The quote I took may have been out of context of your post, but the part I ignored is out of context of this thread. Let me quote myself, the very fist thing said in this thread:


The discussion is crumbling because people keep shouting "no you are wrong" without staying with the argument. Make up your mind: either you are certain that there is a stable setup in place. If so, which one, limits on or off? Provide the model in the appropriate thread, link to it here, end the discussion as irrelevant in a single post. Or we take the option of "let's wait and see how it plays out". These are mutually exclusive. Either you know something, then there is no need to observe it -- or you need to observe it, but then you don't know.

I usually walk away when I face a battle where a logical construct is attacked with sheer mass, be it amount of people or amount of words said. I'm reluctant to do so here, but please note that this discussion is past the point where a blurry claim persuades those who believe there is a problem. If the thread becomes too bloated, I'll re-create the topic again, if necessary on a different site, until it is either solved, shown not a problem or hitting enough non-argumentative resistance to justify giving up. The latter outcome is a very poor way of resolving disputes though.

But please, at the very least, when talking about "current" Bitcoin protocol, specify whether you talk about a future version or want to live with the limits for all eternity. One cannot conjure up the Bitcoin protocol before it's finished. That goes for creighto as well; when talking in #bitcoin-dev, nobody can point me to any rules in place that comply to your claims.

Sorry, but I strongly disagree, strongly enough to make a whole post out of that statement. It is important to show that Bitcoin is not like the other currencies, that it is not patching behind the mess.

If there is an attack and we start fixing after fraud has occurred, it will be known what Bitcoin was not: flawless. The same way it will look when somebody proves the system has been wasting millions of dollars on processing power it never needed. Anybody who paid for transactions will feel fooled when that happens. But Bitcoin could be flawless. Right now, it's still perfectly reasonable to use miners. Nothing went wrong so far, and everybody is astonished by that. That's where the magic lies; people look at things and if they see it flawless, they become advocates of it. People like to find good things and support them. The last thing we need is a fix coming in late, making unbroken belief waver.

Bitcoin. A system ahead of time, superior to other currencies at all times in its history. It can be done from here, but nothing is done by blind belief from those making the system. It is essential that Bitcoin shows no signs of failure, not visibly and not theoretically, until it is well-established; better yet, none ever.

Bitcoin is all about trust and doubt now. Trust is all we have, and all we need. I don't think we should ever risk it. "See how it plays out" is absolutely no option in my opinion.