Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMP<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=813.msg9268#msg9268">Quote from: knightmb on August 14, 2010, 09:04:56 PM</a></div><div class="quote"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=813.msg9265#msg9265">Quote from: gebler on August 14, 2010, 08:51:14 PM</a></div><div class="quote">It's in my original post:<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=813.msg9186#msg9186">Quote from: gebler on August 14, 2010, 12:43:54 PM</a></div><div class="quote">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.&nbsp; 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.<br/><br/>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).&nbsp; 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.<br/></div></div>How will you account for latency and time hacking then?<br/></div><br/>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.</div> text/html