Topic: [ANN] i0coin - Back from the dead - page 3. (Read 14918 times)

Why the hell is the blockchain so ducking big?

i have a really old client, any current nodes to connect too?

The bitparking pool has now enabled i0coin (and groupcoin) for testing. Let me know if you have any issues. It's currently applying only a percentage of the pool towards i0coin to prevent pool performance issues due to large numbers of block submissions.

I am also using Windows, hopefully they get some binaries out, I guess quite a number of Windows users out here.

Really watching this. I've got a few thousand i0coins that are inaccessible to me due to the memory issues running the client. Hopefully someone can compile some windows binaries once the code is more widely released.

@doublec

Thats great!

I value compatibility with the old client, otherwise I would undermine trust in I0C (I run the old version on my home machine to watch for inconsistencies). These are the forks I prevented:

• BIP16 (P2SH): I postponed that indefinately, until there is community consensus to enable it at some point(commit)
• BIP30 (duplicate transactions): Also postponed. Probably worth enabling (commit)
• There is a possible issue with 'version 2' blocks, if there are too much of then, 'version 1' blocks will be ignored. This is no issue, because getauxblock still produces 'version 1' blocks.
• BDB incompatibility, postponed (commit)

I think these are all the causes for splits.

Greetings,

Rik.

Open for registration?

I already have an I0Coin address registered from when it was on bitparking before, will that one still apply?


-MarkM-

Yes, I'll likely add it it. I'll start with putting some hash rate towards it and see if it's stable before opening it up for registration. Bitcoin 0.8.2+ has been fairly unstable for me when used on the pool. What did you do about about the block forking features added in bitcoin that weren't in i0coin originally? I assume this client can cause block forks due to p2sh support, level db vs bdb differences, etc. This would make it a requirement for your client to be used by everyone pretty quickly. Probably not a big deal since i0coin isn't getting much mining power or exchange presence.

Hi doublec,

Nice to see that you are aware of this thread.

Since I based my work on your's; I'd like to get your opinion on my changes to your code and the draft annoucement.

Also, it it likely that Bitparking will pickup I0C again in the near future?

Greetings,

Rik.

i0coin had merge mining added first. Then ixcoin added it once it was proved to work for i0coin.

I0coin en GeistGeld have a much shorter block period and they are mostly mined on P2Pool. (what's the GG difficulty?)

Let's look at blocks that only have the coinbase transaction.

- normally mined blocks are about 200 bytes in size (eg block 160099)
- merge mined blocks on a centralized pool are about 700 bytes in size (eg block 160093)
- merge mined blocks op P2Pool (recently) are about  8600 bytes (eg block 840000)

The size of merge mined blocks differs so greatly because they must include the coinbase (generate) transaction of the parent blockchain. The coinbase transactions of P2Pool are generally very big, because every pool member gets paid out individually in that transaction.

Example calculation with IXC.

Difficulty 1775893. Approximate hashrate 2^32*1775893/600 = 12712 GH/s. P2Ppool has at most (if everyone merged mined ixc) 3000GH/s (which is probably a lot less, I don't know, it can be researched)

Average size of block 2000kB (25% P2Pool, 75% other pools). Annual growth 2000*6*24*365 = 100MB.

In my first post, I showed that I0C grows 2.7GB/yr.

Please ask for more clarification if some part of the calculation is not clear.


Bitcoin (the parent chain) blocks only have the root merkle hash of all merge mined blockchains. The size is fixed. It's part of the coinbase txin script, in which miners can place whatever data they please. (size is limited by Satoshi client; it will not build on blocks with too much data in txin).

if I0Coin and GeistGeld massive use of RAM is because they are merged mined, why do not all the merged mined coins use that much RAM?

heck they all merge with Bitcoin so why doesn't bitcoin have the same problem since presumably each time a block of something is merged mined against bitcoin, the merkles of all the coins that got a block at the same time are all in the header of the bitcoin block aren't they?

-MarkM-

I agree, 'master' should be for general consumption. I will change it before the announcement. (a draft proposal of the announcement can be found in post #69 above).

The current situation is:
- 'master': meant for merging with bitcoin/master
- 'i0coin-0.8.x': the current recommended version with non-dirty memory fix
- 'dirty-trick' is the dirty trick, this branch is dead and wil not be recommended or updated
- the i0coin-0.y.x branches are for tests (if something doesn't work -> go back a major version and see if it works there)

My fix is clean and it should not screw things up. The three relevant changes are:
https://github.com/rsnel/i0coin/commit/e87d43d38bfb5b60151c575f3ba5f4b504d8c5ea
https://github.com/rsnel/i0coin/commit/c3b64e3c42ffec84c60cb005db04d037a31aedbe
https://github.com/rsnel/i0coin/commit/79ceee30d07ba53d75740ac687a62de9e1e5d32e

I have the illusion that, during porting, I learnt enough about the bitcoin codebase to make these changes. My failings during merging are richly documented in the git history.

Hmm well normally one just goes to someone's github picks the repo and clones it, so that is probably what i did.

I thought you had said the branch stuff was some dirty trick so i dod not go there i was contend to use RAM.

If you have something that is not some kind of dirsty trick that saves RAM without potentially screwing thigns up with some kludgy trick then maybe it should be made master so it is what people get when they do the normal go to repo and clone.

-MarkM-

Thanks, I added dvcstable02 to the list of seednodes.

I see you are running the daemon from branch 'master', tot get the memory usage fix you need the one from branch i0coind-0.8.x. The on disk database format is incompatible between master and i0coind-0.8.x. Both are leveldb, but master uses 1 key for BlockIndex-data and i0coin-0.8.x uses two keys; one for mutable data (block status, undo information) and another for immutable data (block header etc). This makes it possible to update the mutable data in the database without knowing all immutable data (like auxpow).

Greetings,

Rik.

I updated earlier already to your repo and ran it on dvcstable01.dvcnode.org and dvcstable02.dvcnode.org

So maybe I don't have this latest update in place yet. I did get upgraded to the leveldb database though and was able to merged mine i0coin as a secondary chain.

One of them died, maybe from memory getting full so the system had to choose something to kill to make room. That was on dvcstable01 which actually has less RAM than dvcstable02.

i usually do not run i0coin and geistgeld on dvcstable01 anymore as they react too slow for the p2pool merged mining to like it, it complains when they take more than five seconds to reply. So I usually run them on dvcstable02, but sometimes I do have to run on both just so there will be a node to connect to since you cannot mine without being connected to at least one other node.

-MarkM-

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.

create ~/.i0coin/i0coin.conf which contains

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:


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://bitcointalksearch.org/topic/a-complete-guide-to-p2pool-merged-mining-btcnmcdvcixci0c-plus-ltc-linux-62842  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.

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

Greetings,

Rik.

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.

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.