Pages:
Author

Topic: Potential disaster scenario (Read 11494 times)

newbie
Activity: 16
Merit: 0
August 17, 2010, 05:58:31 AM
#27
A simple(?) modification of the algorithm would be to apply the adjustment
after a certain amount of time rather than at a certain block number. 

Have you considered the following post which might outline an elegant solution to the problems you raise?

https://bitcointalksearch.org/topic/get-rid-of-difficulty-and-maintain-a-constant-rate-425

Agreed, that also solves the problem.  But is a much more extensive change to the system that changes it in many other ways as well.  It is more difficult to analyze.  My proposal is just a small tweak to the existing algorithm that preserves most of its current characteristics.  Adjustments would still be synced on a block boundary, so no stronger time synchronization would be needed.  No additional communications between clients would be needed.  The frequency of the adjustments would still be low (but more stable) so no additional sensitivity to latencies.
sr. member
Activity: 416
Merit: 277
August 16, 2010, 01:55:22 PM
#26
A simple(?) modification of the algorithm would be to apply the adjustment
after a certain amount of time rather than at a certain block number. 

Have you considered the following post which might outline an elegant solution to the problems you raise?

https://bitcointalksearch.org/topic/get-rid-of-difficulty-and-maintain-a-constant-rate-425

ByteCoin
sr. member
Activity: 294
Merit: 252
Firstbits: 1duzy
August 15, 2010, 01:31:04 PM
#25
Botnets will probably be supporting Bitcoin in the future, so it doesn't really matter anyway.

Which makes it essentially powered by tax revenues.
except it is a tax you can opt out of by having a clue about computer security.
full member
Activity: 210
Merit: 104
August 15, 2010, 01:22:59 PM
#24
As to the solution, I've not seen a convincing reason that adjustments are done every 2016 blocks or whatever. Why not every 50 or 10? Yeah, difficulty would vary a lot more often, but how is that bad?
founder
Activity: 364
Merit: 6472
August 15, 2010, 12:37:16 PM
#23
Some places where generation will gravitate to:
1) places where it's cheapest or free
2) people who want to help for idealogical reasons
3) people who want to get some coins without the inconvenience of doing a transaction to buy them

There are legitimate places where it's free.  Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating.  Many small flats have electric heat out of convenience.

How expensive is heating oil?  With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.

There's also kids putting it on their parent's power bill, employees their employer, botnets, etc.

Case 3 comes into play for small amounts.  The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments.  I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change.
newbie
Activity: 16
Merit: 0
August 15, 2010, 04:31:16 AM
#22
A lot of people are generating them at zero cost by using their employer's computer.  It's unfair to the employer, but it is the reason why bitcoins will continue to generate.

This is a good point.  I don't think I underestimated people's ability to generate bitcoins efficiently and legitimately - the difficulty adjustment does a good job of compensating for that, and that makes it a non-issue in my scenario.  But I probably underestimated the effect of minters using other people's resources without their knowledge and consent.  The FAQ theorizes that the cost of minting will approach the price of electricity minus a thin profit margin, and I probably accepted that theory too uncritically. If resource theft becomes the primary way to finance bitcoin minting, flaws in the difficulty adjustment will have a more subtle impact. 
administrator
Activity: 5166
Merit: 12850
August 14, 2010, 10:15:12 PM
#21
Why would it "grind to a halt"?  Economies don't function just because money is being printed.  Are you using the same argument for the US dollar and assuming our "economy would grind to a halt" if the government didn't print more dollars?  Of course not.

Blocks are used to verify transactions. For example, Bitcoin Market requires two confirmations. If a block takes two hours to make, then it would take four hours to put Bitcoins into Bitcoin Market. This would not be good.

When people start adding transaction fees, the value of the current block will steadily rise until it is solved. If this gets very high, everyone will attempt to "win the jackpot". The market will solve the problem.

Botnets will probably be supporting Bitcoin in the future, so it doesn't really matter anyway.
newbie
Activity: 32
Merit: 0
August 14, 2010, 10:01:17 PM
#20
Why would it "grind to a halt"?  Economies don't function just because money is being printed.  Are you using the same argument for the US dollar and assuming our "economy would grind to a halt" if the government didn't print more dollars?  Of course not.
sr. member
Activity: 252
Merit: 268
August 14, 2010, 08:35:24 PM
#19
But let's assume you are correct and people stop generating bitcoins early.  So what?  There will always be a market price for the remaining bitcoins.
Transactions are verified by generating blocks, so although I don't think it will happen, blocks being too difficult to generate would cause the economy to grind to a halt.
newbie
Activity: 32
Merit: 0
August 14, 2010, 06:49:33 PM
#18
You greatly under estimate the power of the profit motive and a market.  Bitcoins will continue to be generated as people find more clever ways to reduce hardware and power costs.  A lot of people are generating them at zero cost by using their employer's computer.  It's unfair to the employer, but it is the reason why bitcoins will continue to generate.  The current algorithm for difficulty is fine the way it is.

But let's assume you are correct and people stop generating bitcoins early.  So what?  There will always be a market price for the remaining bitcoins.

newbie
Activity: 16
Merit: 0
August 14, 2010, 05:52:26 PM
#17
It's in my original post:

A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number.  The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.

Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years).  Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.
How will you account for latency and time hacking then?

Could you elaborate on what kind of scenarios you see where the proposed algorithm would be more vulnerable than the current one? Note that the current algorithm also uses wallclock time in the difficulty adjustment calculation and is synchronized using newly generated blocks.
sr. member
Activity: 308
Merit: 256
August 14, 2010, 05:04:56 PM
#16
It's in my original post:

A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number.  The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.

Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years).  Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.
How will you account for latency and time hacking then?
newbie
Activity: 16
Merit: 0
August 14, 2010, 04:51:14 PM
#15
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.

Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
I'll bite.  Grin

How would you fix the algorithm?

It's in my original post:

A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number.  The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.

Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years).  Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.
legendary
Activity: 1246
Merit: 1014
Strength in numbers
August 14, 2010, 04:50:12 PM
#14
I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.

Really? Source?

Sorry, I was wrong about that.  I though I had read something on the forum to that effect, but now I can't find it.  Looking at old sources, I see that the 4x cap was there as early as bitcoin-0.1.0.rar, so this is definitely not a new modification.

I thought so, but still, some changes can be made. What is the change that solves this problem?
newbie
Activity: 16
Merit: 0
August 14, 2010, 04:48:57 PM
#13
I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.

Really? Source?

Sorry, I was wrong about that.  I though I had read something on the forum to that effect, but now I can't find it.  Looking at old sources, I see that the 4x cap was there as early as bitcoin-0.1.0.rar, so this is definitely not a new modification.
sr. member
Activity: 308
Merit: 256
August 14, 2010, 04:29:35 PM
#12
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.

Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
I'll bite.  Grin

How would you fix the algorithm?
legendary
Activity: 1246
Merit: 1014
Strength in numbers
August 14, 2010, 04:21:51 PM
#11
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.

Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.

Really? Source?
newbie
Activity: 16
Merit: 0
August 14, 2010, 04:06:01 PM
#10
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.

Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
legendary
Activity: 1246
Merit: 1014
Strength in numbers
August 14, 2010, 03:45:42 PM
#9
The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.

Actually, I was not assuming that.  In the scenario, the profit margin of 10% was the typical profit margin, by which I meant that most of the minting was done by players with a profit margin around 10%.  The scenario assumed the fluctuation in minting activity to be 20%, so it allows quite a lot of variance around the 10% mean without affecting the outcome as long as the bulk is within the 0%-20% interval (and the bulk cannot very well be above 20% - then the typical profit margin would not be 10%).

Regarding the effect of transaction fees, they may alleviate the problem somewhat, but at an unnecessary cost.  There will be some balance between monetary costs and convenience costs, but avoiding the costs altogether seems preferable to me.

What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.

Having a secure, open, P2P, pseudonymous, limited quantity money, is worth a ton. People who agree will pay the .001BTC or whatever to make a transaction if that's about what it ends up costing. 
newbie
Activity: 16
Merit: 0
August 14, 2010, 03:30:43 PM
#8
The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.

Actually, I was not assuming that.  In the scenario, the profit margin of 10% was the typical profit margin, by which I meant that most of the minting was done by players with a profit margin around 10%.  The scenario assumed the fluctuation in minting activity to be 20%, so it allows quite a lot of variance around the 10% mean without affecting the outcome as long as the bulk is within the 0%-20% interval (and the bulk cannot very well be above 20% - then the typical profit margin would not be 10%).

Regarding the effect of transaction fees, they may alleviate the problem somewhat, but at an unnecessary cost.  There will be some balance between monetary costs and convenience costs, but avoiding the costs altogether seems preferable to me.
Pages:
Jump to: