Bitcoin Forum
December 25, 2024, 04:34:58 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Could bitcoin fork to scrypt?  (Read 1346 times)
ToxicDartFrog (OP)
Full Member
***
Offline Offline

Activity: 197
Merit: 104



View Profile
July 02, 2013, 06:21:17 PM
 #1

Ok so I know it sounds silly at first but I was thinking with all the ASIC drama could it be possible for bitcoin to fork and begin using scrypt? Technically yes or no?

My thought was that a fork client would come out hard coded to switch to scrypt once block x is reached. There could be some benefits to this such as shaking off ASICs if you feel they may end up becoming detrimental.

Trying to keep politics aside here. I realize it would require at least 51% consensus and there's a whole set of other issues around forks. It also would need to be done soon as it will become hard (maybe impossible) to break control from ASICs once they control 51%. I doubt ASIC owners would want to use the fork client Cheesy

In theory it is possible isn't it?

DISCLAIMER: I'm not fighting for or against this idea. Just presenting it for discussion as I always hear people worried that ASICs may end up destabilizing btc and that scrypt coins don't have this problem. (not saying that's fact but it's said a lot)
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
July 02, 2013, 06:25:00 PM
 #2

See this thread:

defending ahead the p2p nature of bitcoin - blending hashcash & scrypt

ROI is not a verb, the term you're looking for is 'to break even'.
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1104


View Profile
July 02, 2013, 08:36:36 PM
 #3

Trying to keep politics aside here. I realize it would require at least 51% consensus and there's a whole set of other issues around forks. It also would need to be done soon as it will become hard (maybe impossible) to break control from ASICs once they control 51%. I doubt ASIC owners would want to use the fork client Cheesy

Hard forks require near complete consensus.  You could possibly pull it off if all users (other than miners) agree, maybe.

The other option is to just actually fork it at some point.  There would then be bitcoin-SHA256 and bitcoin-scrypt.

To keep things safe the fork would have to have slightly different signature rules.  Otherwise, if you spend a coin on the scrypt fork, then you also have effectively spent the coin on the sha256 side.

Everyone who has bitcoins would get coins on both forks.

If you checkpoint at the fork point, you could even drop the calculations for hash POW once you have passed that point.  For example, the version of the client released 2-3 months after the fork would just assume the chain up to the fork was valid.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jackjack
Legendary
*
Offline Offline

Activity: 1176
Merit: 1280


May Bitcoin be touched by his Noodly Appendage


View Profile
July 03, 2013, 07:02:44 AM
 #4

Yes

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
jonoiv
Hero Member
*****
Offline Offline

Activity: 966
Merit: 526


🐺Dogs for President🐺


View Profile
July 03, 2013, 01:55:54 PM
 #5

but what would be the consequence in regard to the difficulty ?  with BTC at 20m now, if it were possible to move to scrypt or even something new to make it asic resistant then BTC would die in my opinion.  This problem would not be so pronounced if BFL had actually delivered when they promised. They are 13 months behind which gave time for big players to become very interested in BTC.

In my opinion LTC and FTC will become the future of foreseeable cryptos. 

Signature for hire!
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1104


View Profile
July 03, 2013, 02:48:33 PM
 #6

but what would be the consequence in regard to the difficulty ? 

Well, if most of the processing power stays on the main chain, then the fork would have lower difficulty.

There is a somewhat of a "Highlander" effect here, i.e. "There can only be one".  The coin with the most hashing doesn't have to worry about massive swings in hashing support.  There is no "spare" hashing available to instant divert to hashing that coin.

Each coin effectively pays (coin market value) * (block reward) / (hashes per block) to the miners for hashing.  This means you can rank coins from most profitable to least profitable. 

A profit maximizing miner would direct 100% of his hashing power to the coin with the highest rating.  If all miners think the same, then the coin gets a surge in hashing.

However, if you drop from 1st place to 2nd place, you would get a massive drop in hashing, since all profit maximizing miners would switch away.  This is one of the reasons that alt coins try to change difficulty slowly.  They don't want to drop from 1st to 10th place and then lose 90% of the hashing support.

For the question at hand, you would need to estimate the scrypt support for the scrypt fork.

For example,

- All blocks below 250000 will use sha256 POW
- sha256 difficulty is doubled between 249999 and 250000
- scrypt difficulty is set to lowest at 250000
- All blocks between 250000 and 259999 can use either POW
- scrypt difficulty is halved between 259999 and 260000
- All blocks from 260000 will use scrypt POW

You would have different scrypt and sha256 difficulty targets.  The target is for each type of block to occur every 20 mins during the transition.  It is probably worth having a faster scrypt rise for the transition, since 10k blocks is only 5 re-target periods.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!