Bitcoin Forum
December 08, 2016, 04:25:50 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Potential disaster scenario  (Read 4037 times)
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2506


View Profile
August 15, 2010, 02:15:12 AM
 #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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
1481214350
Hero Member
*
Offline Offline

Posts: 1481214350

View Profile Personal Message (Offline)

Ignore
1481214350
Reply with quote  #2

1481214350
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481214350
Hero Member
*
Offline Offline

Posts: 1481214350

View Profile Personal Message (Offline)

Ignore
1481214350
Reply with quote  #2

1481214350
Report to moderator
gebler
Newbie
*
Offline Offline

Activity: 16


View Profile
August 15, 2010, 08: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. 

18h6HV7RPU4xFwiap2RdzsqDjcgsEmh3vy
satoshi
Founder
Sr. Member
*
Offline Offline

Activity: 364


View Profile
August 15, 2010, 04: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.
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 15, 2010, 05: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?

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 15, 2010, 05: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.
ByteCoin
Sr. Member
****
Offline Offline

Activity: 416


View Profile
August 16, 2010, 05: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?

http://bitcointalk.org/index.php?topic=425

ByteCoin
gebler
Newbie
*
Offline Offline

Activity: 16


View Profile
August 17, 2010, 09: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?

http://bitcointalk.org/index.php?topic=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.

18h6HV7RPU4xFwiap2RdzsqDjcgsEmh3vy
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!