Topic: [ANN][I0C] Resurrection, memory problems and instabilitiy fixed! - page 4. (Read 22807 times)

$ ~/src/i0coin/src/i0coind getpeerinfo | grep -e subver | sort | uniq -c
      1         "subver" : "",
     12         "subver" : "/Satoshi:0.8.3/",
      9         "subver" : "/Satoshi:0.8.3.1/",
      9         "subver" : "/Satoshi:0.8.3.4/",

commit 84376788462dee4467988ccf6f16eaaf299196b9
Author: Rik Snel 
Date:   Sun Aug 11 14:20:35 2013 +0200

    fix retarget at 890000
    
    I0coins old retarget algorithm is asymmetric; difficulty decrease
    is fast and difficulty increase is slow. This can be abused to
    make a 51% attack more profitable than it should be (thereby
    encouraging it).
    
    This patch changes the retarget algorithm to be on par with
    bitcoin's alogirithm (max factor of 4 every 2016 blocks).
    Since i0coin retargets every 120 blocks, the actual retarget
    factor is 4^(120/2016) = 1.086.
    
    Use integer arithmetic, to make sure that all architectures
    return the exact same answer.

diff --git a/src/main.cpp b/src/main.cpp
index 132ffb4..07339f2 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1236,24 +1236,52 @@ unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast, const CBl
 
     // Limit adjustment step
     int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
-    int64 nTwoPercent = nTargetTimespan/50;
     //printf("  nActualTimespan = %"PRI64d"  before bounds\n", nActualTimespan);
 
-    if (nActualTimespan < nTargetTimespan)  //is time taken for a block less than 3minutes?
-    {
-         //limit increase to a much lower amount than dictates to get past the pump-n-dump mining phase
-        //due to retargets being done more often it also needs to be lowered significantly from the 4x increase
-        if(nActualTimespan<(nTwoPercent*16)) //less than a minute?
-            nActualTimespan=(nTwoPercent*45); //pretend it was only 10% faster than desired
-        else if(nActualTimespan<(nTwoPercent*32)) //less than 2 minutes?
-            nActualTimespan=(nTwoPercent*47); //pretend it was only 6% faster than desired
-        else
-            nActualTimespan=(nTwoPercent*49); //pretend it was only 2% faster than desired
+    // assymmetric retarget (slow difficulty rise / fast difficulty drop) can be
+    // abused to make a 51% attack more profitable than it should be,
+    // therefore we adopt (starting at block 890000) a symmetric algorithm based
+    // on bitcoin's algorithm.
+    //
+    // we retarget at most by a factor of 4^(120/2016) = 1.086
+
+    if (height < 890000) {  // use the old retarget algorithm
+       int64 nTwoPercent = nTargetTimespan/50;
+       if (nActualTimespan < nTargetTimespan)  //is time taken for a block less than 3minutes?
+       {
+            //limit increase to a much lower amount than dictates to get past the pump-n-dump mining phase
+            //due to retargets being done more often it also needs to be lowered significantly from the 4x increase
+            if(nActualTimespan<(nTwoPercent*16)) //less than a minute?
+               nActualTimespan=(nTwoPercent*45); //pretend it was only 10% faster than desired
+            else if(nActualTimespan<(nTwoPercent*32)) //less than 2 minutes?
+                nActualTimespan=(nTwoPercent*47); //pretend it was only 6% faster than desired
+            else
+                nActualTimespan=(nTwoPercent*49); //pretend it was only 2% faster than desired
+
+            //int64 nTime=nTargetTimespan-nActualTimespan;
+            //nActualTimespan = nTargetTimespan/2;
+        }
+        else if (nActualTimespan > nTargetTimespan*4)   nActualTimespan = nTargetTimespan*4;
+    } else { // new algorithm
+        // use integer aritmmetic to make sure that
+        // all architectures return the exact same answers,
+        // so instead of:
+        //
+        //  foo < bar/1.086     we do   foo < (1000*bar)/1086
+        //  foo = bar/1.086     we do   foo = (1000*bar)/1086 
+        //  foo > bar*1.086     we do   foo > (1086*bar)/1000
+        //  foo = bar*1.086     we do   foo = (1086*bar)/1000 
+        //
+        // (parentheses to stress desired operator precedence)
+        //
+        // risk of overflow? no way; bar is quite small and
+        // we have it under control, it is defined as 3*60*60
 
-        //int64 nTime=nTargetTimespan-nActualTimespan;
-        //nActualTimespan = nTargetTimespan/2;
+        if (nActualTimespan < (1000*nTargetTimespan)/1086)
+            nActualTimespan = (1000*nTargetTimespan)/1086;
+        else if (nActualTimespan > (1086*nTargetTimespan)/1000)
+            nActualTimespan = (1086*nTargetTimespan)/1000;
     }
-    else if (nActualTimespan > nTargetTimespan*4)   nActualTimespan = nTargetTimespan*4;
 
     // Retarget
     CBigNum bnNew;

commit d760944021104f81cc732a9a2f9891c10195ed39
Author: Rik Snel 
Date:   Sun Aug 11 14:09:18 2013 +0200

    Enable BIP16 for I0coin on 2013-08-23 0:00 UTC
    
    BIP16 is Pay to Script Hash (P2SH). Which may or may not
    be useful in the future.

diff --git a/src/main.cpp b/src/main.cpp
index 132ffb4..d3a9e73 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1742,8 +1742,9 @@ bool CBlock::ConnectBlock(CValidationState &state, CBlockIndex* pindex, CCoinsVi
         }
     }
 
-    // when will BIP16 be active in I0C? I have no clue. Set it to INT64_MAX for now.
-    int64 nBIP16SwitchTime = 0x7fffffffffffffffLL; //from Bitcoin: 1333238400;
+    // BIP16 will be enabled for I0coin on 2013-08-23 0:00 UTC
+    // date -d "2013-08-23 0:00 UTC" +"%s"
+    int64 nBIP16SwitchTime = 1377216000;
     bool fStrictPayToScriptHash = (pindex->nTime >= nBIP16SwitchTime);
 
     unsigned int flags = SCRIPT_VERIFY_NOCACHE |

commit cabccac5946f48e92b9e3b34b3b15acc546642f0
Author: Rik Snel 
Date:   Sun Aug 11 14:05:03 2013 +0200

    Enable BIP30 for I0coin on 2013-08-23 0:00 UTC
    
    BIP30 disallows duplicate (coinbase) transactions. Creating
    a duplicate coinbase transaction destroys unspent coins from
    the original coinbase transaction.

diff --git a/src/main.cpp b/src/main.cpp
index 132ffb4..5153561 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1721,8 +1721,9 @@ bool CBlock::ConnectBlock(CValidationState &state, CBlockIndex* pindex, CCoinsVi
     //
     // This rule applies to all Bitcoin blocks whose timestamp is after March 15, 2012, 0:00 UTC.
     //
-    // When should this happen in i0coin? Not yet...
-    int64 nBIP30SwitchTime = 0x7fffffffffffffffLL;
+    // BIP30 for I0coin will go into effect on 2013-08-23 0:00 UTC 
+    // date -d "2013-08-23 0:00 UTC" +"%s"
+    int64 nBIP30SwitchTime = 1377216000;
     bool fEnforceBIP30 = (pindex->nTime > nBIP30SwitchTime);
 
     // after BIP30 is enabled for some time, we could make the same change

commit a6caa06588b691013f0507ed5ee9aa36b6137b7c
Author: Rik Snel 
Date:   Sun Aug 11 21:45:35 2013 +0200

    Stop enforcing BDB limits on 2013-08-23 0:00 UTC
    
    Well, I0coin never reached those BDB limits, but since all
    BDB based clients will disappear from the new chain, we
    can safely drop compatibility kludges.

diff --git a/src/main.cpp b/src/main.cpp
index 132ffb4..a639a00 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -2247,9 +2247,9 @@ bool CBlock::CheckBlock(CValidationState &state, int nHeight, bool fCheckPOW, bo
     // Bitcoin had a chain split because of incompatible changes in 0.8.x
     // old releases had some difficulty with large blocks with many transactions
     //
-    // for now, in I0coin, we enforce BDB limits to keep the chain from splitting
-    // Special short-term limits to avoid 10,000 BDB lock limit:
-    if (true)
+    // on 2013-08-23 0:00 UTC we will stop enforcing BDB limits
+    // date -d "2013-08-23 0:00 UTC" +"%s" = 1377216000
+    if (GetBlockTime() < 1377216000)
     {
         // Rule is: #unique txids referenced <= 4,500
         // ... to prevent 10,000 BDB lock exhaustion on old clients
@@ -4376,9 +4376,9 @@ CBlockTemplate* CreateNewBlock(CReserveKey& reservekey)
     // Bitcoin had a chain split because of incompatible changes in 0.8.x
     // old releases had some difficulty with large blocks with many transactions
     //
-    // for now, in I0coin, we enforce BDB limits to keep the chain from splitting
-    // Special short-term limits to avoid 10,000 BDB lock limit:
-    if (true)
+    // on 2013-08-23 0:00 UTC we will stop enforcing BDB limits
+    // date -d "2013-08-23 0:00 UTC" +"%s" = 1377216000
+    if (GetAdjustedTime() < 1377216000)
         nBlockMaxSize = std::min(nBlockMaxSize, (unsigned int)(MAX_BLOCK_SIZE_GEN));
 
     // How much of the block should be dedicated to high-priority transactions,

commit c546f77099265587a5519db1a5fb1773d0b0eea3
Author: Rik Snel 
Date:   Sun Aug 11 14:27:14 2013 +0200

    Don't enforce v2 blocks.
    
    Version 2 blocks have their height encoded in the first 4 bytes of
    the coinbase input script. getauxblock produces v1 blocks.
    
    This can be enabled later if getauxblock is updated and most miners
    produce v2 blocks. (desireable, but it won't cause a hard fork, since
    95% of the miners automatically produce the best chain)

diff --git a/src/main.cpp b/src/main.cpp
index 132ffb4..079c691 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -2349,6 +2349,9 @@ bool CBlock::AcceptBlock(CValidationState &state, CDiskBlockPos *dbp)
         if (!Checkpoints::CheckBlock(nHeight, hash))
             return state.DoS(100, error("AcceptBlock() : rejected by checkpoint lock-in at %d", nHeight));
 
+       // I0coin currently doesn't enforce 2 blocks, since merged mining
+       // produces v1 blocks and normal mining should produce v2 blocks.
+#if 0
         // Reject block.nVersion=1 blocks when 95% (75% on testnet) of the network has upgraded:
         if ((nVersion&0xff) < 2)
         {
@@ -2370,6 +2373,7 @@ bool CBlock::AcceptBlock(CValidationState &state, CDiskBlockPos *dbp)
                     return state.DoS(100, error("AcceptBlock() : block height mismatch in coinbase"));
             }
         }
+#endif
     }
 
     // Write block to history file