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

[K1773R]

@rsnel:

you have a little typo in makefile.unix in <git>/src/

Code:

all: i0coin

it should be

Code:

all: i0coind

as there is no build target i0coin, only i0coind

you had issues disabled @ github so i report it here

[1715319764]

1715319764

[1715319764]

1715319764

[1715319764]

1715319764

[xorxor]

https://bitcointalk.org/index.php?topic=134179.msg2899812#msg2899812



I moved I0Coin from the "dead" section

[rsnel]

@rsnel:

you have a little typo in makefile.unix in <git>/src/

Code:

all: i0coin

it should be

Code:

all: i0coind

as there is no build target i0coin, only i0coind

you had issues disabled @ github so i report it here

Thanks. It is fixed.

Greetings,

Rik.

[rsnel]

Hi xorxor,

https://bitcointalk.org/index.php?topic=134179.msg2899812#msg2899812

I moved I0Coin from the "dead" section

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.

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.

[K1773R]

I0coin is officially undead! Whooohooo!

Iz0mbieCoin!

[K1773R]

@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

[rsnel]

@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.

But a condition is that the coin is listed on some major exchange. I expect it to happen, but it hasn't happened yet.

[pyra-proxy]

@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.

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....

[markm]

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-

[xorxor]

Hi xorxor,

https://bitcointalk.org/index.php?topic=134179.msg2899812#msg2899812

I moved I0Coin from the "dead" section

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.

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.

[markm]

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-

[Tomatocage]

It's not officially undead til it has an exchange

[rsnel]

About the vulnerability discussed by xorxor and markm.

I read some threads about the "asymmetric adjustment", most notably this post:
https://bitcointalk.org/index.php?topic=46498.msg555148#msg555148

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

[rsnel]

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....

[doublec]

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.

[rsnel]

@doublec

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.

[K1773R]

im against hard forking

EDIT: im ok with hardforking if we bundle up alot of fixed and backports from bitcoin ie, make it worth

[lightlord]

https://bitcointalk.org/index.php?topic=124316.0

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

[rsnel]

@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

• 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

[lightlord]

My bounty receiving address is jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE

20,000 bounty sent.