[ANN] i0coin - Back from the dead

[Tomatocage]

Is Art close to being done with the Scrypt ASIC yet?

He hasn't worked on it in a while, it's been on hold.

~BCX~

I guess he's been busy trying to hit 20TH

[TheSwede75]

With 10+ functional coins already established and traded, why would we even need to revive some old crap? Except for the obvious profit potential in hoarding some ancient crap and dumping it, what possible reason is there to 'revive' anything?

[Hazard]

For fun

[Tomatocage]

With 10+ functional coins already established and traded, why would we even need to revive some old crap? Except for the obvious profit potential in hoarding some ancient crap and dumping it, what possible reason is there to 'revive' anything?

That's pretty much what people are saying about Feathercoin

[steelhouse]

I really hope this gets revived, the inflation is very low and there may be bounties if you revive it.

[markm]

Lots of people got it "free" when it was in bitparking's merged mining pool, and since then it has had long long time when anyone could pick some up, so it probably has huge numbers of people holding it by now, even just direct holders not counting people who just use the dI0C tokens in Open Transactions.

Also of course if people sold off a lot in the last days of it being on bitparking's merge list and also on their exchange, someone must have bought what was sold so there are probably peole who invested money into it 9whether bitcoins or whatever) as well as lots and lots of people who mined it.

it is kind of silly to bother with all these orphanfests of the new pump and dumps when you can just stick to merged mining month after month year after year the same stable array of coins.

overall the ancient coins are much more interesting than the new ones, the new ones will start to become intereesting in a year or few when there has been time for lots of people to pick up some after the pump and dump folk have moved on to the next day's batch of new coins.

A big problem with all these recent ones too is how will they ever actually manage to get secured? Without merged mining the hashing just gets more and more diffused day by day.

-MarkM-

[eroxors]

Status on this?

[Tomatocage]

Yeah what's up with i0coin?

[eroxors]

Bump.

[brooksby]

Any progress on the client update?

[markm]

No, like all the other merged mined coins it needs a recent copy of bitcoin with merged mining as secondary chain added, as the common base all the merged mined coins can then customise from.

Unfortunately a DDOS attack fix has recently been added to bitcoin since the last start on making a copy of bitcoin with the merged mining added, so maybe the whole project of adding merged mining as a secondary chain to the bitcoin code might need to be started over yet again using an even more recent copy of bitcoin.

Though i guess that depends on how big the fix for the attack was. Maybe it is just another patch that will need to be applied in addition to finishing up the applying of the merged mining patches.

I0Coin is still humming along even though it does die pretty much every day on some stupid and probably pointless DNS lookup error, so for now just retart it when that error kills it keep on merged mining as usual.

It is actually GeistGeld more than I0Coin that seems in need of an update, since there are fewer people using it, it seems, than are using I0Coin, and that probably means there are less people willing to put up with its RAM consumption than are willing to put up with I0Coin's daily dying.

-MarkM-

[rsnel]

Hi all,

I'd like to share the things i found out while researching the above question.

I0coin is killed by:

• I0coin by keeping all auxpow's in memory
• slow adoption by regular pools
• P2Pool
• high blockrate

Why?

• I0Coin stores all auxpows in memory, because auxpows are included in CBlockHeader and ALL CBlockHeaders are stored in memory, Bitcoin up to at least v0.8.3 does this also.
• Due to normal pools having little support for I0Coin (as opposed to eg. NMC), most of the mining is done in P2Pool
• P2Pool has very large (8kB as opposed to 200B) coinbase transactions (each auxpow has a copy of the full coinbase transaction in the bitcoin block with which it is associated)
• Due to the high blockrate, i0coin's memory usage grew faster than namecoin, ixcoin, devcoin GOTO bullet 2 and repeat ad infinitum

Endresult: i0coin's memory usage grows by at least 8kB per block, which is 8kB*60/1.5*24*365 = 2.7GB per year...  

Solution:

Port I0coin to v0.8.3. I did that https://github.com/rsnel/i0coin/tree/i0coin-0.8.x (I started with doublec's v32509 and merged sucessively higher versions of bitcoin into it). It seems to work fine. (it can do transactions, it can mine blocks that get accepted eg 01f017f6e86c5de539b0137677e6d096bbd2b05d9859c4c25c14c73579644dc8, which is a nVersion=2 block because it includes its nHeight in the coinbase script) On its own, this port uses about 500MB more memory than v32509. (I hoped to solve the problem by doing this port, but that didn't work...)

Then I proceded by, and I agree that this is a bit dirty, just not storing auxpows. This breaks two things:

• response to getheaders request doest not return auxpow part of header (not that bad, because the Satoshi client never issues getheaders requests)
• CBlockIndex:CheckIndex, it just returns true because it doesn't have access to auxpow (see comment in source)

I implemented this in branch dirty-trick. Please try it out, and run this version besides your own i0coind (it uses about 321MB) and keep an eye on it.

Better solution:

Retrieve auxpow's from disk in the two problem cases.

Further work:

• compile on other os's, only tested "make -f makefile.unix i0coind"
• fix logo's in qt client
• stabilize/test 0.8.3 port
• when to enable BIP30?
• much much more
• irc seeding is removed in bitcoin, include good seednodes and setup DNSSeed for i0coin

Greetings,

Rik.

[markm]

So this is probably why GeistGeld uses even more memory than I0Coin, too.

No memory leaks required, these coins are simply showing us what would happen to all the merged coins if people only merged mined them using p2pool.

People who would prefer not to have to use as much memory for merged mined chains thus have an incentive to try to convince pools other than p2pool to merged mine the coins.

As it is, p2pool makes all the coins other than the primary chain into roulette aka solo mining, which will be more and more of a crapshoot as merged mined coins in general go up in difficulty.

So basically anyone who wants I0coin and GeistGeld and, eventually, most other merged mined coins, not to grow in memory needs as fast should set up methods other than p2pool for merged mining them.

They could also consider pledging to the bounty that DeVCoin already has been offering for a long time now, a bounty for software that can be used to in effect make merged mining pools. The current bounty can be won even just by software letting someone offering access to a p2pool node to divvy up the secondary chain coins among the miners; maybe this finding though will motivate a separate bounty that leaves p2pool out of it and specifically wants free open source merged mining pool software to be created.

I will not be running your dirty trick version of I0coin, it does not seem a good idea. RAM is cheap, lets just throw RAM at the problem.

A non dirty trick updated I0Coin is welcome though even if it does consume more RAM. It should download the blockchain much faster and just basically be a better client with all the modern features.

-MarkM-

[ahmed_bodi]

i have possibly come up with a solution to the problem and will be testing it out on bytecoin first before releasing my idea, if it works ill gladly share my idea and any possible code to u guys

[rsnel]

Hello all,

Thanks for the responses. Note that i0coin-0.8.x is a clean port without dirty stuff. It starts and stops much faster than BDB clients. There probably are bugs, so the thing must be watched until the worst ones are inroned out.

WRT the dirty fix... I have a proposal for a clean fix that conserves even more memory.

The huge in-memory table of all block headers is called mapBlockIndex.

I plan on:

• wrapping access to mapBlockIndex (and LevelDB backend) in a class (there only 57 references to it, should be doable)
• within that class serializing directly from LevelDB, possibly introducing an object cache if performance is bad, in extreme cases this cache should be able to contain everything in which case performance should be equal to what it is now (come to think of it, in some cases it is better to skip serialize/unserialize, like in getheaders)
• creating a branch that will be based on bitcoin tag v0.8.2 so that it can be merged in all current branches

Greetings,

Rik.

[markm]

Well the really important question of course is does it actually work as a secondary chain in merged mining?

I tried to find in the code where it sets its aux chain ID as chain number three but could not find it, but then again going back to the old code and looking there I also could not find it. I cannot remember anymore where the merged mined coins set such things.

-MarkM-

[rsnel]

Well the really important question of course is does it actually work as a secondary chain in merged mining?

I tried to ind in the code where it sets its aux chain ID as chain number three but could not find it, but then again going back to the old code and looking there I also could not find it. i cannot remember anymore where the merged mined coins set such things.

-MarkM-

The function GetOurChainID() in main.cpp (around line 2092) sets the id to 2. The blocks that I produced during testing (i stopped mining after two blocks) are still part of the main chain.

See 58e3b1de4853cc237a6af7f784a5fafe76c37210f280a8e06619ae59bb77eec9 and 01f017f6e86c5de539b0137677e6d096bbd2b05d9859c4c25c14c73579644dc8.

So it seems to work.

[markm]

TL;DR They *are* reversed; Ixcoin is 3, I0coin is 2. Weird. Maybe they moved to merged mining in a different order than they were originally created.

Old post:

No, that will not work, I think, as each secondary chain needs a different ID, I think the ID is used as an index into the list of secondary chain merkles or something in the coinbase transaction or the block header or something.

Here are the IDs and default ports of the merged mined coins:

# Chains:
#  0 geistgeld 8777
#  1 namecoin 8336
#  2 ixcoin 8339
#  3 i0coin 7332
#  4 devcoin 52332
#  5 groupcoin 51332
#  7 rucoin 8082
# 16 coiledcoin 9442

RUcoin is no longer a merged mined coin I think, but when it was its ID was 7.

Notice that GiestGeld failed to set a unique ID, it just used bitcoin's ID, so it probably only works due to bitcoin itself never being one of the secondary chains.

So have you actually merged-mined this alongside ixcoin and not found that the IDs clash?'

Or has my list reversed the IDs for Ixcoin and I0coin, like maybe actually Ixcoin is 3 and I0coin is 2 ?

Ixcoin came first though didn't it, so seems likely its number would be lower than I0coin's?

Coiledcoin's 16 reflects the fact they already way back then thought it likely by the time they released their coin several more clones would have popped up!

-MarkM-

TL;DR They *are* reversed; Ixcoin is 3, i0coin is 2. Weird. Maybe they moved to merged mining in a different order than they were originally created.

[rsnel]

I use ixcoin from https://github.com/ixcoin/ixcoin/ it has id 3 in src/main.cpp (master branch).

Greetings,

Rik.

[rsnel]

Edited:

• added a seednode from markm
• transform howto into draft announcement
• added reference to doublec's bitparking pool

---- DRAFT [ANN][I0C] resurrection
---- please comment below if you have suggestions on how to proceed
---- if nobody objects in a couple of days, I will post the announcement in a new thread
---- to attempt to get more people interested
----
---- vircurex has expressed interest in relisting I0C, but the difficulty should be a lot higher
---- making a 51% attack infeasible

I0C, our favourite non-premined, fully decentralised, merged minable altcoin is back. I0coin used to require a lot of memory, about 8.2GB. The updated version only uses about 250MB (fully synced). The problem was fixed by moving data from memory storage to disk storage (this data was almost never used, it just took up space). Technical details are in the git log.

Short instructions on how to join the network, and start merged mining with P2Pool:

The sourcecode is in a git repository on github. The recommended branch (currently i0coin-0.8.x) is automatically selected.

Code:

$ git clone http://github.com/rsnel/i0coin/
$ cd i0coin/src
$ make -f makefile.unix i0coind

create ~/.i0coin/i0coin.conf which contains

Code:

server=1
daemon=1
rpcport=7332
rpcuser=i0coinrpc
rpcpassword=SOME_PASSWORD_HERE
port=7333
addnode=85.17.248.211:7333
addnone=198.154.60.61:7333

Run the daemon and let it sync. Currently there are about 845000 blocks in the blockchain. Please open incoming port 7333 in your firewall, the network needs externally reachable nodes to grow.

Let's earn some coin with P2Pool. Miners that already are merged mining GG,NVC,IXC,DVC already know what to do.

For the rest of us:

Code:

$ git checkout https://github.com/forrestv/p2pool/
$ cd p2pool
$ less README.md
$ # install required packages, you did read the README didn't you?
$ ./run_p2pool.py --give-author 1.0 \
        --merged http://i0coinrpc:SOME_PASSWORD_HERE@localhost:7333/ \
        BITCOINRPC_USERNAME BITCOINRPC_PASSWORD

If you point your miner to localhost:9332 you will earn BTC, it will be sent directly to your wallet. In addition, without extra cost, you will get free I0coins. If you want to earn yet more coins (like IXC,DVC,NMC), please see this excellent topic https://bitcointalk.org/index.php?topic=62842.0  After that you should be able to figure GG out yourself.

Too much hassle? Check out http://mmpool.bitparking.com/pool (BTC 0% DGM, NMC/DVC/IXC/I0C?!?! PPS) to see if they have re-enabled I0C!

I hope that, once there is enough mining power, exchanges will relist this likable coin.

---- END DRAFT ANNOUNCEMENT---
--- rest of original post follows ----

Warning: the on-disk format of the database is not compatible with earlier versions. i0coind will need to rescan blk00??.dat or redownload the blockchain.

The gist of the fix is: fetch auxpow from LevelDB if it is needed.

My idea of caching mapBlockIndex completely is fruitless, because the pointers in it enable efficient traversal of the blocktree (also the bad parts of the blockchain). However, I split DB storage of mutable and immutable parts of C(Disk)BlockIndex, which allows caching of immutable parts.

Request:

The first node listed in the example i0coin.conf is my own server, it is currently syncing it's blockchain against the only other i0coin node that I know of.... (are you on this forum? thanks for keeping the coin alive!) Ideally there should be some more seednodes. Please post your IP address + port, if you want to contribute.

Greetings,

Rik.