[ANN][I0C] Resurrection, memory problems and instabilitiy fixed!

[rsnel]

My bounty receiving address is jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE

20,000 bounty sent.

Bounty arrived. Thanks! 

[1715107172]

1715107172

[1715107172]

1715107172

[1715107172]

1715107172

[1715107172]

1715107172

[purelithium]

I'm glad that this coin keeps getting noticed! It's great there is support out there again!

[rsnel]

When I took maintainership of I0coin, some issues cropped up which require a hardfork to fix. I propose to apply all hardfork-requiring updates that bitcoin has (as far as I know). Furthermore I'd like to fix a possible issue regarding v2 blocks and to change the difficulty adjustment to be slow (as slow as bitcoin on a per block basis) and symmetric.

The proposed release date of the hardforking version is 2013-08-16, the proposed moment of forking is

• block 890000XXXXX regarding the difficulty algorithm update
• 2013-08-23 2013-09-01 0:00 UTC for BIP16/BIP30 and lifting of BDB limits
• disregard supermajority (95%) v2 blocks: immediately (not an issue, because there won't be one)

I will list all proposed patches verbatim, rationale is listed in commit message and comments:

Code:

commit 84376788462dee4467988ccf6f16eaaf299196b9
Author: Rik Snel <rik@snel.it>
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;

Code:

commit d760944021104f81cc732a9a2f9891c10195ed39
Author: Rik Snel <rik@snel.it>
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 |

Code:

commit cabccac5946f48e92b9e3b34b3b15acc546642f0
Author: Rik Snel <rik@snel.it>
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

Code:

commit a6caa06588b691013f0507ed5ee9aa36b6137b7c
Author: Rik Snel <rik@snel.it>
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,

Code:

commit c546f77099265587a5519db1a5fb1773d0b0eea3
Author: Rik Snel <rik@snel.it>
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

Please speak up if you have an opinion on this proposed hardfork. If I proceed, everybody should upgrade before 2013-08-23 0:00 UTC OR block 890000 (whichever is earlier) 2013-09-01 0:00 OR block TO_BE_DETERMINED.

Updates

• switch difficulty adjustments to integer arithmetic, to make sure all architectures return the exact same answer
• move deadline to 1 sep (and corresponding block numer) to give everybody more time to upgrade (this change is not reflected in the patches above)
  

[K1773R]

merging the changes from bitcoin into 1 huge hardfork is a good idea, therefore i agree on the hardfork

[markm]

Why slow difficulty adjustment?

I thought most merged mined coins did some kind of adjustment to be faster than bitcoin in that regard, though maybe that was also how some evidently changed to going down faster than they go up?

GRouPcoin and DeVCoin both use the same system as each other I believe and it seemed to work well. Unless maybe that was the very one that goes down faster than up???

-MarkM-

[rsnel]

Why slow difficulty adjustment?

I thought most merged mined coins did some kind of adjustment to be faster than bitcoin in that regard, though maybe that was also how some evidently changed to going down faster than they go up?

GRouPcoin and DeVCoin both use the same system as each other I believe and it seemed to work well. Unless maybe that was the very one that goes down faster than up???

-MarkM-

A factor of 1.086 allows for a doubling or halving of difficulty over about 1000 blocks (nominal time is a day, so approx 1/2 day for doubling and 2 days for halving). This is already very flexible in my eyes.

I hope a slow adjustment process will lead to less screwing around with the blockchain. If someone with a lot of hashing power wants to increase the difficulty sigificantly, he/she will have to mine a lot of coins and may therefore be motivated to keep supporting the chain.

The designed block rate of I0coin is very high. Even if a large drop of hashing power would occur (say 85%), there would still be a block every 10 minutes. Which is slow, but not unworkable.

So I think 1.086 is fast enough.

If I didn't convince you, please propose a different constant.

[rsnel]

One more thing:

It is not be the smartest idea to rely on floating point math (*1.086). It may lead to every floating point implementation having its own blockchain... I will update the patch to use integer math.

[pyra-proxy]

One more thing:

It is not be the smartest idea to rely on floating point math (*1.086). It may lead to every floating point implementation having its own blockchain... I will update the patch to use integer math.

This is a good thing.  Nice foresight!

[CYPER]

Wow, this coin is alive 

Can you help me with 2 questions:

1 - I read that the i0coin will have to download the entire BTC blockchain. Can I just copy it over as I already have it (I update my BTC client daily). Or even better can I point i0coin to the BTC folder, so they share the blockchain?
2 - In regards to that hardfork - what does that mean in simple terms? Do I have to do something, so I don't lose my coins?

Thank you.

[rsnel]

Hi CYPER,

Wow, this coin is alive 

Can you help me with 2 questions:

1 - I read that the i0coin will have to download the entire BTC blockchain. Can I just copy it over as I already have it (I update my BTC client daily). Or even better can I point i0coin to the BTC folder, so they share the blockchain?
2 - In regards to that hardfork - what does that mean in simple terms? Do I have to do something, so I don't lose my coins?

Thank you.

1. The I0coin client needs to download the entire I0coin blockchain, it goes automatically. The I0coin blockchain is different from the Bitcoin blockchain because the genesis block differs and the rules (difficulty adjusment, reward etc) are different. The size of the blockchain is about 4GB.

2. You have to upgrade to the version I will release friday (unless there will be showstopping issues or complaints by the community; a successfull hardfork is only possible if there is agreement on the necessety of the fork), then you will be on the good branch of the fork. I will urge everybody to upgrade, because the new version includes important security enhancements, it is impossible to fix these issues without EVERYONE (sorry for shouting) having to upgrade.

Greetings,

Rik.

[CYPER]

Thank you for you swift reply.

I started the client about 30 minutes ago and it is downloading it quite fast: 68 weeks left, which is almost about 1/3rd.
In regards to the new fork - we won't lose our coins from before, right?

[K1773R]

Thank you for you swift reply.

I started the client about 30 minutes ago and it is downloading it quite fast: 68 weeks left, which is almost about 1/3rd.
In regards to the new fork - we won't lose our coins from before, right?

nope, no coins would be lost

[purelithium]

So has doublec committed to the hardfork? I think that's pretty important, as he's the highest profile pool mining i0coin.

[doublec]

So has doublec committed to the hardfork? I think that's pretty important, as he's the highest profile pool mining i0coin.

I'll go along with whatever the current coin developer and users prefer. It'll be helpful if there is plenty of time from the release of the code to when it activates. I'm only about 30% of the network though so it'll take time for the new version to get a majority on the network.

[rsnel]

So has doublec committed to the hardfork? I think that's pretty important, as he's the highest profile pool mining i0coin.

I'll go along with whatever the current coin developer and users prefer. It'll be helpful if there is plenty of time from the release of the code to when it activates. I'm only about 30% of the network though so it'll take time for the new version to get a majority on the network.

If you say 'plenty of time', you probably mean more than a week. What timespan do you recommend? (2 weeks, month, 2 months?)

The date is not etched in stone yet, but I'd like to release the forking version tomorrow.

Greetings,

Rik.

[doublec]

If you say 'plenty of time', you probably mean more than a week. What timespan do you recommend? (2 weeks, month, 2 months?)

I'd need a week to schedule testing and upgrade but whatever you think is best beyond that.

[rsnel]

Thanks, doublec, for your comment.

I think it is best to prolong the the transition period by a week and a few days. So, the deadline will be September 1st.

Release is scheduled for tomorrow.
 

[rsnel]

i0coin-0.8.3-2 is released, it contains the changes we discussed here, please upgrade as soon as possible

[purelithium]

I feel like there needs to be a larger announcement than this small post buried in this thread, which is only marked as i0coin by the short name. People searching for an "i0coin" topic by title alone won't find.

rsnel, consider creating a new announcement thread with an informative title to inform the wider user base.

[rsnel]

I feel like there needs to be a larger announcement than this small post buried in this thread, which is only marked as i0coin by the short name. People searching for an "i0coin" topic by title alone won't find.

rsnel, consider creating a new announcement thread with an informative title to inform the wider user base.

It probably wouldn't hurt, will do. Thanks for the suggestion.

On my seednode:

Code:

$ ~/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/",