i0coin UPDATES - page 4. | Bitcointalksearch.org

cabin

sr. member

Activity: 604

Merit: 250

The way I understood it was it was just a few minor tweaks to change the block rate and such and boom, that is i0coin.. wouldn't it be easiest to just take the latest stable bitcoin code and just reapply the tweaks? Or was there lots of check-pointing code and such that messes this up?

lightlord

donator

Activity: 3228

Merit: 1226

★Bitvest.io★ Play Plinko or Invest!

Quote from: dreamwatcher on November 17, 2012, 10:52:36 AM

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!! Cheesy

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.

Well I being using this version: Windows x86-32 GUI and Command Line Daemon version 32509
http://i0coin.bitparking.com/

Perhaps the version we should work from.
And it be nice to get i0coin to work with the newer bitcoin client.
Shouldn't be that hard to do that.
Once the memory issues are fixed or dealt with,
Vicruex and the other will open.

And then you will receive your bounty.

Best of luck.
lightlord

dreamwatcher

legendary

Activity: 1064

Merit: 1000

Here are some results from a Memory leak test.

Code:

==11598== Invalid read of size 8
==11598==    at 0x06d64e08: wcscmp (wcscmp.S:479)
==11598==    by 0x06521113: std::moneypunct==11598==    by 0x06521198: std::moneypunct==11598==    by 0x06515a79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    Address 0x74a1258 is 0 bytes after a block of size 8 alloc'd
==11598==    at 0x04c2ac27: operator
==11598==    by 0x06520ded: std::moneypunct==11598==    by 0x0651811e: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    by 0x0651865e: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==
==11598== Invalid read of size 8
==11598==    at 0x06d64e08: wcscmp (wcscmp.S:479)
==11598==    by 0x06521003: std::moneypunct==11598==    by 0x06521088: std::moneypunct==11598==    by 0x06515a79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    Address 0x74a1488 is 0 bytes after a block of size 8 alloc'd
==11598==    at 0x04c2ac27: operator==11598== Invalid read of size 8
==11598==    at 0x06d64e08: wcscmp (wcscmp.S:479)
==11598==    by 0x06521113: std::moneypunct==11598==    by 0x06521198: std::moneypunct==11598==    by 0x06515a79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    Address 0x74a1258 is 0 bytes after a block of size 8 alloc'd
==11598==    at 0x04c2ac27: operator
==11598==    by 0x06520ded: std::moneypunct==11598==    by 0x0651811e: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    by 0x0651865e: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==
==11598== Invalid read of size 8
==11598==    at 0x06d64e08: wcscmp (wcscmp.S:479)
==11598==    by 0x06521003: std::moneypunct==11598==    by 0x06521088: std::moneypunct==11598==    by 0x06515a79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    Address 0x74a1488 is 0 bytes after a block of size 8 alloc'd
==11598==    at 0x04c2ac27: operator
==11598==    by 0x065207fd: std::moneypunct==11598==    by 0x0651816b: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    by 0x0651865e: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    by 0x065207fd: std::moneypunct==11598==    by 0x0651816b: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598==    by 0x0651865e: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==11598== HEAP SUMMARY:
==11598== in use at exit: 88 bytes in 3 blocks
==11598== total heap usage: 3,380 allocs, 3,377 frees, 228,456 bytes allocated
==11598==
==11598== 24 bytes in 1 blocks are still reachable in loss record 1 of 3
==11598==    at 0x04c2b6cd: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11598==    by 0x05d21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11598==    by 0x05aa0c5b: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==11598==    by 0x05aa2d48: SSL_COMP_get_compression_methods (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==11598==
==11598== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==11598==    at 0x04c2b6cd: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11598==    by 0x05d21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11598==    by 0x05d9b8ae: sk_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11598==    by 0x05aa0c39: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==11598==
==11598== 32 bytes in 1 blocks are still reachable in loss record 3 of 3
==11598==    at 0x04c2b6cd: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11598==    by 0x05d21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11598==    by 0x05d9b8cc: sk_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11598==    by 0x05aa0c39: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==11598==
==11598== LEAK SUMMARY:
==11598== definitely lost: 0 bytes in 0 blocks
==11598== indirectly lost: 0 bytes in 0 blocks
==11598== possibly lost: 0 bytes in 0 blocks
==11598== still reachable: 88 bytes in 3 blocks
==11598== suppressed: 0 bytes in 0 blocks

dreamwatcher

legendary

Activity: 1064

Merit: 1000

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!! Cheesy

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.

FuzzyBear

legendary

Activity: 1420

Merit: 1010

Quote from: dreamwatcher on November 17, 2012, 09:12:31 AM

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

legendary

Activity: 1064

Merit: 1000

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?

pyra-proxy

hero member

Activity: 490

Merit: 500

Quote from: lightlord on November 16, 2012, 10:24:14 PM

Quote from: FuzzyBear on November 16, 2012, 08:45:20 PM

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

And that's what I like to hear!

Ditto!

lightlord

donator

Activity: 3228

Merit: 1226

★Bitvest.io★ Play Plinko or Invest!

Quote from: FuzzyBear on November 16, 2012, 08:45:20 PM

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

And that's what I like to hear!

FuzzyBear

legendary

Activity: 1420

Merit: 1010

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

donator

Activity: 3228

Merit: 1226

★Bitvest.io★ Play Plinko or Invest!

dreamwatcher

legendary

Activity: 1064

Merit: 1000

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.

paladin_avatar16

newbie

Activity: 19

Merit: 0

pyra-proxy

hero member

Activity: 490

Merit: 500

lightlord

donator

Activity: 3228

Merit: 1226

★Bitvest.io★ Play Plinko or Invest!

Quote from: Tomatocage on November 15, 2012, 11:24:57 AM

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

Tomatocage

legendary

Activity: 1554

Merit: 1222

brb keeping up with the Kardashians

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?

pyra-proxy

hero member

Activity: 490

Merit: 500

Quote from: steelhouse on November 15, 2012, 02:10:29 AM

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:

- block X - block Y - block Z - block N (then when N hits the next reledgering point)
- 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....

Quote from: Unthinkingbit on November 14, 2012, 07:07:36 PM

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://bitcointalksearch.org/topic/bounty-185-btc-open-transactions-client-for-grandmas-105506

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?

steelhouse

hero member

Activity: 717

Merit: 501

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

hero member

Activity: 490

Merit: 500

Quote from: lightlord on November 14, 2012, 10:50:01 PM

Quote from: dree12 on November 14, 2012, 10:44:29 PM

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)

lightlord

donator

Activity: 3228

Merit: 1226

★Bitvest.io★ Play Plinko or Invest!

Quote from: dree12 on November 14, 2012, 10:44:29 PM

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?

dree12

legendary

Activity: 1246

Merit: 1077

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.

Topic: i0coin UPDATES - page 4. (Read 10012 times)