My bounty receiving address is jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE
20,000 bounty sent.
Bounty arrived. Thanks!
Topic: [ANN][I0C] Resurrection, memory problems and instabilitiy fixed! - page 5. (Read 22807 times)
August 11, 2013, 05:03:38 PM
20,000 bounty sent.
Bounty arrived. Thanks!
August 11, 2013, 03:11:58 PM
My bounty receiving address is jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE
20,000 bounty sent.
August 11, 2013, 05:27:27 AM
@lightlord
I think I met all conditions except introduction at exchanges. I analyzed the problem (incidentally, almost all points on the 'further work' list are addressed at the moment) and eventually implemented a solution, which I defended and which as been adopted by the community @6.1TH/s and about 40 with my seednode. Both vircurex and cryptsy are following the situation closely. They are probably wary of difficulty adjustment problems (as TRC is having now).
Before that, my hard-fork proposal needs to be debated.
I will probably write a pre-announcement with rationale. If there are no objections I will push a version 0.8.3-2 that will fork the chain at some point in the future and will contain
AFAIK these are all the hardfork requiring fixes from recent bitcoin.
My bounty receiving address is jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE
I think I met all conditions except introduction at exchanges. I analyzed the problem (incidentally, almost all points on the 'further work' list are addressed at the moment) and eventually implemented a solution, which I defended and which as been adopted by the community @6.1TH/s and about 40 with my seednode. Both vircurex and cryptsy are following the situation closely. They are probably wary of difficulty adjustment problems (as TRC is having now).
Before that, my hard-fork proposal needs to be debated.
I will probably write a pre-announcement with rationale. If there are no objections I will push a version 0.8.3-2 that will fork the chain at some point in the future and will contain
- symmetric and slow (as fast as bitcoin) adjustment
- BIP16
- BIP30
- perpetual acceptance of v1 blocks
- bdb limits lifted
AFAIK these are all the hardfork requiring fixes from recent bitcoin.
My bounty receiving address is jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE
August 11, 2013, 05:12:09 AM
https://bitcointalksearch.org/topic/i0coin-updates-124316
Yes there is a 20,000 i0coin bounty for the fix of the bug.
It will be a while to download the entire i0coin block chain.
Post your address, so I can send your bounty.
There is other bounties up, so post in that thread
stating the fix and PM them.
Best regards
Lightlord
Yes there is a 20,000 i0coin bounty for the fix of the bug.
It will be a while to download the entire i0coin block chain.
Post your address, so I can send your bounty.
There is other bounties up, so post in that thread
stating the fix and PM them.
Best regards
Lightlord
August 11, 2013, 04:21:22 AM
im against hard forking
EDIT: im ok with hardforking if we bundle up alot of fixed and backports from bitcoin
ie, make it worth
EDIT: im ok with hardforking if we bundle up alot of fixed and backports from bitcoin
ie, make it worth August 11, 2013, 02:48:34 AM
@doublec
It is good to hear that other large miners have picked I0coin up. Just keep ramping up the hashrate...
What's your opinion on the possible hard fork? Will you support it? I specifically need announcements on the i0coin.bitparking.com website and the poolwebsite itself.
Well, I wouldn't blame the exchanges if they waited until bitparking has < 50% of the hashrate (more pools/p2pminers needed!). Bitparking has 25% of ixcoin, it must be coming from somewhere (private instances of p2pool?). (auxpows can now be examined through getblock in latest git).
Bitparking has currently around 50 immature blocks out of 120. It floats from 30-55 over the last few days. That means it has less than 50% of the hash rate. Bitparkings entire hashrate isn't used on i0coin as I don't react to blocks found meaning I get a lot of stale share submissions. There's at least one other big miner mining the chain. For ixcoin and devcoin there are other big miners mining it too - When I last investigated it was disqus fish and/or 'made in china' IIRC.It is good to hear that other large miners have picked I0coin up. Just keep ramping up the hashrate...
What's your opinion on the possible hard fork? Will you support it? I specifically need announcements on the i0coin.bitparking.com website and the poolwebsite itself.
August 10, 2013, 07:41:30 PM
Well, I wouldn't blame the exchanges if they waited until bitparking has < 50% of the hashrate (more pools/p2pminers needed!). Bitparking has 25% of ixcoin, it must be coming from somewhere (private instances of p2pool?). (auxpows can now be examined through getblock in latest git).
Bitparking has currently around 50 immature blocks out of 120. It floats from 30-55 over the last few days. That means it has less than 50% of the hash rate. Bitparkings entire hashrate isn't used on i0coin as I don't react to blocks found meaning I get a lot of stale share submissions. There's at least one other big miner mining the chain. For ixcoin and devcoin there are other big miners mining it too - When I last investigated it was disqus fish and/or 'made in china' IIRC. August 10, 2013, 04:13:05 PM
It's not officially undead til it has an exchange
Well, I wouldn't blame the exchanges if they waited until bitparking has < 50% of the hashrate (more pools/p2pminers needed!). Bitparking has 25% of ixcoin, it must be coming from somewhere (private instances of p2pool?). (auxpows can now be examined through getblock in latest git).
Also the proposed hard fork, may sound scary....
August 10, 2013, 03:35:28 PM
About the vulnerability discussed by xorxor and markm.
I read some threads about the "asymmetric adjustment", most notably this post:
https://bitcointalksearch.org/topic/m.555148
If I understand it correctly, an asymmetric adjustment makes a 51% attack more profitable, because an alternate chain can be produced which has the same amount of work as the original chain and is a lot higher.
This is obviously bad, since it encourages 51% attacks. Judging from the difficulty we only have 111622.573485*2^32/90=5.3TH/s at our disposal (about 1/4 of ixcoin). Due to merged mining, we can be attacked for free...
Also, the limit (factor of 4) to the adjustments is too large, compared to the amount of blocks that are part of the computation.
To play it safe, I think we should use bitcoin as a baseline, and try not to deviate too much. I0coin adjusts over a period of 120 blocks. Bitcoin readjusts every 2016 blocks. So the retarget should be limited by about 4^(120/2016) = 1.086.
Is this too conservative? What other value is reasonable?
Letting this new retarget rule commence at block XXXXXX will cause a hard fork. Announcements will be needed on pools, this topic, homepages (old i0coin page at bitparking and new one by me). It would be nice to reach some community consensus before doing such a thing.
The patch would look like this:
Comments?
Edit:
I read some threads about the "asymmetric adjustment", most notably this post:
https://bitcointalksearch.org/topic/m.555148
If I understand it correctly, an asymmetric adjustment makes a 51% attack more profitable, because an alternate chain can be produced which has the same amount of work as the original chain and is a lot higher.
This is obviously bad, since it encourages 51% attacks. Judging from the difficulty we only have 111622.573485*2^32/90=5.3TH/s at our disposal (about 1/4 of ixcoin). Due to merged mining, we can be attacked for free...
Also, the limit (factor of 4) to the adjustments is too large, compared to the amount of blocks that are part of the computation.
To play it safe, I think we should use bitcoin as a baseline, and try not to deviate too much. I0coin adjusts over a period of 120 blocks. Bitcoin readjusts every 2016 blocks. So the retarget should be limited by about 4^(120/2016) = 1.086.
Is this too conservative? What other value is reasonable?
Letting this new retarget rule commence at block XXXXXX will cause a hard fork. Announcements will be needed on pools, this topic, homepages (old i0coin page at bitparking and new one by me). It would be nice to reach some community consensus before doing such a thing.
The patch would look like this:
Code:
diff --git a/src/main.cpp b/src/main.cpp
index 132ffb4..186fb91 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1236,6 +1236,9 @@ unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast, const CBl
// Limit adjustment step
int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
+
+ if (height < XXXXXX) {
+
int64 nTwoPercent = nTargetTimespan/50;
//printf(" nActualTimespan = %"PRI64d" before bounds\n", nActualTimespan);
@@ -1255,6 +1258,11 @@ unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast, const CBl
}
else if (nActualTimespan > nTargetTimespan*4) nActualTimespan = nTargetTimespan*4;
+ } else {
+ if (nActualTimespan < nTargetTimespan/1.086) nActualTimespan = nTargetTimespan/1.086;
+ else if (nActualTimespan > nTargetTimespan*1.086) nActualTimespan = nTargetTimespan*1.086;
+ }
+
// Retarget
CBigNum bnNew;
bnNew.SetCompact(pindexLast->nBits);
Comments?
Edit:
- original indent kept for readability
- anyone against activating BIP16 and BIP30?
- something must be done about the block versions, I propose to keep accepting v1 blocks (since a non merged miner would generate v2 blocks, and a supermajority of v2 blocks will lead to non-acceptance of v1 blocks)
- these are the blocks that violate BIP30 at this moment, they contain a copy of an earlier coinbase transaction, therby invalidating unspent coins in the earlier coinbase
Code:
BLOCK 512462 FAILS BIP30
BLOCK 512463 FAILS BIP30
BLOCK 512464 FAILS BIP30
BLOCK 512467 FAILS BIP30
BLOCK 512479 FAILS BIP30
BLOCK 855597 FAILS BIP30
BLOCK 855599 FAILS BIP30
BLOCK 855602 FAILS BIP30
BLOCK 855604 FAILS BIP30
BLOCK 855605 FAILS BIP30
BLOCK 855608 FAILS BIP30
BLOCK 855610 FAILS BIP30
BLOCK 855612 FAILS BIP30
BLOCK 855614 FAILS BIP30
BLOCK 855616 FAILS BIP30
BLOCK 855618 FAILS BIP30
BLOCK 855622 FAILS BIP30
BLOCK 855625 FAILS BIP30
BLOCK 855629 FAILS BIP30
BLOCK 855631 FAILS BIP30
BLOCK 855633 FAILS BIP30
- we can also drop the bdb limits on blocks
August 10, 2013, 02:39:31 PM
It's not officially undead til it has an exchange
August 10, 2013, 01:53:34 PM
Oh darn, it lets difficulty drop more than it lets it rise?
All coins that do that need to be fixed. I guess it was a fashionable thing to do at some point in the distant past.
-MarkM-
All coins that do that need to be fixed. I guess it was a fashionable thing to do at some point in the distant past.
-MarkM-
August 10, 2013, 12:25:47 PM
Hi xorxor,
I0coin is officially undead! Whooohooo!
Regarding the percentage of coins already in circulation; it is much worse that you said before.
I0coin started with a block subsidy of 48 coins per block. It halves every 218750 blocks. At most, there will be 96*218750 = 21000000 coins.
Now, say at block 850000, we have (48 + 24 + 12)*218750 + 6 * (850000 - 3*218750) = 19537500 coins in circulation. This means 93% of the coins are already mined. Fortunately this coin can be mined for free, so miners do not have to live off of transaction fees.
You also warned about a possible attack on I0coin.
The code you quote has in some cases a lower limit for difficulty changes smaller than 4, but not in the default case. I believe this is to prevent coin hopping (a lot of hashrate on a coin -> very high difficulty -> miners go to another coin -> blockchain moves very slow).
Note that I0coin has the anti-timewarp patch from solidcoin.
Is the vulnerability you talk about documented somewhere, can you point me to a thread or an example?
Greetings,
Rik.
I0coin is officially undead! Whooohooo!
Regarding the percentage of coins already in circulation; it is much worse that you said before.
I0coin started with a block subsidy of 48 coins per block. It halves every 218750 blocks. At most, there will be 96*218750 = 21000000 coins.
Now, say at block 850000, we have (48 + 24 + 12)*218750 + 6 * (850000 - 3*218750) = 19537500 coins in circulation. This means 93% of the coins are already mined. Fortunately this coin can be mined for free, so miners do not have to live off of transaction fees.
You also warned about a possible attack on I0coin.
Quote from: xorxor
also, this coin can be fcuk'ed inside-out by any basic coder and <1% attacked LOL!!!
The code you quote has in some cases a lower limit for difficulty changes smaller than 4, but not in the default case. I believe this is to prevent coin hopping (a lot of hashrate on a coin -> very high difficulty -> miners go to another coin -> blockchain moves very slow).
Note that I0coin has the anti-timewarp patch from solidcoin.
Is the vulnerability you talk about documented somewhere, can you point me to a thread or an example?
Greetings,
Rik.
You can time-attack not only by compressing time and therefore speeding up your miner relatively. this attack can be patched against. it can be detected because the longer chain has bad time.
I0coin [not only I0C, a lot of devs doesn't get it ant tries to fasten diff algo that way] uses heavily asymetric towards drop diff adjustment, which can be attacked differently.
First you compress the time, than strech it perfectly to get maximum drop but to more. this way you can drop diff to zero, with proper time. now you mine SHITLOAD of blocks and introduce it to the network. BUM! much higher chain, timestamps are correct => doublespending and freemining.
August 10, 2013, 11:53:13 AM
I am not sure if a bounty ever did get offered for the "mergecoin" thing, just the basic applying of the merged mining as secondary chain patches to bitcoin.
If so I think this update of I0Coin serves fine to accomplish the same end as the mergecoin thing would have so you should get it if indeed such a bounty did end up getting offered. I just don't recall if it did or not.
(It would have been a DeVCoin bounty, in the DeVCoin thread.)
-MarkM-
If so I think this update of I0Coin serves fine to accomplish the same end as the mergecoin thing would have so you should get it if indeed such a bounty did end up getting offered. I just don't recall if it did or not.
(It would have been a DeVCoin bounty, in the DeVCoin thread.)
-MarkM-
August 10, 2013, 11:02:14 AM
@rsnel:
there has been a bounty of several thousand i0coins if someone fixes the i0coin problems, i just messaged lightlord to pay you the bounty
Thanks, I knew there was a bounty.there has been a bounty of several thousand i0coins if someone fixes the i0coin problems, i just messaged lightlord to pay you the bounty
But a condition is that the coin is listed on some major exchange. I expect it to happen, but it hasn't happened yet.
That was only for a portion of the bounty, for some of the bount(ies) you've already earned them I think....
August 10, 2013, 05:32:05 AM
@rsnel:
there has been a bounty of several thousand i0coins if someone fixes the i0coin problems, i just messaged lightlord to pay you the bounty
Thanks, I knew there was a bounty.there has been a bounty of several thousand i0coins if someone fixes the i0coin problems, i just messaged lightlord to pay you the bounty
But a condition is that the coin is listed on some major exchange. I expect it to happen, but it hasn't happened yet.
August 10, 2013, 05:14:50 AM
@rsnel:
there has been a bounty of several thousand i0coins if someone fixes the i0coin problems, i just messaged lightlord to pay you the bounty
there has been a bounty of several thousand i0coins if someone fixes the i0coin problems, i just messaged lightlord to pay you the bounty
August 10, 2013, 04:35:24 AM
I0coin is officially undead! Whooohooo!
Iz0mbieCoin! August 09, 2013, 06:13:39 PM
Hi xorxor,
I0coin is officially undead! Whooohooo!
Regarding the percentage of coins already in circulation; it is much worse that you said before.
I0coin started with a block subsidy of 48 coins per block. It halves every 218750 blocks. At most, there will be 96*218750 = 21000000 coins.
Now, say at block 850000, we have (48 + 24 + 12)*218750 + 6 * (850000 - 3*218750) = 19537500 coins in circulation. This means 93% of the coins are already mined. Fortunately this coin can be mined for free, so miners do not have to live off of transaction fees.
You also warned about a possible attack on I0coin.
The code you quote has in some cases a lower limit for difficulty changes smaller than 4, but not in the default case. I believe this is to prevent coin hopping (a lot of hashrate on a coin -> very high difficulty -> miners go to another coin -> blockchain moves very slow).
Note that I0coin has the anti-timewarp patch from solidcoin.
Is the vulnerability you talk about documented somewhere, can you point me to a thread or an example?
Greetings,
Rik.
I0coin is officially undead! Whooohooo!
Regarding the percentage of coins already in circulation; it is much worse that you said before.
I0coin started with a block subsidy of 48 coins per block. It halves every 218750 blocks. At most, there will be 96*218750 = 21000000 coins.
Now, say at block 850000, we have (48 + 24 + 12)*218750 + 6 * (850000 - 3*218750) = 19537500 coins in circulation. This means 93% of the coins are already mined. Fortunately this coin can be mined for free, so miners do not have to live off of transaction fees.
You also warned about a possible attack on I0coin.
Quote from: xorxor
also, this coin can be fcuk'ed inside-out by any basic coder and <1% attacked LOL!!!
The code you quote has in some cases a lower limit for difficulty changes smaller than 4, but not in the default case. I believe this is to prevent coin hopping (a lot of hashrate on a coin -> very high difficulty -> miners go to another coin -> blockchain moves very slow).
Note that I0coin has the anti-timewarp patch from solidcoin.
Is the vulnerability you talk about documented somewhere, can you point me to a thread or an example?
Greetings,
Rik.
August 09, 2013, 02:40:21 PM
@rsnel:
you have a little typo in makefile.unix in/src/
it should be
as there is no build target i0coin, only i0coind
you had issues disabled @ github so i report it here
you have a little typo in makefile.unix in
Code:
all: i0coin
Code:
all: i0coind
you had issues disabled @ github so i report it here
Thanks. It is fixed.
Greetings,
Rik.
August 09, 2013, 01:31:58 PM
Jump to: