[ANN] i0coin - Back from the dead

[markm]

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-

[rsnel]

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.

[markm]

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 did not go there i was contend to use RAM.

If you have something that is not some kind of dirty trick that saves RAM without potentially screwing things 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-

[rsnel]

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.

[markm]

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-

[rsnel]

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?

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.

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?

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

[doublec]

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?

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

[rsnel]

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.

[doublec]

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?

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.

[markm]

Open for registration?

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


-MarkM-

[rsnel]

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

[purelithium]

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.

[worldinacoin]

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

[doublec]

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.

[kelsey]

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

[bitpop]

Why the hell is the blockchain so ducking big?

[doublec]

Why the hell is the blockchain so ducking big?

It's a pretty old coin with a 1.5 minute or so block time. It's a good example of what bitcoin will be like when it gets this many blocks.

[markm]

Why the hell is the blockchain so ducking big?

Merged mined coins include the primary chain's coinbase as proof of the merged mining, and a lot of merged mining happens using p2pool which distributes to its miners in the coinbase so making some pretty huge coinbase transactions...

-MarkM-

[FinShaggy]

Are there ways to earn this coin without mining, maybe by writing?

[Kumala]

I0coin back on Vircurex.com  (incl. your old balances).

https://bitcointalk.org/index.php?topic=294490.new#new