What happens to mining with a sudden drop in value?

[Meni Rosenfeld]

Exactly, no one in his right mind would agree to change the block rewards.

Unfortunately, I believe that the general  public would say the same of a deflationary currency. The libertarians and austrian economists are the ones who are looked upon as kooks. But sure, if the scenario I layed out were to happen right now, I do believe this community still has enough influence to make sure that the right adjustments are made. The point I tried to make to you was that in the future, the influence over bitcoin of this community may be next to nil. If that is the case, we can't be sure that the majority of miners won't settle for some other solution that sounds plausible/has better marketing.

But changing the difficulty is a perfectly valid measure to deal with emergencies.

But the cost of this would surely be a massive loss of confidence in the very concept of cryptocurrencies. I don't see how that would benefit any of us. Preventing emergencies is always better than dealing with them. If the scenario I have layed out is plausible, then I am of the belief that measures should be taken to prevent it, not to deal with it.

There will always be a need for a way to establish consensus about changes to the protocol. It need not be this community. What happens if/when SHA-256 or ECDSA is broken? Someone will have to agree on a replacement. Nobody will lose faith in cryptocurrencies because of occasional amendments which are known in advance to be inevitable.

It is clear that changing block rewards is utterly unacceptable, for the reasons you have mentioned. But a one-time difficulty adjustment to deal with what is basically a technical issue (difficulty update granularity) is ok.

I agree that the effects of a difficulty spike may be preventable, but we need to be very careful not to change the rules in a way that will cause more harm than it solves.

[1714833864]

1714833864

[1714833864]

1714833864

[1714833864]

1714833864

[1714833864]

1714833864

[1714833864]

1714833864

[1714833864]

1714833864

[2_Thumbs_Up]

Luckily, the miners are not the general public but a specialised subgroup with much stronger incentives to preserve the value of the currency even in the face of possible short term gains from higher block rewards (as they are demonstrating every day right now).

Miners do not have a direct incentive to preserve the value of the currency. Thier incentive is to keep earning money, inflation or not. And more importantly, they are not economists. If they can be persuaded that increasing the block reward is a safer solution than decreasing the difficulty, they may settle for that solution. The majority of miners may be libertarian-leaning right now but I don't think it's safe to assume this will always be the case.

There will always be a need for a way to establish consensus about changes to the protocol. It need not be this community. What happens if/when SHA-256 or ECDSA is broken? Someone will have to agree on a replacement. Nobody will lose faith in cryptocurrencies because of occasional amendments which are known in advance to be inevitable.

Amendments are fine. "Panic amendments" or not imo.

It is clear that changing block rewards is utterly unacceptable, for the reasons you have mentioned. But a one-time difficulty adjustment to deal with what is basically a technical issue (difficulty update granularity) is ok.

It's clear for you and me, but I don't think it is for everyone or even the majority of miners (especially not in the future when this community represents even less of the total amount of miners and users). In a potential situation where the stability of the bitcoin-network is very uncertain, I don't think it's safe to just assume that our solution is the one that will gain traction. I really think such issues needs to be adressed before that ever becomes a reality.

I agree that the effects of a difficulty spike may be preventable, but we need to be very careful not to change the rules in a way that will cause more harm than it solves.

I couldn't agree with you more here. Any change need very thourough thoughts and investigation put into it. And that is kind of my point. We won't have that time right after a sudden drop in the value and sudden transaction hold-ups.

Also, I just want to make clear that I'm not as certain of my position as I probably sound. I arguee mor for the sake that I really think this needs to be adressed long before it ever becomes real.

[Coma]

I'm hoping for a price drop and not deep trusters of the concept miners leaving.

[wareen]

I agree that the effects of a difficulty spike may be preventable, but we need to be very careful not to change the rules in a way that will cause more harm than it solves.

I couldn't agree with you more here. Any change need very thourough thoughts and investigation put into it. And that is kind of my point. We won't have that time right after a sudden drop in the value and sudden transaction hold-ups.

Very true indeed!

We might start with describing a few of the more plausible scenarios in greater detail - maybe on the wiki.
Then maybe outline a kind of action plan for such emergency situations which would include ideas from this thread and things like:

• Who should be in an emergency council? (lead developers, pool operators, maybe major exchange operator,...)
• How and when can this council be convened?
• Voting rules for this gathering
• How are users/miners to be notified of important changes? (somehow get the alert key from Satoshi or him back on the team?)
• Timeframes for the meeting/notifications/changes
• Define which parts of the Bitcoin system must not be changed no matter what happens (block reward?)

Maybe there should also be a mailinglist to reach a greater part of the users and especially the bigger solo-miners.
Another idea would be the funding of some emergency hashing capacity which only starts to mine in case of a major attack.

But I also agree that preventing such emergencies is better than dealing with them after they have happened!
However, to have a clearer picture of the possible crisis situations is certainly not a bad idea - if only for helping the discussion about safeguards in the bitcoin client. The outline of an emergency procedure can again help for unforeseen situations or for those against which the countermeasures in the code are not yet in place or insufficient.

Then again, this is just another noob speaking here - we need more input from the elders

[danglybits]

This whole problem can be resolved with proper short selling.

Miner borrows bitcoins in advance, sells them at today's profitable price, and then pays them back with newly generated BTC.  This transfers the risk from currency flux to difficulty flux.   Unfortunately, the primary time difficulty goes up is when price goes up.  So if you short coins and lock in todays price, the price goes up causing difficulty to follow then you end up having a hard time paying off your BTC debt.

The relationship between difficulty and price means that if you are mining bitcoins you must speculate that their value will go up over time because there is no "safe" way to short BTC and hedge difficulty increases.

Perhaps if a pool operator offered a contract for a fixed price per work item.  Then you could short or go long on difficulty adjustments. 

Miner would then look at the current price for a 1,3 or 6 month mining contract @ fixed difficulty to determine profitability.  They would then buy the contract and short the BTC thus locking in the "unknowns" and transferring the profit/loss from BTC price/difficulty adjustments to speculators.

With these factors in place, the market should automatically smooth out all such "sudden" disturbances.

[Meni Rosenfeld]

Miner borrows bitcoins in advance, sells them at today's profitable price, and then pays them back with newly generated BTC.

How will this help? If the price crashes and mining becomes unprofitable, he will just stop mining and buy the bitcoins he owes.

[danglybits]

If mining contracts were priced in $USD then price the money earned by mining is fixed and the risk is shifted to the speculator.

[SgtSpike]

I agree that the effects of a difficulty spike may be preventable, but we need to be very careful not to change the rules in a way that will cause more harm than it solves.

I couldn't agree with you more here. Any change need very thourough thoughts and investigation put into it. And that is kind of my point. We won't have that time right after a sudden drop in the value and sudden transaction hold-ups.

Very true indeed!

We might start with describing a few of the more plausible scenarios in greater detail - maybe on the wiki.
Then maybe outline a kind of action plan for such emergency situations which would include ideas from this thread and things like:

• Who should be in an emergency council? (lead developers, pool operators, maybe major exchange operator,...)
• How and when can this council be convened?
• Voting rules for this gathering
• How are users/miners to be notified of important changes? (somehow get the alert key from Satoshi or him back on the team?)
• Timeframes for the meeting/notifications/changes
• Define which parts of the Bitcoin system must not be changed no matter what happens (block reward?)

Maybe there should also be a mailinglist to reach a greater part of the users and especially the bigger solo-miners.
Another idea would be the funding of some emergency hashing capacity which only starts to mine in case of a major attack.

But I also agree that preventing such emergencies is better than dealing with them after they have happened!
However, to have a clearer picture of the possible crisis situations is certainly not a bad idea - if only for helping the discussion about safeguards in the bitcoin client. The outline of an emergency procedure can again help for unforeseen situations or for those against which the countermeasures in the code are not yet in place or insufficient.

Then again, this is just another noob speaking here - we need more input from the elders

Sorry, but I completely disagree with a closed council style meeting.  And only inviting pool/exchange operators?  No, the point of Bitcoin is to be decentralized.  Since the developers have to be a part of it, any centralization should occur only around them.  The rest should be open game.

I would suggest just holding an emergency meeting in an IRC channel and allowing anyone in.  Sure, it would probably get a bit chaotic, but at least that way everyone has a chance to voice their thoughts/ideas.

Regardless, I think that this issue is something that must be solved.  I doubt it will ever happen, but we must take it in to account.  The reason I doubt it will ever happen is because of a recent poll I took:  Half of all miners said they would continue mining even if it was not profitable, for a variety of reasons.  So that means that the network, at most, would drop 50% in mining power if the price dropped to the point of it being unprofitable to mine.  It would take 4 weeks for difficulty to readjust, and in the meantime, we'd still have blocks coming through every 20 minutes.

A possible solution might be to time the time it takes between blocks.  If the time period exceeds 3 standard deviations of the statistical curve, then readjust difficulty immediately.  The statistical curve could be calculated in the client based off of the difficulty level.  The difficulty would only adjust if > 50% of the clients agreed that this 3 standard deviation limit had been reached.

[Coma]

Maybe a forum thread where everyone is given 1 post and extra posts are charged with bitcoins.
Then polls with all propositions on relative matters.
Then you have a veredict.

Just brainstorming.

[wareen]

Sorry, but I completely disagree with a closed council style meeting.  And only inviting pool/exchange operators?  No, the point of Bitcoin is to be decentralized.  Since the developers have to be a part of it, any centralization should occur only around them.  The rest should be open game.

The council would only quickly agree on a possible solution and have the immediate ability to implement it and publish an updated version of the client. I did not intend this to be any kind of centralized control over the network - each participant in the Bitcoin network has to decide if he/she accepts (installs) the updated version or not.

Being decentralized is a vital part of the Bitcoin system but most of the users implicitly trust the official Bitcoin client. I suggested the large pool operators to be a part of an emergency response process only because for the changes to take effect it would be important that they quickly update to the new version (if they agree with the changes of course). Everybody mining in a pool already gives up the control over the rules followed by the pool operator.

I am in no way saying that this should be a closed process, but it has to be efficient. If it takes weeks for an updated version of the client to control > 50% of the hashing power of the network then the trust of the users could already be severely damaged (depending on the kind of "emergency situation" the network might be in).

Bitcoin as a system follows the rules made by a majority of the participating miners and this is the _only_ authority in the network. An open voting on IRC or the forum might be more democratic but this is not how Bitcoin works right now. Everybody votes with his/her hashing-power and I think this is something nobody really wants to change: "one CPU - one vote" (make that GPU nowadays ).

If a few of the larger pool operators agree on a change it is more or less immediately accepted by Bitcoin. Of course, every user is free to leave the pool if he does not approve of the changes, but if we (the users) want the system to be robust and adapt quickly in a crisis situation we would probably want the larger pool operators to be well connected with the developers.

Since everybody mining in a pool has currently no way to prevent the pool operator from changing the rules at any moment anyway, we should at least make best use of this in case of an emergency in that we proactively outline a mechanism for them to act quickly and accordingly together with the devs.

Sorry if this came across as advocating some kind of centralized control - it was never meant that way!

[SgtSpike]

I suppose the majority of the miners are smart enough to know whether a change would be good or bad for the network.  I was just afraid of people accepting a change because "those people said it was a good idea and needed to be done ASAP."  Hopefully, we can trust enough people that we wouldn't end up in a situation like that.

You do make valid points about efficiency and getting an important update out quickly.  Like, say, if quantum computing suddenly breaks SHA-256. 

[wareen]

I suppose the majority of the miners are smart enough to know whether a change would be good or bad for the network.

Yes, you're probably right about that - at least I hope so
We can't ignore the fact though, that currently [Tycho] and slush represent the majority of the miners so if they don't agree on a network change it will not happen quickly and if they do it will.

Since there's really only a handful of people who must coordinate themselves in case of emergency (and they know who they are) it might as well be left to them since we're currently trusting them anyway. A bit more community involvement in such important decisions would be nice though.

But it is probably really best to work on safeguards in the code before anything bad happens!

At current difficulties, most of the miners are in no position to demand policies from their pool operators and I don't really see pool policies apart from the payout model to influence the decision of the miners on which pool they join. It is a bit sad because in the future this might make a real difference of what the network will become and how robust it will be.

Maybe we could need a bit more discussion about pool policies and how they are communicated and make small miners more aware of their importance - they seem to still make up for the majority of the hashing power and thus shouldn't lose their vote only because they don't like high variance in their payouts.

Anyway - this is going a bit off-topic - I apologize!

[Zman0101]

I don't agree with mining for no profit. Us Miners need some sort of incentive. I love Bitcoin but, paying 300 dollars per month for all my rigs and not gaining anything for it... Whats the point? As long as my electric bill is paid for,Ill keep mining. In order for this currency to succeed , we have to take care of our own. Plus with the difficulty going up and up and up... Its pretty hectic. Can't keep buying more hardware and going into more debt just so people can build and buy more shit in 2nd life. This currency is past that and far more valuable. This scenario is the same as a state firing their whole road crew to repair roads... After enough people bitch that they keep hitting pot holes and messing up their cars... Something has to be done. I'd rather not see Bitcoins come to that . If anything implement something now into the pools. I liked a lot of the ideas on here. An just because the votes say 50% will still continue to mine even if it isn't profitable means nothing. Trust me... Once Mom sees her electric bill... All your shit will be ripped out of her basement real quick.

The Pool questions should be written like this:

1. Is your Mining operation in your Mom's Basement? Yes Or No

2. If question 2 = Yes ...Will Your Mom beat you if you don't pay her money ? Yes Or No

3. After your beating... Will you still continue to Mine ? Yes Or No

[DamienBlack]

BTW, this could be turned into a potential (but difficult to pull off) attack: get a large mining capacity, make the difficulty go up, then, all of a sudden, stop mining.

If they could increase the difficulty that much, we've got bigger problems. Namely that they have control of the network.

[wareen]

BTW, this could be turned into a potential (but difficult to pull off) attack: get a large mining capacity, make the difficulty go up, then, all of a sudden, stop mining.

Actually, that happened once on the testnet, when ArtForz redirected his rigs to it just for fun, producing blocks with ~4 times the usual hashrate. It took some months for the difficulty to recover, during which transaction confirmation was very slow.

This would probably be a major problem for Bitcoin but I doubt someone has the required ExaFLOP/s idling around somewhere on this planet

[kjj]

BTW, this could be turned into a potential (but difficult to pull off) attack: get a large mining capacity, make the difficulty go up, then, all of a sudden, stop mining.

Actually, that happened once on the testnet, when ArtForz redirected his rigs to it just for fun, producing blocks with ~4 times the usual hashrate. It took some months for the difficulty to recover, during which transaction confirmation was very slow.

This would probably be a major problem for Bitcoin but I doubt someone has the required ExaFLOP/s idling around somewhere on this planet

I'm of the opinion that enough hashing power to disrupt the network does not currently exist in purchasable form.  I think it would require a door to door search and confiscation operation in several countries.

[AngelusWebDesign]

I think the exchange rate would need to drop quite a ways to scare off most miners.  In my case it'd have to go below $1.94 at the current difficulty to make mining unprofitable.

You say that --

And many others do as well.

"I am profitable all the way down to $2.25"
"1.96"
"2.50"

But come on!  I'm not going to have room full of loud, hot PCs belching out heat in the middle of the Texas summer for ZERO PROFIT!
Heck, even if I was only making $1 or $2 for every $8 of electricity, I'd be nervous that my math was off a bit, and that I was actually losing money. You have to count the Mt. Gox 0.65% fee for conversion, etc.  And if BTC dropped by so much as 50 cents, I'd be in the red! 

So you see, it gets dicey for miners long before "break even".

Heck, there are guys quitting mining RIGHT NOW and the difficulty doesn't reset again till Friday, and BTC is still around $12.

Matthew

[Zman0101]

Thank you Matt.. Someone is finally seeing what i was saying earlier.