i0coin UPDATES

[lightlord]

Ixcoin has value in the market. Reasons for i0coin are its
a non premined currency, community worked based.
Logo voted, designed, work from several others into this.

http://webchat.freenode.net/
#i0coin is the IRC Channel.
Link there and talk live
Download link: http://i0coin.bitparking.com/

The Designs of i0coin:
Voted From community from
other designs:


-Created by Lightlord

Problem that needs to be addressed:
-Memory issues, etc.


Email from Vircurex

Tuesday, November 6, 2012 7:09:58 AM
Dear Lightlord,

We stopped the trading and support of I0C because of the huge memory requirement of the wallet.
We are running our servers in a datacenter, a 2GB memory VPS costs you in the range of 30 USD to 50USD monthly.  
And looking at the growth of the chain, we are anticipating a growth of 80MB per month,
hence sometime end of next year the wallet will require 3GB of memory.    
Unless the memory usage isn't addressed, I see no possibility of supporting the I0C chain.

Regards
Your Vircurex Team


Bounty That is up at the moment:

Paladin_avatar16: 20,000 i0c bounty
Lightlord:          20,000 i0c bounty
steelhouse          5,000 i0c bounty(Up to 25,000 i0c)
pyra-proxy         5,000 i0c bounty(Up to 25,000 i0c/1M DVC/4K IXC/200 NMC)

I am willing to add 5000 coins to a bounty to fix Iocoin. 

Note: If steelhouse can find the 5,000. If he can't find it, I will Match his offer,
and will instead offer 25,000 as a bounty on my part.

Site: http://i0coin.bitparking.com/

More Bounties if the Following criteria is followed:

Actually, I'm going to up my share of the bounty.  On the following conditions:
1)  Vircurex reenables its support of the chain due to the solution - Then my minimum bounty will be 10,000 I0C
2)  If the solution still allows for merge mining (specifically at minimum on the bitparking pool) - Then I'll add an additional 10,000 I0C to the bounty
3)  If the solution can be and is ported to the following chains then further bounty additions from me will be:  (option 2 has to be met for option 3 to go into effect)
3a) DVC - 1,000,000 DVC bounty addition
3b) IXC - 4,000 IXC bounty addition
3c) NMC - 200 NMC bounty addition

Hope that by adding these and perhaps encouraging others that this is a serious concern for the longevity of cryptocurrencies the bounties and development efforts will be increased.

Aah! What the hell ...

I upp my bounty too:

1) I like merged mining - so let's keep it (additional 20,000) ...
2) And yes - an exchange makes sense too (vircurex or any other "significant" exchange - additional 10,000)

hope, that helps as motivation ...

[smoothie]

Someone sounds like they want to take a huge I0coin dump. LOL!

[lightlord]

Someone sounds like they want to take a huge I0coin dump. LOL!

Smoothie, you come on every single i0coin post, always putting it down and stuff, and there was a ton of community work on this.
You are implying that EVERY SINGLE PERSON that helped is planing on dumping i0coin.

You are rude, short sighted, and jumping to conclusions all the time. Some sort of behavior problem?
Or some brain problem? I don't have time to keep fighting you, I am sorry I just had enough with you.

I added you to my ignore list.

[dree12]

The issue with I0Coin is that too many blocks are empty. These blocks are useless except to help secure previous transactions. This ballooning could be solved by forking the chain to temporarily slow target block time to 15 minutes and slowly decrease it to 3 minutes.

[lightlord]

The issue with I0Coin is that too many blocks are empty. These blocks are useless except to help secure previous transactions. This ballooning could be solved by forking the chain to temporarily slow target block time to 15 minutes and slowly decrease it to 3 minutes.

That was one of the suggestions of i0coin. Would forking be a problem for the bounties?
Would the bounties coins from i0coin version 1.0 still be valid in i0coin version 2.0?

[pyra-proxy]

The issue with I0Coin is that too many blocks are empty. These blocks are useless except to help secure previous transactions. This ballooning could be solved by forking the chain to temporarily slow target block time to 15 minutes and slowly decrease it to 3 minutes.

That was one of the suggestions of i0coin. Would forking be a problem for the bounties?
Would the bounties coins from i0coin version 1.0 still be valid in i0coin version 2.0?

I would see this solution as a "band-aid" fix not a permanent (mostly permanent) fix ... i.e. I would recommend the bounty go toward a solution that not only can shrink the size of what is already out there but also employ tactics that keep the size relative to actual system participation (as in based on wallets/addresses that hold > 0 balances etc. so the system may grow as number of users grow but it doesn't just grow for the sake of just adding a new block in the chain even when there has been no new system activity).  I also strongly encourage that the bounty stipulate that merged-mining must still be viable with the fix offered up.

Lastly I'll offer up some to this bounty as well, 5000 I0C - to be paid when vircurex can safely add I0C back into it's exchange (since the coins are frozen there as I had no other use for them with the last reasonable exchange for I0C shutting down)

[steelhouse]

Why not use latest bitcoin/namecoin/ixcoin client with modifications to i0coin sections.  Also, if we stop merged mining, maybe we could use latest bitcoin client.  Smoothie just wants to pump litecoin.  Unfortuantely that is how it is working in these alt-coins.  Let them fail on their own.  95% chance I have the 5000.  No exchange means no coin.  Maybe use PPcoin. solidcoin compressed the chain once. Maybe lengthen the block time. and adjust the frequency every block.  you would think empty blocks would be small.

[pyra-proxy]

Why not use latest bitcoin/namecoin/ixcoin client with modifications to i0coin sections.  Also, if we stop merged mining, maybe we could use latest bitcoin client.  Smoothie just wants to pump litecoin.  Unfortuantely that is how it is working in these alt-coins.  Let them fail on their own.  95% chance I have the 5000.  No exchange means no coin.  Maybe use PPcoin. solidcoin compressed the chain once. Maybe lengthen the block time. and adjust the frequency every block.  you would think empty blocks would be small.

Compressing the chain (solidcoin style) would be a nice addition to the update but not sure how it would be possible w/out creating essentially an I0Coin2, but maybe that will have to happen...  1 idea I had suggested which may avoid needing a "reboot" of the coin would be to create (for lack of a better term) a "dynamic genesis block" whereby every X blocks the history is rolled into a ledger record and then the chain past the ledger could be dropped as being tabulated into the ledgered "checkpoint"/"dynamic genesis block", in this method you could keep standard block hashing, but say every X blocks all the blocks Y in the past are tabulated into a new ledger so that the chain might look like this:

<ledger> - block X - block Y - block Z - block N (then when N hits the next reledgering point)
<new ledger = ledger + block N - reasonable block history to account for orphans/splits> - reasonable block history - New block X

In this method the chain size would dramatically fall to: ledger + X block history + current block ... even if X were 100 or 1000 it would represent a pretty significant drop in resource consumption which some simple analysis could prove even before making the code changes. At 1000 for a value of desired block history the largest the block chain record would be is: ledger + 1999 blocks because at block 2000 you'd create a new ledger and be back at: ledger + 1000 blocks.

regarding letting chains fail on their own:  Devcoin is very interested in solving this and the reason given why there is not a devcoin bounty share on it is that the market cap of devcoin alone is not sufficient to fund this work, BUT the quoted message below was submitted today regarding partial funding for projects which have sufficient funding from other sources, so if I0Coin + others get a reasonable bounty up then it looks like devcoin might also be capable of chipping in as well, of course this means the solution should be easily portable to other *coin chains.  It's certainly something to consider....

Both are too big for devcoin to fund right now.

However, if people are offering a sufficient bounty for people to get interested in a project, for example the 185+ BTC - Open Transactions Client (for Grandmas) project:
https://bitcointalk.org/index.php?topic=105506.0

then I suggest that devcoin pile in with a bounty if the project is at least one quarter funded. In the project types section:
http://devtome.org/wiki/index.php?title=Devcoin_Bounty#Project_Types

it is assumed that the bounty offered would be up to 1% of the market capitalization. So the 1,000,000 USD required for modification to a big application works out to a 10,000 USD bounty, a quarter of which is 2,500 USD.

Should 8 shares be offered if the pledges go above 2,500 USD? Should the pledge target be different?

[Tomatocage]

Lightlord, didn't you design the i0coin logo?

Steelhouse, aren't you that nutjob that wanted the block reward to be something like 1 coin or some shit?

[lightlord]

Lightlord, didn't you design the i0coin logo?

Steelhouse, aren't you that nutjob that wanted the block reward to be something like 1 coin or some shit?

Yes I designed those coins myself

[pyra-proxy]

Why not use latest bitcoin/namecoin/ixcoin client with modifications to i0coin sections.  Also, if we stop merged mining, maybe we could use latest bitcoin client.  Smoothie just wants to pump litecoin.  Unfortuantely that is how it is working in these alt-coins.  Let them fail on their own.  95% chance I have the 5000.  No exchange means no coin.  Maybe use PPcoin. solidcoin compressed the chain once. Maybe lengthen the block time. and adjust the frequency every block.  you would think empty blocks would be small.

Compressing the chain (solidcoin style) would be a nice addition to the update but not sure how it would be possible w/out creating essentially an I0Coin2, but maybe that will have to happen...  1 idea I had suggested which may avoid needing a "reboot" of the coin would be to create (for lack of a better term) a "dynamic genesis block" whereby every X blocks the history is rolled into a ledger record and then the chain past the ledger could be dropped as being tabulated into the ledgered "checkpoint"/"dynamic genesis block", in this method you could keep standard block hashing, but say every X blocks all the blocks Y in the past are tabulated into a new ledger so that the chain might look like this:

<ledger> - block X - block Y - block Z - block N (then when N hits the next reledgering point)
<new ledger = ledger + block N - reasonable block history to account for orphans/splits> - reasonable block history - New block X

In this method the chain size would dramatically fall to: ledger + X block history + current block ... even if X were 100 or 1000 it would represent a pretty significant drop in resource consumption which some simple analysis could prove even before making the code changes. At 1000 for a value of desired block history the largest the block chain record would be is: ledger + 1999 blocks because at block 2000 you'd create a new ledger and be back at: ledger + 1000 blocks.

regarding letting chains fail on their own:  Devcoin is very interested in solving this and the reason given why there is not a devcoin bounty share on it is that the market cap of devcoin alone is not sufficient to fund this work, BUT the quoted message below was submitted today regarding partial funding for projects which have sufficient funding from other sources, so if I0Coin + others get a reasonable bounty up then it looks like devcoin might also be capable of chipping in as well, of course this means the solution should be easily portable to other *coin chains.  It's certainly something to consider....

Both are too big for devcoin to fund right now.

However, if people are offering a sufficient bounty for people to get interested in a project, for example the 185+ BTC - Open Transactions Client (for Grandmas) project:
https://bitcointalk.org/index.php?topic=105506.0

then I suggest that devcoin pile in with a bounty if the project is at least one quarter funded. In the project types section:
http://devtome.org/wiki/index.php?title=Devcoin_Bounty#Project_Types

it is assumed that the bounty offered would be up to 1% of the market capitalization. So the 1,000,000 USD required for modification to a big application works out to a 10,000 USD bounty, a quarter of which is 2,500 USD.

Should 8 shares be offered if the pledges go above 2,500 USD? Should the pledge target be different?

Actually, I'm going to up my share of the bounty.  On the following conditions:
1)  Vircurex reenables its support of the chain due to the solution - Then my minimum bounty will be 10,000 I0C
2)  If the solution still allows for merge mining (specifically at minimum on the bitparking pool) - Then I'll add an additional 10,000 I0C to the bounty
3)  If the solution can be and is ported to the following chains then further bounty additions from me will be:  (option 2 has to be met for option 3 to go into effect)
3a) DVC - 1,000,000 DVC bounty addition
3b) IXC - 4,000 IXC bounty addition
3c) NMC - 200 NMC bounty addition

Hope that by adding these and perhaps encouraging others that this is a serious concern for the longevity of cryptocurrencies the bounties and development efforts will be increased.

[paladin_avatar16]

Why not use latest bitcoin/namecoin/ixcoin client with modifications to i0coin sections.  Also, if we stop merged mining, maybe we could use latest bitcoin client.  Smoothie just wants to pump litecoin.  Unfortuantely that is how it is working in these alt-coins.  Let them fail on their own.  95% chance I have the 5000.  No exchange means no coin.  Maybe use PPcoin. solidcoin compressed the chain once. Maybe lengthen the block time. and adjust the frequency every block.  you would think empty blocks would be small.

Compressing the chain (solidcoin style) would be a nice addition to the update but not sure how it would be possible w/out creating essentially an I0Coin2, but maybe that will have to happen...  1 idea I had suggested which may avoid needing a "reboot" of the coin would be to create (for lack of a better term) a "dynamic genesis block" whereby every X blocks the history is rolled into a ledger record and then the chain past the ledger could be dropped as being tabulated into the ledgered "checkpoint"/"dynamic genesis block", in this method you could keep standard block hashing, but say every X blocks all the blocks Y in the past are tabulated into a new ledger so that the chain might look like this:

<ledger> - block X - block Y - block Z - block N (then when N hits the next reledgering point)
<new ledger = ledger + block N - reasonable block history to account for orphans/splits> - reasonable block history - New block X

In this method the chain size would dramatically fall to: ledger + X block history + current block ... even if X were 100 or 1000 it would represent a pretty significant drop in resource consumption which some simple analysis could prove even before making the code changes. At 1000 for a value of desired block history the largest the block chain record would be is: ledger + 1999 blocks because at block 2000 you'd create a new ledger and be back at: ledger + 1000 blocks.

regarding letting chains fail on their own:  Devcoin is very interested in solving this and the reason given why there is not a devcoin bounty share on it is that the market cap of devcoin alone is not sufficient to fund this work, BUT the quoted message below was submitted today regarding partial funding for projects which have sufficient funding from other sources, so if I0Coin + others get a reasonable bounty up then it looks like devcoin might also be capable of chipping in as well, of course this means the solution should be easily portable to other *coin chains.  It's certainly something to consider....

Both are too big for devcoin to fund right now.

However, if people are offering a sufficient bounty for people to get interested in a project, for example the 185+ BTC - Open Transactions Client (for Grandmas) project:
https://bitcointalk.org/index.php?topic=105506.0

then I suggest that devcoin pile in with a bounty if the project is at least one quarter funded. In the project types section:
http://devtome.org/wiki/index.php?title=Devcoin_Bounty#Project_Types

it is assumed that the bounty offered would be up to 1% of the market capitalization. So the 1,000,000 USD required for modification to a big application works out to a 10,000 USD bounty, a quarter of which is 2,500 USD.

Should 8 shares be offered if the pledges go above 2,500 USD? Should the pledge target be different?

Actually, I'm going to up my share of the bounty.  On the following conditions:
1)  Vircurex reenables its support of the chain due to the solution - Then my minimum bounty will be 10,000 I0C
2)  If the solution still allows for merge mining (specifically at minimum on the bitparking pool) - Then I'll add an additional 10,000 I0C to the bounty
3)  If the solution can be and is ported to the following chains then further bounty additions from me will be:  (option 2 has to be met for option 3 to go into effect)
3a) DVC - 1,000,000 DVC bounty addition
3b) IXC - 4,000 IXC bounty addition
3c) NMC - 200 NMC bounty addition

Hope that by adding these and perhaps encouraging others that this is a serious concern for the longevity of cryptocurrencies the bounties and development efforts will be increased.

Aah! What the hell ...

I upp my bounty too:

1) I like merged mining - so let's keep it (additional 20,000) ...
2) And yes - an exchange makes sense too (vircurex or any other "significant" exchange - additional 10,000)

hope, that helps as motivation ...

[dreamwatcher]

I do not participate in Devcoin, though I might in the future as I learn more about it.

I can offer to make a block explorer for i0coin as my contribution to help this Alt coin.

If i0coin makes it's comeback as discussed in this thread, I will put a block explorer on cryptocoinexplorer.com.

[lightlord]

[FuzzyBear]

hmmmm some nice bounty rewards on this development.... good thing its the weekend and i in need of doing things that require me not to spend money i'll see what I can do!!

[lightlord]

....i'll see what I can do!!

And that's what I like to hear! 

[pyra-proxy]

....i'll see what I can do!!

And that's what I like to hear! 

Ditto!

[dreamwatcher]

I have been testing out the i0coin client, in anticipation of publishing a block explorer.

In the interest of time, does anybody have any ideas on why the client eats up such a massive amount of memory?

I will look at the code, but it will go quicker if I could target in generally why this happens.

I see the memory issue as being the number one problem to solve at this time, not only for site operators and miners but normal users as well. The client just cannot eat up GB of ram and be useable.

Also, anybody know the network version number i0coin uses?

[FuzzyBear]

I have been testing out the i0coin client, in anticipation of publishing a block explorer.

In the interest of time, does anybody have any ideas on why the client eats up such a massive amount of memory?

I will look at the code, but it will go quicker if I could target in generally why this happens.

I see the memory issue as being the number one problem to solve at this time, not only for site operators and miners but normal users as well. The client just cannot eat up GB of ram and be useable.

Also, anybody know the network version number i0coin uses?

yeah memory leak / consumption is what i'm looking at now... but it all new to me so your guess as good as mine atm.... if i find anything i'll post here or PM u

[dreamwatcher]

The i0coin community also needs to decide on a version of client to use.

I have found three so far. The Bitparking versions (Which for some reason I cannot D/L the windows binaries, Firefox stops because it cannot read the last few bytes or so).

I have also seen two different git sites.

Personally I think the newest git version that uses the BTC client 0.6 as it's base would be the best starting point. Although the QT version has a compile problem, it does not look as if it will be that hard to fix. It appears that it wants to use static linking, and the Linux community has been discouraging it in favor of dynamic linking. QT seems to have the biggest problem with the static linking.

The other versions use Widgets for the GUI version, and what a monster that dependency is!!  Qt is also easier for the Windows translation as only a few .DLL files are required to be included with the distribution.

The average person is not going to be running Mingw, so it is in the best interest of the coin that the Windows version be self-contained.


Anyway, those are my thoughts, take 'em or leave 'em.