rsnel (OP)
|
|
August 11, 2013, 09:03:38 PM |
|
My bounty receiving address is jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE
20,000 bounty sent. Bounty arrived. Thanks!
|
|
|
|
purelithium
|
|
August 12, 2013, 12:40:29 AM |
|
I'm glad that this coin keeps getting noticed! It's great there is support out there again!
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
rsnel (OP)
|
|
August 12, 2013, 06:36:12 AM Last edit: August 15, 2013, 02:31:20 PM by 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: 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;
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 |
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
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,
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
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
August 12, 2013, 06:49:36 AM |
|
merging the changes from bitcoin into 1 huge hardfork is a good idea, therefore i agree on the hardfork
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
markm
Legendary
Offline
Activity: 2968
Merit: 1098
|
|
August 12, 2013, 02:00:39 PM |
|
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 (OP)
|
|
August 12, 2013, 02:28:44 PM |
|
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 (OP)
|
|
August 12, 2013, 04:20:03 PM |
|
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
|
|
August 12, 2013, 05:27:25 PM |
|
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
|
|
August 13, 2013, 04:22:04 PM |
|
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 (OP)
|
|
August 13, 2013, 05:00:18 PM |
|
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
|
|
August 13, 2013, 05:08:12 PM |
|
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
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
August 13, 2013, 05:10:09 PM |
|
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
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
purelithium
|
|
August 14, 2013, 11:52:18 PM |
|
So has doublec committed to the hardfork? I think that's pretty important, as he's the highest profile pool mining i0coin.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
doublec
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
August 14, 2013, 11:56:20 PM |
|
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 (OP)
|
|
August 15, 2013, 05:49:32 AM |
|
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
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
August 15, 2013, 09:23:16 AM |
|
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 (OP)
|
|
August 15, 2013, 10:14:53 AM |
|
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 (OP)
|
|
August 16, 2013, 05:47:05 AM |
|
i0coin-0.8.3-2 is released, it contains the changes we discussed here, please upgrade as soon as possible
|
|
|
|
purelithium
|
|
August 17, 2013, 03:20:49 AM |
|
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.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
rsnel (OP)
|
|
August 17, 2013, 06:14:05 AM |
|
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: $ ~/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/",
|
|
|
|
|