Bitcoin Forum
June 24, 2024, 05:38:00 AM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Difficulty vs. Block Reward and other rambling thoughts  (Read 634 times)
DarkLight72 (OP)
Newbie
*
Offline Offline

Activity: 42
Merit: 0



View Profile
October 22, 2013, 06:17:37 PM
 #1

Ok, I've done as much research on this as I know how but admit that I'm far from an expert...so I'm asking.

Understanding that the ultimate "payoff" should be the same, has it ever been considered to modify block reward instead of modifying difficulty?

Again, being a relative newb, I've probably missed at least something if not most things but, here's what I'm thinking:
  • One of the issues with Bitcoin/Namecoin and potentially any other coin that isn't resistant to ASICs is that as the difficulty increases, hashes/sec vs. reward pushes the smaller/home players out of the market.
  • As more and faster ASICs are introduced, any prior investment is rendered more and more obsolete.

If, for example, Block Reward was modified (and possibly difficulty to keep things from getting utterly ridiculous but not 200,000,000+) every say 20 blocks or something like that, you could keep the release rate of coins per hour consistent, regardless of difficulty or global hash rate.

One other issue I've thought about with regards to the ultra-high difficulties on SHA-256 coins is that if a new one comes out and someone wants to "kill" it, they just throw their ASIC miner at it for a couple of hours, crank the difficulty into the stratosphere and then walk away from it.  It takes WEEKS for the difficulty to come back down and only after a concerted effort by a small community to even keep chugging away at blocks until the next adjustment (or in some cases multiple adjustments).

As a potential "fix" to what I see as a weakness, I was wondering how well this would work:
  • Certain wallet IDs would be incapable of holding any coins.
  • Those wallet IDs/addresses, starting with the one that mines the genesis block, would be able to perform "maintenance".  For example, if that address is used to mine a block, it could force a difficulty adjustment back to something "realistic" within one block without having to wait for the next natural adjustment.
  • Additional maintenance addresses could be created and then included in the code for the wallet.
  • There would be severe limitations placed on what the maintenance addresses could do.  They couldn't modify the block reward or reverse transactions or anything like that


Lastly, while everyone wants to tie their cryptocurrency to the price of fiat...what if there was no way to directly convert/tie the "value" to local fiat for exchange.  Only a mutually agreed upon value when used for barter?  The "handshake" at the end of a closed deal.  I wouldn't be surprised to learn that this was one of the ultimate goals of bitcoin but it's something I've been wondering about.

Anyway, just some musings that I don't have the knowledge to answer for myself or ability to code on my own.  Figured I would throw them out there.
gatra
Hero Member
*****
Offline Offline

Activity: 583
Merit: 505


CTO @ Flixxo, Riecoin dev


View Profile WWW
October 22, 2013, 08:33:03 PM
 #2

if you adjust block reward instead of difficulty, then the difficulty would eventually be too easy, so the network would be flooded with many new blocks each second, creating many orphans.
Also, less difficulty => easier to double spend. It would be hard to decide how many confirmations are needed for a transaction.
Because of network latency, there is a minium difficulty needed for things to work, and that value depends on the time required to generate a block (for a fixed diff), which depends on the hashrate of the network. So you need to adjust difficulty according to network computing power.


           ▄▄▄██████████▄▄▄
       ▄▄██
██████████████████▄▄
     ▄█
█████▀████████████▀██████▄
   ▄█
█████████████████████████████▄
  ▄█
█████████▄█▀▀██████████████████▄
 ▄█
███████████▀██████▄▄█████▄███████▄
▄█
██████████▀██▄▄▄▄██▀▀▀▀▀███████████▄
█████████████▀▀██▀████████▀▀████████
█████████████▄█▀████████████████████
████████▀▀▀▀██▀▀▀▀██████████████████
▀█
██████▀▀▀▀██▀▀▀▀███████████████████▀
 ▀█
███████▄████▄▄███████████████████▀
  ▀█
███████████████████████████████▀
   ▀█
█████████████████████████████▀
     ▀█
█████▄████████████▄██████▀
       ▀▀██
██████████████████▀▀
           ▀▀▀██████████▀▀▀
riecoin       ▄▄█████████▄▄
    ▄██▀▀         ▀▀██▄
  ▄██▀              ▀██▄
 ▄██     ██▄▄          ██▄
▄██      █████▄▄        ██▄
██       ████████▄▄      ██
██       ███████████▄    ██
██       ██████████▀     ██
▀██      ███████▀       ██▀
 ▀██     ████▀         ██▀
  ▀██▄   █▀          ▄██▀
    ▀██▄▄         ▄▄██▀
       ▀▀█████████▀▀
.flixxo   
gatra
Hero Member
*****
Offline Offline

Activity: 583
Merit: 505


CTO @ Flixxo, Riecoin dev


View Profile WWW
October 22, 2013, 08:34:26 PM
 #3

and your maintenance addresses smell like centralization. Who controls those could lower diff at will...


           ▄▄▄██████████▄▄▄
       ▄▄██
██████████████████▄▄
     ▄█
█████▀████████████▀██████▄
   ▄█
█████████████████████████████▄
  ▄█
█████████▄█▀▀██████████████████▄
 ▄█
███████████▀██████▄▄█████▄███████▄
▄█
██████████▀██▄▄▄▄██▀▀▀▀▀███████████▄
█████████████▀▀██▀████████▀▀████████
█████████████▄█▀████████████████████
████████▀▀▀▀██▀▀▀▀██████████████████
▀█
██████▀▀▀▀██▀▀▀▀███████████████████▀
 ▀█
███████▄████▄▄███████████████████▀
  ▀█
███████████████████████████████▀
   ▀█
█████████████████████████████▀
     ▀█
█████▄████████████▄██████▀
       ▀▀██
██████████████████▀▀
           ▀▀▀██████████▀▀▀
riecoin       ▄▄█████████▄▄
    ▄██▀▀         ▀▀██▄
  ▄██▀              ▀██▄
 ▄██     ██▄▄          ██▄
▄██      █████▄▄        ██▄
██       ████████▄▄      ██
██       ███████████▄    ██
██       ██████████▀     ██
▀██      ███████▀       ██▀
 ▀██     ████▀         ██▀
  ▀██▄   █▀          ▄██▀
    ▀██▄▄         ▄▄██▀
       ▀▀█████████▀▀
.flixxo   
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!