Title: i0coin UPDATES
Post by: lightlord on November 15, 2012, 03:37:01 AM
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: http://s10.postimage.org/csqwvwcpx/i0coin32_X32.pnghttp://s10.postimage.org/lcaatnl2d/i0coin64_X64.pnghttp://s10.postimage.org/ni4lo5oit/i0coin128_X128.png http://s9.postimage.org/nk65flt5b/i05_Updatedagainfinal3.png-Created by Lightlord Problem that needs to be addressed:-Memory issues, etc. Email from VircurexTuesday, 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 bountyLightlord: 20,000 i0c bountysteelhouse 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 ...
Title: Re: i0coin UPDATES
Post by: smoothie on November 15, 2012, 03:37:53 AM
Someone sounds like they want to take a huge I0coin dump. LOL!
Title: Re: i0coin UPDATES
Post by: lightlord on November 15, 2012, 03:40:21 AM
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. http://s12.postimage.org/e89g00a4t/smoothie.png
Title: Re: i0coin UPDATES
Post by: dree12 on November 15, 2012, 03:44:29 AM
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.
Title: Re: i0coin UPDATES
Post by: lightlord on November 15, 2012, 03:50:01 AM
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?
Title: Re: i0coin UPDATES
Post by: pyra-proxy on November 15, 2012, 05:15:32 AM
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)
Title: Re: i0coin UPDATES
Post by: steelhouse on November 15, 2012, 07: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.
Title: Re: i0coin UPDATES
Post by: pyra-proxy on November 15, 2012, 08:50:11 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: <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?
Title: Re: i0coin UPDATES
Post by: Tomatocage on November 15, 2012, 04:24:57 PM
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?
Title: Re: i0coin UPDATES
Post by: lightlord on November 16, 2012, 12:09:07 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
Title: Re: i0coin UPDATES
Post by: pyra-proxy on November 16, 2012, 08:50:39 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: <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.
Title: Re: i0coin UPDATES
Post by: paladin_avatar16 on November 16, 2012, 04:30:38 PM
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 ...
Title: Re: i0coin UPDATES
Post by: dreamwatcher on November 16, 2012, 05:44:21 PM
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.
Title: Re: i0coin UPDATES
Post by: lightlord on November 16, 2012, 11:46:50 PM
Title: Re: i0coin UPDATES
Post by: FuzzyBear on November 17, 2012, 01:45:20 AM
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!!
Title: Re: i0coin UPDATES
Post by: lightlord on November 17, 2012, 03:24:14 AM
....i'll see what I can do!!
And that's what I like to hear! :)
Title: Re: i0coin UPDATES
Post by: pyra-proxy on November 17, 2012, 12:11:30 PM
....i'll see what I can do!!
And that's what I like to hear! :) Ditto!
Title: Re: i0coin UPDATES
Post by: dreamwatcher on November 17, 2012, 02:12:31 PM
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?
Title: Re: i0coin UPDATES
Post by: FuzzyBear on November 17, 2012, 02:53:55 PM
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
Title: Re: i0coin UPDATES
Post by: dreamwatcher on November 17, 2012, 03:52:36 PM
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!! :D 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. :)
Title: Re: i0coin UPDATES
Post by: dreamwatcher on November 18, 2012, 12:06:22 AM
Here are some results from a Memory leak test. ==11598== Invalid read of size 8
==11598== at 0x06d64e08: wcscmp (wcscmp.S:479)
==11598== by 0x06521113: std::moneypunct<wchar_t,
==11598== by 0x06521198: std::moneypunct<wchar_t,
==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<wchar_t,
==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<wchar_t,
==11598== by 0x06521088: std::moneypunct<wchar_t,
==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<wchar_t,
==11598== by 0x06521198: std::moneypunct<wchar_t,
==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<wchar_t,
==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<wchar_t,
==11598== by 0x06521088: std::moneypunct<wchar_t,
==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<wchar_t,
==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<wchar_t,
==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
Title: Re: i0coin UPDATES
Post by: lightlord on November 18, 2012, 02:55:17 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!! :D 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
Title: Re: i0coin UPDATES
Post by: cabin on November 18, 2012, 04:30:01 PM
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?
Title: Re: i0coin UPDATES
Post by: FuzzyBear on November 18, 2012, 04:42:04 PM
Here are some results from a Memory leak test. ==11598== Invalid read of size 8
==11598== at 0x06d64e08: wcscmp (wcscmp.S:479)
==11598== by 0x06521113: std::moneypunct<wchar_t,
==11598== by 0x06521198: std::moneypunct<wchar_t,
==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<wchar_t,
==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<wchar_t,
==11598== by 0x06521088: std::moneypunct<wchar_t,
==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<wchar_t,
==11598== by 0x06521198: std::moneypunct<wchar_t,
==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<wchar_t,
==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<wchar_t,
==11598== by 0x06521088: std::moneypunct<wchar_t,
==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<wchar_t,
==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<wchar_t,
==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
From this I take it that there are objects not being disposed properly... hence why they are ... ==11598== still reachable: 88 bytes in 3 blocks and this will just build up over time... all this code is new to me, but i am making progress in breaking down the code, so will update if i find anything of interest, but don't expect it in the next few hours that's all i'm saying!! 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?
I don't know enough about this tbh.. but would be lovely if we could just grab the latest BTC client and change it to I0Coin, but someone else maybe able to clarify if this is a valid possibility or not...
Title: Re: i0coin UPDATES
Post by: markm on November 18, 2012, 07:37:35 PM
That hardest part will be applying the merged mining patch to a recent copy of bitcoin, since bitcoin still lacks the ability to be a secondary chain when merged mining.
-MarkM-
Title: Re: i0coin UPDATES
Post by: dreamwatcher on November 19, 2012, 03:51:33 PM
Can anybody point me to some whitepapers on i0coin?
Any kind of technical document on how exactly i0coin differs from Bitcoin.
I also would like to get some feedback on why the i0client based on the Bitcoin 0.6.3 client is not widely used, but rather a client based on Bitcoin 0.3.24 is?
The git to the 0.6.3 is https://github.com/doublec/i0coin/tree/based_on_bitcoin_0.6.3 (https://github.com/doublec/i0coin/tree/based_on_bitcoin_0.6.3).
I have a hard time testing it out as I can only get 0-1 peers using that version.
I have a couple of theories on what is happening with the memory and I will continue to work on version 032509, but it would really make more sense to work on a later version.
Also, any ideas on why I cannot download the Windows binaries from http://i0coin.bitparking.com (http://i0coin.bitparking.com) ? Both Firefox and Iron stop unable to read the last few bytes or so. (Linux and Windows browsers)
Title: Re: i0coin UPDATES
Post by: doublec on November 20, 2012, 01:44:24 AM
Any kind of technical document on how exactly i0coin differs from Bitcoin.
The original patches are the only thing I know of. I also would like to get some feedback on why the i0client based on the Bitcoin 0.6.3 client is not widely used, but rather a client based on Bitcoin 0.3.24 is?
The git to the 0.6.3 is https://github.com/doublec/i0coin/tree/based_on_bitcoin_0.6.3 (https://github.com/doublec/i0coin/tree/based_on_bitcoin_0.6.3).
I have a hard time testing it out as I can only get 0-1 peers using that version.
That branch was a work in progress of my own to port i0coin to a more recent bitcoin. Unfortunately the new nodes were not getting peers and I lacked time to investigate. I have a couple of theories on what is happening with the memory and I will continue to work on version 032509, but it would really make more sense to work on a later version.
The high memory usage is inherited from bitcoin. My bitcoin node uses >1GB at times as well. With i0coin's faster blocks it uses more. Also, any ideas on why I cannot download the Windows binaries from http://i0coin.bitparking.com (http://i0coin.bitparking.com) ? Both Firefox and Iron stop unable to read the last few bytes or so. (Linux and Windows browsers)
I don't know why this would be happening.
Title: Re: i0coin UPDATES
Post by: steelhouse on November 20, 2012, 07:48:59 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?
I am for a no inflation coin. mining is not work, it is a technique to distribute coins. Thus block reward = 0, except for the costs of maintaining the system. http://www.youtube.com/watch?v=TEFQC0IX9-4 http://www.youtube.com/watch?v=DfwQzlrea7Y
Title: Re: i0coin UPDATES
Post by: lightlord on November 27, 2012, 07:43:51 AM
Title: Re: i0coin UPDATES
Post by: markm on November 27, 2012, 11:08:54 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?
I am for a no inflation coin. mining is not work, it is a technique to distribute coins. Thus block reward = 0, except for the costs of maintaining the system. http://www.youtube.com/watch?v=TEFQC0IX9-4 http://www.youtube.com/watch?v=DfwQzlrea7Y There are no-inflation coins, there are plenty of techniques for distributing coins, the block reward method simply happens to also help get miners to mine for a few years initially. It is a very expensive way of getting them to mine, but it has worked (so far...) for a few chains. -MarkM-
Title: Re: i0coin UPDATES
Post by: dreamwatcher on December 12, 2012, 03:11:41 PM
Just a quick update: I have modified doublec's 0.6.3 i0client so that it connects and communicates with peers on the I0coin network. This client still eats about 1.8 GB Ram. I have spent hours and hours tracing and even debugging step by step with Nemiver. The memory gets taken up with an ever growing heap size during the initial blkindex load up. I am seeing many uninitialized memcopy and variables. I also noticed a trend away from the BTC client towards using unsigned integers in places where signed integers are are normally used. Is there a reason for this change? I also noticed the replacement in the line of code the checks blocks (block.CheckBlock((INT_MAX))). It is my understating the INT_MAX is a system constant for the maximum value of the integer class of variable. Why is that being used? Below I have a more detailed Valgrind report: Continued in the next post. =3211== Memcheck, a memory error detector
==3211== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==3211== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==3211== Command: /home/robert/worki0/src/i0coind
==3211==
==3211== Thread 11:
==3211== Conditional jump or move depends on uninitialised value(s)
==3211== at 0x57F9BD7: ??? (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FB3A1: __log_put (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FC61D: ??? (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FD48F: __log_put_record (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57B8ECA: __db_pitem (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x571ACAA: ??? (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x571C2F9: __bam_iitem (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x5717421: ??? (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57AEC68: __dbc_iput (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57AC86F: __db_put (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57BE5DA: __db_put_pp (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57007FA: Db::put(DbTxn*, Dbt*, Dbt*, unsigned int) (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211==
==3211== Syscall param pwrite64(buf) points to uninitialised byte(s)
==3211== at 0x60986C3: ??? (syscall-template.S:82)
==3211== by 0x5812A07: __os_io (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57F98D5: ??? (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FB9A2: __log_put (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FC61D: ??? (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FD48F: __log_put_record (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x581D79C: __txn_commit (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57BE471: __db_put_pp (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57007FA: Db::put(DbTxn*, Dbt*, Dbt*, unsigned int) (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x43D633: bool CDB::Write<std::string, CAddrMan>(std::string const&, CAddrMan const&, bool) (db.h:110)
==3211== by 0x42F640: CAddrDB::WriteAddrman(CAddrMan const&) (db.cpp:755)
==3211== by 0x48DE07: DumpAddresses() (net.cpp:1052)
==3211== Address 0x9cbde34 is not stack'd, malloc'd or (recently) free'd
==3211==
==3211== Thread 7:
==3211== Syscall param pwrite64(buf) points to uninitialised byte(s)
==3211== at 0x60986C3: ??? (syscall-template.S:82)
==3211== by 0x5812A07: __os_io (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FF773: ??? (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x57FFBB0: __memp_bhwrite (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x580F115: __memp_sync_int (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x581ECC3: __txn_checkpoint (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x581F040: __txn_checkpoint_pp (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x5703639: DbEnv::txn_checkpoint(unsigned int, unsigned int, unsigned int) (in /usr/lib/x86_64-linux-gnu/libdb_cxx-5.1.so)
==3211== by 0x42D84E: CDB::Close() (db.cpp:175)
==3211== by 0x45E904: SendMessages(CNode*, bool) (db.h:46)
==3211== by 0x48F80C: ThreadMessageHandler2(void*) (net.cpp:1383)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== Address 0x987d488 is not stack'd, malloc'd or (recently) free'd
==3211==
==3211== Conditional jump or move depends on uninitialised value(s)
==3211== at 0x46FFB3: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2821)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== Conditional jump or move depends on uninitialised value(s)
==3211== at 0x492E1E: CNode::Misbehaving(int) (net.cpp:445)
==3211== by 0x46FFBC: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2821)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== Conditional jump or move depends on uninitialised value(s)
==3211== at 0x6B024F1: vfprintf (vfprintf.c:1629)
==3211== by 0x6B061A3: buffered_vfprintf (vfprintf.c:2313)
==3211== by 0x6B00BDD: vfprintf (vfprintf.c:1316)
==3211== by 0x6BC13C7: __vfprintf_chk (vfprintf_chk.c:35)
==3211== by 0x4FDC30: OutputDebugStringF(char const*, ...) (stdio2.h:128)
==3211== by 0x492EE7: CNode::Misbehaving(int) (net.cpp:454)
==3211== by 0x46FFBC: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2821)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== Use of uninitialised value of size 8
==3211== at 0x6B007EB: _itoa_word (_itoa.c:195)
==3211== by 0x6B02837: vfprintf (vfprintf.c:1629)
==3211== by 0x6B061A3: buffered_vfprintf (vfprintf.c:2313)
==3211== by 0x6B00BDD: vfprintf (vfprintf.c:1316)
==3211== by 0x6BC13C7: __vfprintf_chk (vfprintf_chk.c:35)
==3211== by 0x4FDC30: OutputDebugStringF(char const*, ...) (stdio2.h:128)
==3211== by 0x492EE7: CNode::Misbehaving(int) (net.cpp:454)
==3211== by 0x46FFBC: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2821)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211==
==3211== Conditional jump or move depends on uninitialised value(s)
==3211== at 0x6B007F5: _itoa_word (_itoa.c:195)
==3211== by 0x6B02837: vfprintf (vfprintf.c:1629)
==3211== by 0x6B061A3: buffered_vfprintf (vfprintf.c:2313)
==3211== by 0x6B00BDD: vfprintf (vfprintf.c:1316)
==3211== by 0x6BC13C7: __vfprintf_chk (vfprintf_chk.c:35)
==3211== by 0x4FDC30: OutputDebugStringF(char const*, ...) (stdio2.h:128)
==3211== by 0x492EE7: CNode::Misbehaving(int) (net.cpp:454)
==3211== by 0x46FFBC: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2821)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211==
==3211== Thread 3:
==3211== Invalid read of size 8
==3211== at 0x6B59E08: wcscmp (wcscmp.S:479)
==3211== by 0x6316113: std::moneypunct<wchar_t, false>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x6316198: std::moneypunct<wchar_t, false>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630AA79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630AC4C: std::locale::~locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x6AF3D1C: __cxa_finalize (cxa_finalize.c:56)
==3211== by 0x5040755: ??? (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x504E010: ??? (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x6AF3900: __run_exit_handlers (exit.c:78)
==3211== by 0x6AF3984: exit (exit.c:100)
==3211== by 0x4419B4: Shutdown(void*) (init.cpp:80)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== Address 0x7296258 is 0 bytes after a block of size 8 alloc'd
==3211== at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x6315DED: std::moneypunct<wchar_t, false>::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630D11E: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630D65E: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x504ADDA: boost::filesystem3::path::wchar_t_codecvt_facet() (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x504058E: ??? (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x400F305: call_init.part.0 (dl-init.c:85)
==3211== by 0x400F3DE: _dl_init (dl-init.c:52)
==3211== by 0x40016E9: ??? (in /lib/x86_64-linux-gnu/ld-2.15.so)
==3211==
==3211== Invalid read of size 8
==3211== at 0x6B59E08: wcscmp (wcscmp.S:479)
==3211== by 0x6316003: std::moneypunct<wchar_t, true>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x6316088: std::moneypunct<wchar_t, true>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630AA79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630AC4C: std::locale::~locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x6AF3D1C: __cxa_finalize (cxa_finalize.c:56)
==3211== by 0x5040755: ??? (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x504E010: ??? (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x6AF3900: __run_exit_handlers (exit.c:78)
==3211== by 0x6AF3984: exit (exit.c:100)
==3211== by 0x4419B4: Shutdown(void*) (init.cpp:80)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== Address 0x7296488 is 0 bytes after a block of size 8 alloc'd
==3211== at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x63157FD: std::moneypunct<wchar_t, true>::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630D16B: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x630D65E: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==3211== by 0x504ADDA: boost::filesystem3::path::wchar_t_codecvt_facet() (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x504058E: ??? (in /usr/lib/libboost_filesystem.so.1.46.1)
==3211== by 0x400F305: call_init.part.0 (dl-init.c:85)
==3211== by 0x400F3DE: _dl_init (dl-init.c:52)
==3211== by 0x40016E9: ??? (in /lib/x86_64-linux-gnu/ld-2.15.so)
==3211==
==3211==
==3211== HEAP SUMMARY:
==3211== in use at exit: 1,354,529,948 bytes in 21,104,474 blocks
==3211== total heap usage: 39,816,134 allocs, 18,711,660 frees, 4,412,257,962 bytes allocated
==3211==
Title: Re: i0coin UPDATES
Post by: dreamwatcher on December 12, 2012, 03:13:05 PM
Continued from previous post: ==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5E0146D: ERR_load_TS_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA84: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211==
==3211== 1,296 bytes in 54 blocks are still reachable in loss record 323 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA69: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 1,338 bytes in 1 blocks are indirectly lost in loss record 324 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x41D0F1: void std::vector<char, zero_after_free_allocator<char> >::_M_range_insert<char const*>(__gnu_cxx::__normal_iterator<char*, std::vector<char, zero_after_free_allocator<char> > >, char const*, char const*, std::forward_iterator_tag) (new_allocator.h:92)
==3211== by 0x48FC76: CNode::PushGetBlocks(CBlockIndex*, uint256) (stl_vector.h:1201)
==3211== by 0x46C1C3: ProcessBlock(CNode*, CBlock*) (main.cpp:1952)
==3211== by 0x46FFA5: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2819)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 1,368 bytes in 57 blocks are still reachable in loss record 325 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D7EECD: ERR_load_RSA_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA12: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211==
==3211== 1,416 bytes in 59 blocks are still reachable in loss record 326 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA12: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 1,512 bytes in 3 blocks are indirectly lost in loss record 327 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x496469: std::_Deque_base<CInv, std::allocator<CInv> >::_M_initialize_map(unsigned long) (new_allocator.h:92)
==3211== by 0x496A47: CNode::CNode(unsigned int, CAddress, bool) (stl_deque.h:452)
==3211== by 0x4921B6: ThreadSocketHandler2(void*) (net.cpp:666)
==3211== by 0x492549: ThreadSocketHandler(void*) (net.cpp:477)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 1,560 bytes in 65 blocks are still reachable in loss record 328 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA1C: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 1,560 bytes in 65 blocks are still reachable in loss record 329 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5DDF3DD: ERR_load_X509V3_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA6E: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211==
==3211== 1,632 bytes in 68 blocks are still reachable in loss record 330 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA6E: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 1,640 bytes in 1 blocks are still reachable in loss record 331 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4C7532: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::detail::strand_service>(boost::asio::io_service&) (service_registry.hpp:63)
==3211== by 0x4C4198: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (service_registry.ipp:99)
==3211== by 0x4C7011: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::ssl::detail::openssl_stream_service>(boost::asio::io_service&) (service_registry.hpp:30)
==3211== by 0x4C4198: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (service_registry.ipp:99)
==3211== by 0x4C439A: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::ssl::stream_service>(boost::asio::io_service&) (service_registry.hpp:30)
==3211== by 0x4C4198: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (service_registry.ipp:99)
==3211== by 0x4B512A: ThreadRPCServer2(void*) (service_registry.hpp:30)
==3211== by 0x4B83C9: ThreadRPCServer(void*) (bitcoinrpc.cpp:2799)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 1,640 bytes in 41 blocks are still reachable in loss record 332 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4D62B1: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:54)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 1,680 bytes in 70 blocks are still reachable in loss record 333 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5DFC75D: ERR_load_CMS_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA99: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211==
==3211== 1,696 bytes in 2 blocks are indirectly lost in loss record 334 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x492156: ThreadSocketHandler2(void*) (net.cpp:666)
==3211== by 0x492549: ThreadSocketHandler(void*) (net.cpp:477)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 1,824 bytes in 76 blocks are still reachable in loss record 335 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5DAA96D: ERR_load_EVP_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA1C: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211==
==3211== 1,968 bytes in 82 blocks are still reachable in loss record 336 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA99: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 2,597 (848 direct, 1,749 indirect) bytes in 1 blocks are definitely lost in loss record 337 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x492156: ThreadSocketHandler2(void*) (net.cpp:666)
==3211== by 0x492549: ThreadSocketHandler(void*) (net.cpp:477)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 2,832 bytes in 118 blocks are still reachable in loss record 338 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA3E: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 2,904 bytes in 121 blocks are still reachable in loss record 339 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5DC8A0D: ERR_load_ASN1_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA3E: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211==
==3211== 3,048 bytes in 127 blocks are still reachable in loss record 340 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA08: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 3,264 bytes in 136 blocks are still reachable in loss record 341 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D7230D: ERR_load_EC_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9FA54: ERR_load_crypto_strings (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5A9E1D8: SSL_load_error_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211==
==3211== 3,296 (1,696 direct, 1,600 indirect) bytes in 2 blocks are definitely lost in loss record 342 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x49289D: ConnectNode(CAddress, long long) (net.cpp:359)
==3211== by 0x492C1F: OpenNetworkConnection(CAddress const&, bool) (net.cpp:1307)
==3211== by 0x49404D: ThreadOpenConnections2(void*) (net.cpp:1207)
==3211== by 0x494719: ThreadOpenConnections(void*) (net.cpp:1087)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 4,096 bytes in 1 blocks are still reachable in loss record 343 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4D3E07: boost::iostreams::detail::indirect_streambuf<SSLIOStreamDevice, std::char_traits<char>, std::allocator<char>, boost::iostreams::bidirectional>::open(SSLIOStreamDevice const&, long, long) (new_allocator.h:92)
==3211== by 0x4B54CF: ThreadRPCServer2(void*) (stream_buffer.hpp:106)
==3211== by 0x4B83C9: ThreadRPCServer(void*) (bitcoinrpc.cpp:2799)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 4,100 bytes in 1 blocks are still reachable in loss record 344 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4D3DCC: boost::iostreams::detail::indirect_streambuf<SSLIOStreamDevice, std::char_traits<char>, std::allocator<char>, boost::iostreams::bidirectional>::open(SSLIOStreamDevice const&, long, long) (new_allocator.h:92)
==3211== by 0x4B54CF: ThreadRPCServer2(void*) (stream_buffer.hpp:106)
==3211== by 0x4B83C9: ThreadRPCServer(void*) (bitcoinrpc.cpp:2799)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 4,954 bytes in 196 blocks are indirectly lost in loss record 345 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4239E9: std::vector<unsigned char, std::allocator<unsigned char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned long, unsigned char const&) (new_allocator.h:92)
==3211== by 0x4862BD: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_construct.h:103)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x489198: void CBlock::Unserialize<CDataStream>(CDataStream&, int, int) (main.h:867)
==3211== by 0x46FED2: ProcessMessage(CNode*, std::string, CDataStream&) (serialize.h:353)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 5,184 bytes in 216 blocks are still reachable in loss record 346 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5AA901D: ERR_load_SSL_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 6,272 bytes in 1 blocks are indirectly lost in loss record 347 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x440D99: std::vector<CTxOut, std::allocator<CTxOut> >::_M_fill_insert(__gnu_cxx::__normal_iterator<CTxOut*, std::vector<CTxOut, std::allocator<CTxOut> > >, unsigned long, CTxOut const&) (new_allocator.h:92)
==3211== by 0x4862E2: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_vector.h:944)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x489198: void CBlock::Unserialize<CDataStream>(CDataStream&, int, int) (main.h:867)
==3211== by 0x46FED2: ProcessMessage(CNode*, std::string, CDataStream&) (serialize.h:353)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 7,176 bytes in 299 blocks are still reachable in loss record 348 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C24A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 8,192 bytes in 1 blocks are still reachable in loss record 349 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9A84F: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9A9A1: BIO_new_bio_pair (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x4B51FE: ThreadRPCServer2(void*) (openssl_stream_service.hpp:195)
==3211== by 0x4B83C9: ThreadRPCServer(void*) (bitcoinrpc.cpp:2799)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 8,192 bytes in 1 blocks are still reachable in loss record 350 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9A80F: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9A9A1: BIO_new_bio_pair (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x4B51FE: ThreadRPCServer2(void*) (openssl_stream_service.hpp:195)
==3211== by 0x4B83C9: ThreadRPCServer(void*) (bitcoinrpc.cpp:2799)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 9,958 bytes in 394 blocks are possibly lost in loss record 351 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4239E9: std::vector<unsigned char, std::allocator<unsigned char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned long, unsigned char const&) (new_allocator.h:92)
==3211== by 0x4862BD: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_construct.h:103)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 10,108 bytes in 400 blocks are indirectly lost in loss record 352 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4239E9: std::vector<unsigned char, std::allocator<unsigned char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned long, unsigned char const&) (new_allocator.h:92)
==3211== by 0x4862BD: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_construct.h:103)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 10,224 bytes in 1 blocks are possibly lost in loss record 353 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x484346: std::deque<CInv, std::allocator<CInv> >::_M_reallocate_map(unsigned long, bool) (new_allocator.h:92)
==3211== by 0x48450B: std::deque<CInv, std::allocator<CInv> >::_M_push_back_aux(CInv const&) (stl_deque.h:1888)
==3211== by 0x4846CE: CNode::AddInventoryKnown(CInv const&) (stl_deque.h:1371)
==3211== by 0x471788: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2583)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 11,738 bytes in 3 blocks are indirectly lost in loss record 354 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x477092: std::vector<char, zero_after_free_allocator<char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<char*, std::vector<char, zero_after_free_allocator<char> > >, unsigned long, char const&) (new_allocator.h:92)
==3211== by 0x491EB2: ThreadSocketHandler2(void*) (stl_vector.h:944)
==3211== by 0x492549: ThreadSocketHandler(void*) (net.cpp:477)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 12,437 (152 direct, 12,285 indirect) bytes in 1 blocks are definitely lost in loss record 355 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x46BC12: ProcessBlock(CNode*, CBlock*) (main.cpp:1946)
==3211== by 0x46FFA5: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2819)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 12,640 bytes in 2 blocks are possibly lost in loss record 356 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x440D99: std::vector<CTxOut, std::allocator<CTxOut> >::_M_fill_insert(__gnu_cxx::__normal_iterator<CTxOut*, std::vector<CTxOut, std::allocator<CTxOut> > >, unsigned long, CTxOut const&) (new_allocator.h:92)
==3211== by 0x4862E2: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_vector.h:944)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 12,800 bytes in 2 blocks are indirectly lost in loss record 357 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x440D99: std::vector<CTxOut, std::allocator<CTxOut> >::_M_fill_insert(__gnu_cxx::__normal_iterator<CTxOut*, std::vector<CTxOut, std::allocator<CTxOut> > >, unsigned long, CTxOut const&) (new_allocator.h:92)
==3211== by 0x4862E2: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_vector.h:944)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 16,384 bytes in 1 blocks are still reachable in loss record 358 of 380
==3211== at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21894: CRYPTO_realloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9C1F1: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E828: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D9E243: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5AA901D: ERR_load_SSL_strings (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==3211== by 0x4D622E: boost::asio::ssl::detail::openssl_init<true>::do_init::do_init() (openssl_init.hpp:49)
==3211== by 0x4D6522: boost::asio::ssl::detail::openssl_init<true>::do_init::instance() (openssl_init.hpp:82)
==3211== by 0x417F9A: _GLOBAL__sub_I__Z12JSONRPCErroriRKSs (openssl_init.hpp:121)
==3211== by 0x51E39C: __libc_csu_init (in /home/robert/worki0/src/i0coind)
==3211== by 0x6AD96FF: (below main) (libc-start.c:185)
==3211==
==3211== 16,672 bytes in 1 blocks are still reachable in loss record 359 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4B514D: ThreadRPCServer2(void*) (openssl_stream_service.hpp:189)
==3211== by 0x4B83C9: ThreadRPCServer(void*) (bitcoinrpc.cpp:2799)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 17,640 bytes in 35 blocks are possibly lost in loss record 360 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x484481: std::deque<CInv, std::allocator<CInv> >::_M_push_back_aux(CInv const&) (new_allocator.h:92)
==3211== by 0x45F41F: SendMessages(CNode*, bool) (stl_deque.h:1371)
==3211== by 0x48F80C: ThreadMessageHandler2(void*) (net.cpp:1383)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 17,647 (160 direct, 17,487 indirect) bytes in 2 blocks are definitely lost in loss record 361 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x479856: std::_Rb_tree<CAddress, CAddress, std::_Identity<CAddress>, std::less<CAddress>, std::allocator<CAddress> >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base const*, CAddress const&) (new_allocator.h:92)
==3211== by 0x4799E2: std::_Rb_tree<CAddress, CAddress, std::_Identity<CAddress>, std::less<CAddress>, std::allocator<CAddress> >::_M_insert_unique(CAddress const&) (stl_tree.h:1291)
==3211== by 0x45E38F: SendMessages(CNode*, bool) (stl_set.h:410)
==3211== by 0x48F80C: ThreadMessageHandler2(void*) (net.cpp:1383)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 18,432 bytes in 1 blocks are possibly lost in loss record 362 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x477726: std::vector<CInv, std::allocator<CInv> >::_M_insert_aux(__gnu_cxx::__normal_iterator<CInv*, std::vector<CInv, std::allocator<CInv> > >, CInv const&) (new_allocator.h:92)
==3211== by 0x477AD3: CNode::PushInventory(CInv const&) (stl_vector.h:834)
==3211== by 0x46EF6A: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2687)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 20,222 bytes in 1 blocks are possibly lost in loss record 363 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x41D0F1: void std::vector<char, zero_after_free_allocator<char> >::_M_range_insert<char const*>(__gnu_cxx::__normal_iterator<char*, std::vector<char, zero_after_free_allocator<char> > >, char const*, char const*, std::forward_iterator_tag) (new_allocator.h:92)
==3211== by 0x4800C8: void CNode::PushMessage<std::vector<CInv, std::allocator<CInv> > >(char const*, std::vector<CInv, std::allocator<CInv> > const&) (stl_vector.h:1201)
==3211== by 0x45E6A4: SendMessages(CNode*, bool) (main.cpp:3181)
==3211== by 0x48F80C: ThreadMessageHandler2(void*) (net.cpp:1383)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 25,972 (768 direct, 25,204 indirect) bytes in 6 blocks are definitely lost in loss record 364 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x42D634: InsertBlockIndex(uint256) (db.cpp:509)
==3211== by 0x43158D: CTxDB::LoadBlockIndex() (db.cpp:552)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 36,000 bytes in 500 blocks are possibly lost in loss record 365 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x47EBB6: std::_Rb_tree<CInv, CInv, std::_Identity<CInv>, std::less<CInv>, std::allocator<CInv> >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base const*, CInv const&) (new_allocator.h:92)
==3211== by 0x47ED42: std::_Rb_tree<CInv, CInv, std::_Identity<CInv>, std::less<CInv>, std::allocator<CInv> >::_M_insert_unique(CInv const&) (stl_tree.h:1291)
==3211== by 0x45F139: SendMessages(CNode*, bool) (stl_set.h:410)
==3211== by 0x48F80C: ThreadMessageHandler2(void*) (net.cpp:1383)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 103,600 bytes in 1 blocks are possibly lost in loss record 366 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x477092: std::vector<char, zero_after_free_allocator<char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<char*, std::vector<char, zero_after_free_allocator<char> > >, unsigned long, char const&) (new_allocator.h:92)
==3211== by 0x491EB2: ThreadSocketHandler2(void*) (stl_vector.h:944)
==3211== by 0x492549: ThreadSocketHandler(void*) (net.cpp:477)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 222,264 bytes in 441 blocks are possibly lost in loss record 367 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x484481: std::deque<CInv, std::allocator<CInv> >::_M_push_back_aux(CInv const&) (new_allocator.h:92)
==3211== by 0x4846CE: CNode::AddInventoryKnown(CInv const&) (stl_deque.h:1371)
==3211== by 0x471788: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2583)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 444,456 bytes in 6,173 blocks are possibly lost in loss record 368 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x47EBB6: std::_Rb_tree<CInv, CInv, std::_Identity<CInv>, std::less<CInv>, std::allocator<CInv> >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base const*, CInv const&) (new_allocator.h:92)
==3211== by 0x47ED42: std::_Rb_tree<CInv, CInv, std::_Identity<CInv>, std::less<CInv>, std::allocator<CInv> >::_M_insert_unique(CInv const&) (stl_tree.h:1291)
==3211== by 0x484573: CNode::AddInventoryKnown(CInv const&) (stl_set.h:410)
==3211== by 0x471788: ProcessMessage(CNode*, std::string, CDataStream&) (main.cpp:2583)
==3211== by 0x47215E: ProcessMessages(CNode*) (main.cpp:3017)
==3211== by 0x48F79F: ThreadMessageHandler2(void*) (net.cpp:1374)
==3211== by 0x48F999: ThreadMessageHandler(void*) (net.cpp:1337)
==3211== by 0x6090E99: start_thread (pthread_create.c:308)
==3211== by 0x6BABCBC: clone (clone.S:112)
==3211==
==3211== 4,312,528 bytes in 539,066 blocks are still reachable in loss record 369 of 380
==3211== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x5D21783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D5A5F6: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D5AB2C: bn_expand2 (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x5D5AC34: BN_copy (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3211== by 0x431C0A: CTxDB::LoadBlockIndex() (bignum.h:71)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 9,073,776 bytes in 378,074 blocks are still reachable in loss record 370 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x488EF1: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (shared_count.hpp:87)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 22,698,690 bytes in 378,074 blocks are still reachable in loss record 371 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4239E9: std::vector<unsigned char, std::allocator<unsigned char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned long, unsigned char const&) (new_allocator.h:92)
==3211== by 0x48601E: void Unserialize_impl<CDataStream, CTxIn, std::allocator<CTxIn> >(CDataStream&, std::vector<CTxIn, std::allocator<CTxIn> >&, int, int, boost::integral_constant<bool, false> const&) (stl_vector.h:944)
==3211== by 0x488F66: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 22,989,824 bytes in 179,608 blocks are still reachable in loss record 372 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x42D634: InsertBlockIndex(uint256) (db.cpp:509)
==3211== by 0x431604: CTxDB::LoadBlockIndex() (db.cpp:554)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 23,004,416 bytes in 179,722 blocks are still reachable in loss record 373 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x42D634: InsertBlockIndex(uint256) (db.cpp:509)
==3211== by 0x43158D: CTxDB::LoadBlockIndex() (db.cpp:552)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 23,006,208 bytes in 179,736 blocks are still reachable in loss record 374 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x42D634: InsertBlockIndex(uint256) (db.cpp:509)
==3211== by 0x4315C8: CTxDB::LoadBlockIndex() (db.cpp:553)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 27,221,328 bytes in 378,074 blocks are still reachable in loss record 375 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4405AC: std::vector<CTxIn, std::allocator<CTxIn> >::_M_fill_insert(__gnu_cxx::__normal_iterator<CTxIn*, std::vector<CTxIn, std::allocator<CTxIn> > >, unsigned long, CTxIn const&) (new_allocator.h:92)
==3211== by 0x486042: void Unserialize_impl<CDataStream, CTxIn, std::allocator<CTxIn> >(CDataStream&, std::vector<CTxIn, std::allocator<CTxIn> >&, int, int, boost::integral_constant<bool, false> const&) (stl_vector.h:944)
==3211== by 0x488F66: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 33,779,008 bytes in 377,657 blocks are still reachable in loss record 376 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x44C800: std::vector<uint256, std::allocator<uint256> >::_M_fill_insert(__gnu_cxx::__normal_iterator<uint256*, std::vector<uint256, std::allocator<uint256> > >, unsigned long, uint256 const&) (new_allocator.h:92)
==3211== by 0x467B9F: _Z12SerReadWriteI11CDataStreamSt6vectorI7uint256SaIS2_EEEjRT_RT0_ii21CSerActionUnserialize.isra.2284 (stl_vector.h:944)
==3211== by 0x488FCC: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (auxpow.h:27)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 69,149,408 bytes in 373,536 blocks are still reachable in loss record 377 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x44C800: std::vector<uint256, std::allocator<uint256> >::_M_fill_insert(__gnu_cxx::__normal_iterator<uint256*, std::vector<uint256, std::allocator<uint256> > >, unsigned long, uint256 const&) (new_allocator.h:92)
==3211== by 0x467B9F: _Z12SerReadWriteI11CDataStreamSt6vectorI7uint256SaIS2_EEEjRT_RT0_ii21CSerActionUnserialize.isra.2284 (stl_vector.h:944)
==3211== by 0x488FAA: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (main.h:729)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 117,959,088 bytes in 378,074 blocks are still reachable in loss record 378 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x488D45: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (auxpow.h:72)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 444,275,994 bytes in 17,373,654 blocks are still reachable in loss record 379 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x4239E9: std::vector<unsigned char, std::allocator<unsigned char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned long, unsigned char const&) (new_allocator.h:92)
==3211== by 0x4862BD: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_construct.h:103)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
==3211==
==3211== 555,956,896 bytes in 378,074 blocks are still reachable in loss record 380 of 380
==3211== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3211== by 0x440D99: std::vector<CTxOut, std::allocator<CTxOut> >::_M_fill_insert(__gnu_cxx::__normal_iterator<CTxOut*, std::vector<CTxOut, std::allocator<CTxOut> > >, unsigned long, CTxOut const&) (new_allocator.h:92)
==3211== by 0x4862E2: void Unserialize_impl<CDataStream, CTxOut, std::allocator<CTxOut> >(CDataStream&, std::vector<CTxOut, std::allocator<CTxOut> >&, int, int, boost::integral_constant<bool, false> const&) (stl_vector.h:944)
==3211== by 0x488F7C: int ReadWriteAuxPow<CDataStream>(CDataStream&, boost::shared_ptr<CAuxPow>&, int, int, CSerActionUnserialize) (serialize.h:473)
==3211== by 0x431540: CTxDB::LoadBlockIndex() (main.h:1242)
==3211== by 0x46A443: LoadBlockIndex(bool) (main.cpp:2065)
==3211== by 0x4441CB: AppInit2(int, char**) (init.cpp:371)
==3211== by 0x447D88: AppInit(int, char**) (init.cpp:124)
==3211== by 0x4154B8: main (init.cpp:110)
Title: Re: i0coin UPDATES
Post by: dreamwatcher on December 12, 2012, 03:17:22 PM
and finally: ==3211== LEAK SUMMARY:
==3211== definitely lost: 3,624 bytes in 12 blocks
==3211== indirectly lost: 58,325 bytes in 674 blocks
==3211== possibly lost: 899,480 bytes in 7,569 blocks
==3211== still reachable: 1,353,568,519 bytes in 21,096,219 blocks
==3211== suppressed: 0 bytes in 0 blocks
==3211==
==3211== For counts of detected and suppressed errors, rerun with: -v
==3211== Use --track-origins=yes to see where uninitialised values come from
==3211== ERROR SUMMARY: 83 errors from 40 contexts (suppressed: 2 from 2)
Anyway, any input would be appreciated. :)
Title: Re: i0coin UPDATES
Post by: dreamwatcher on December 19, 2012, 07:35:34 PM
Just to let you know I am still working on it. A thought: Bitcoin 0.6.3 synced and idle takes about 200 MB. (8 GB x 2.5% ~ 200 MB) bitcoind takes about 1.3% and Bitcoin-QT about 2.5% Mem: 7920304k total, 1429880k used, 6490424k free, 59452k buffers
Swap: 8123388k total, 0k used, 8123388k free, 736056k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2446 robert 20 0 710m 101m 43m S 1 1.3 0:21.86 bitcoind I0coin (32509 or based on Bitcoin 0.6.3) takes about 1.8 GB. The HEAP really builds up during the load of the blkindex. (i0coin and Bitcoin blkindex files are almost the same size. 1.4 GB and 1.3 GB) It seems the the merged mining is the only difference. IF I take 1.8 GB and subtract the footprint of Bitcoin 0.6.3 without merged mining I end up at ~ 1.6 GB. Merged mining started in I0coin at block 160000. / Start accepting AUX POW at this block
//
// Even if we do not accept AUX POW ourselves, we can always be the parent chain.
int GetAuxPowStartBlock()
{
if (fTestNet)
return 0; // Always on testnet
else
return 160000; // Never on prodnet Coincidence or is there something causing the client to to force load everything about the first 160000 blocks into the heap instead of the (?2000?) blocks that Bitcoin does? This is part of the code that creates the block index object from the blkindex file in I0coin. It is almost exactly the same except for auxpow. try {
string strType;
ssKey >> strType;
if (strType == "blockindex" && !fRequestShutdown)
{
CDiskBlockIndex diskindex;
ssValue >> diskindex;
// Construct block index object
CBlockIndex* pindexNew = InsertBlockIndex(diskindex.GetBlockHash());
pindexNew->pprev = InsertBlockIndex(diskindex.hashPrev);
pindexNew->pnext = InsertBlockIndex(diskindex.hashNext);
pindexNew->nFile = diskindex.nFile;
pindexNew->nBlockPos = diskindex.nBlockPos;
pindexNew->nHeight = diskindex.nHeight;
pindexNew->nVersion = diskindex.nVersion;
pindexNew->hashMerkleRoot = diskindex.hashMerkleRoot;
pindexNew->nTime = diskindex.nTime;
pindexNew->nBits = diskindex.nBits;
pindexNew->nNonce = diskindex.nNonce;
pindexNew->auxpow = diskindex.auxpow;
// Watch for genesis block
if (pindexGenesisBlock == NULL && diskindex.GetBlockHash() == hashGenesisBlock)
pindexGenesisBlock = pindexNew;
if (!pindexNew->CheckIndex())
return error("LoadBlockIndex() : CheckIndex failed at %d", pindexNew->nHeight);
}
else
{
break; // if shutdown requested or finished loading block index
}
} // try
catch (std::exception &e) {
return error("%s() : deserialize error", __PRETTY_FUNCTION__);
}
}
pcursor->close();
Notice pindexNew->auxpow = diskindex.auxpow; . So the auxpow is being read into the block index object for every block, is there an issue with the first 160000 blocks that were not part of merged mining and therefor have nothing to do with auxpow? It seems I have stumbled upon a puzzle, that to me seems like it should be easy to solve, yet the solution eludes me. I do not see any reason to keep more than 2000-2500 worth of blocks and tx's cached in memory. If the first goal is to get Vicruex to put I0coin back on the exchange, would not removing the merged mining accomplish the goal? I would not think Vicruex would care about merged mining, but only about the memory consumption being solved. Afterwords, work on a sane memory solution to the merged mining? Anyway, any input from programmers, especially those much more experienced than myself, are welcome.
Title: Re: i0coin UPDATES
Post by: markm on December 19, 2012, 09:16:11 PM
Is the version of bitcoin that i0coin is based on the most recent version that any merged mined chain is based on?
If not maybe it would make sense to take whichever merged mined chain used the most recent bitcoin version and make an i0coin based on that?
Or maybe just go ahead and apply the merged mining patch to the latest stable version of bitcoin or even just the most recent version of bitcoin, and make all the various altcoins up to date based on that?
Maybe if i0coin is the most up to date version of bitcoin that any merged mined coin has been built from the problem i0coin has is just waiting to hit all the other coins whenever they try to get more up to date with bitcoin? Maybe there is a gotcha waiting for all of them, maybe the merged mining patch isn't so simple to apply to recent bitcoins and all the coins are going to have to adapt in whatever way i0coin is going to have to?
-MarkM-
Title: Re: i0coin UPDATES
Post by: doublec on December 19, 2012, 09:33:52 PM
Bitcoin 0.6.3 synced and idle takes about 200 MB. (8 GB x 2.5% ~ 200 MB) bitcoind takes about 1.3% and Bitcoin-QT about 2.5%
Leave it running for a while. It takes over 1GB on my servers.
Title: Re: i0coin UPDATES
Post by: rav3n_pl on December 19, 2012, 11:34:10 PM
i0coind getinfo
{
"version" : 32509,
18889 rav3n 20 0 2498M 1741M 5308 S 0.0 44.0 10:12.47 +¦ i0coind
Memory eater... 40% res from 4G server
Latest bitcoind eats 170M ~4.5%...
Title: Re: i0coin UPDATES
Post by: dreamwatcher on December 20, 2012, 12:06:57 AM
Bitcoin 0.6.3 synced and idle takes about 200 MB. (8 GB x 2.5% ~ 200 MB) bitcoind takes about 1.3% and Bitcoin-QT about 2.5%
Leave it running for a while. It takes over 1GB on my servers. Ahh yes, I am aware of that issue. With the Cryptocoin Explorer site running full node, I was having that problem with PPC and to a lesser extent TRC. I solved that problem by not running with the default max connections for full node.(I believe it is hard coded at 125 connections) I use the config file option maxconnections=8 and it slows the memory creep down to glacier speed. rav3n, you are probably not having the Bitcoin client memory creep issue because you are not running full node ( with port 8333 open in your firewalls and routers or UPNP active on both client and network/router) therefore are automatically limited to 8 connections. If you are running full node and able to keep that memory footprint with the default max connections, please do tell us how. I would like to be able to run the daemons on Cryptocoin explorer full node with no restrictions. ;D I wish the i0coin problem was that simple. Unfortunately the heap allocation is happening during start up while the blkindex is loading, so the heap is up to 1.8 GB even before the client begins to fully function.
Title: Re: i0coin UPDATES
Post by: rav3n_pl on December 20, 2012, 12:45:25 AM
bitcoind getinfo "version" : 79900, "protocolversion" : 60002, "connections" : 24, /bitcoin$ git show commit 6940626d08e313c5e1cd99c63aeca9da45d5b7a4 Merge: da8c5c9 f0bf5fb Author: Gavin Andresen <gavinandresen@gmail.com> Date: Tue Dec 18 09:53:30 2012 -0800 file bitcoind bitcoind: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x433a84c7c32c1a709aa57b5f4db63305ae532bee, stripped in makefile.unix: use_upnp= use_ipv6=0 xCXXFLAGS=-O3 -mtune=generic -march=native cat bitcoin.conf server=1 daemon=1 maxconnections=25 paytxfee=0.00001 mintxfee=0.00001 htop 1 [||||||||||||||||||||| 35.5%] Tasks: 40; 2 running
2 [|||||||||||||||| 26.2%] Load average: 0.33 0.38 0.38
Mem[|||||||||||||||||||||||||||||||||||||||||||3138/3954MB] Uptime: 6 days, 14:28:14
Swp[||||||||| 311/2043MB]
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
1 root 20 0 24328 564 428 S 0.0 0.0 0:01.49 /sbin/init
25653 rav3n 20 0 24800 724 596 S 0.0 0.0 0:16.62 ├─ SCREEN -U -d -m python /home/rav3n/p2pool/run_p2pool.py -f 0.5
25654 rav3n 20 0 396M 188M 3216 S 25.0 4.8 1h21:37 │ └─ python /home/rav3n/p2pool/run_p2pool.py -f 0.5 --irc-announc
25378 rav3n 20 0 1211M 113M 3436 S 21.0 2.9 45:48.63 ├─ litecoind
20701 rav3n 20 0 1370M 180M 29380 S 1.0 4.6 10:33.98 ├─ bitcoind -daemon
18895 rav3n 20 0 24800 988 548 S 0.0 0.0 0:03.39 ├─ SCREEN -U -d -m python /home/rav3n/p2pool/run_p2pool.py --merge
18896 rav3n 20 0 594M 318M 3112 S 4.0 8.0 43:36.57 │ └─ python /home/rav3n/p2pool/run_p2pool.py --merged http://rav3
18891 rav3n 20 0 787M 217M 4180 S 1.0 5.5 4:55.16 ├─ ixcoind
18889 rav3n 20 0 2498M 1747M 5352 S 0.0 44.2 11:22.34 ├─ i0coind
10241 rav3n 20 0 665M 84240 3992 S 0.0 2.1 1h00:55 ├─ namecoind -daemon
8748 rav3n 20 0 24800 988 604 S 0.0 0.0 0:24.62 ├─ SCREEN -U -d -m python /home/rav3n/p2pool/run_p2pool.py -f 0.5
8749 rav3n 20 0 365M 89504 3064 R 4.0 2.2 1h18:05 │ └─ python /home/rav3n/p2pool/run_p2pool.py -f 0.5 --irc-announc
4272 rav3n 20 0 1136M 39696 4244 S 0.0 1.0 16:34.87 ├─ terracoind -daemon
Title: Re: i0coin UPDATES
Post by: Sunny King on December 20, 2012, 03:39:04 AM
Bitcoin 0.6.3 synced and idle takes about 200 MB. (8 GB x 2.5% ~ 200 MB) bitcoind takes about 1.3% and Bitcoin-QT about 2.5%
Leave it running for a while. It takes over 1GB on my servers. Ahh yes, I am aware of that issue. With the Cryptocoin Explorer site running full node, I was having that problem with PPC and to a lesser extent TRC. I solved that problem by not running with the default max connections for full node.(I believe it is hard coded at 125 connections) I use the config file option maxconnections=8 and it slows the memory creep down to glacier speed. rav3n, you are probably not having the Bitcoin client memory creep issue because you are not running full node ( with port 8333 open in your firewalls and routers or UPNP active on both client and network/router) therefore are automatically limited to 8 connections. If you are running full node and able to keep that memory footprint with the default max connections, please do tell us how. I would like to be able to run the daemons on Cryptocoin explorer full node with no restrictions. ;D I wish the i0coin problem was that simple. Unfortunately the heap allocation is happening during start up while the blkindex is loading, so the heap is up to 1.8 GB even before the client begins to fully function. So the memory leak related to maxconnections applies to bitcoind as well? Although I haven't observed it on the seed nodes of ppcoin, which on average has about over 30 connections (I didn't set maxconnections so it's using default max of 125).
Title: Re: i0coin UPDATES
Post by: markm on March 13, 2013, 09:29:05 AM
I merged-mine lots of chains, all using the same merged-mining patch I think, though I am not sure if i0coin also uses the same patch. (I think it does though.)
Could it be that i0coin tries to validate blocks even before reaching the most-recent checkpoint?
I don't know if older versions of bitcoin did not skip over all the blocks up to the last checkpoint, only checking that the block-hashes of the checkpointed blocks matched its list, and only doing real validation of blocks more recent than the most-recent checkpoint.
Another weird thing about i0coin is it dies from failure to do a DNS lookup, I think it tries to look up a timeserver for some reason, and uses DNS instead of IP address to do so, and thus dies when my connection is congested or flakes out or whatever, causing DNS to fail. No other coin (and I have run a lot of types of coin) has ever done that as far as I recall.
-MarkM-
Title: Re: i0coin UPDATES
Post by: CYPER on March 13, 2013, 05:44:19 PM
Is i0coin completely dead? Can you trade it anywhere? I'm trying to update it and after it downloaded around 6.67GB of blockchain (around 500K blocks so far) it just crashes everytime with the following error: https://i.imgur.com/xyLoOBo.pnghttps://i.imgur.com/Ian6xOv.pngAlso it uses way too much RAM: 1.9GB which is weird. Also how many blocks are there? I updated IXCoin and it only has around 121K blocks, but i0coin has more, but how many exactly?
Title: Re: i0coin UPDATES
Post by: tiker on March 14, 2013, 05:16:14 PM
Sounds like the same problem I had with GeistGeld. The 32-bit version on Windows crashed once the memory consumption reached 2gig. I haven't run my i0coin client recently but I will check it tonight.
Title: Re: i0coin UPDATES
Post by: CYPER on March 14, 2013, 08:09:40 PM
Sounds like the same problem I had with GeistGeld. The 32-bit version on Windows crashed once the memory consumption reached 2gig. I haven't run my i0coin client recently but I will check it tonight.
My Windows is 64bit and I got 6GB of RAM. Anyway my main question was if i0coin is completely dead in terms of trading?
Title: Re: i0coin UPDATES
Post by: markm on March 15, 2013, 12:17:33 AM
Anyway my main question was if i0coin is completely dead in terms of trading?
http://galaxies.mygamesonline.org/digitalisassets.html https://bitcointalk.org/index.php?topic=53329.0 In short, no, but, currently it seems one needs Open Transactions in order to access the markets. At some point it should become possible to make a Ripple gateway for it, so that it can be traded on Ripple in the same gateway-enabled way that bitcoins can be, but apparently the sample gateway source code the Ripple team provided is not intended for production use and so far the gateways that are in production have not seen fit, as far as I am aware, to realease the production-grade software they are using. (If they actually even are; one can hope, but absent their source code who knows...) -MarkM-
Title: Re: i0coin UPDATES
Post by: lightlord on April 05, 2013, 04:52:18 PM
Bumping this month old thread because I got a reply from someone that wants to offer a bounty.
Seems more interest is pouring into i0coin. Perhaps its a non-premined currency.
More worthy over ixcoin, as ixcoin is premined.
It should be i0coins that are worth more then ixcoin.
Lets get this problem fixed. Even though its been hogging around for a year.
It can be brought back up, its possible. As people we can make a community
based currency, made from many different ones. Anyone can contribute.
Title: Re: i0coin UPDATES
Post by: MaGNeT on April 05, 2013, 10:15:18 PM
Tried the client but it crashes at 2GB...
I'm not a programmer... Too bad...
Could someone give it a try? :)
Title: Re: i0coin UPDATES
Post by: dreamwatcher on April 05, 2013, 10:29:26 PM
I0coin is still on the list of projects, it has just fallen down a "few" rungs.
If somebody does not fix it before I can get to it, I promise to take another look at it.
Offering a bounty may encourage somebody to take up the cause, especially with the value of alt-coins sky rocketing now, and get the client patched before I can get to it again. ;D
Title: Re: i0coin UPDATES
Post by: Jambi on April 07, 2013, 05:56:11 PM
I0coin is still on the list of projects, it has just fallen down a "few" rungs.
If somebody does not fix it before I can get to it, I promise to take another look at it.
I the mean time, if someone could post a 64 bit executable for i0coin v0.3.25.9 it would allow more miners to keep it alive! I had to stop mining once the 32 bit version died.
Title: Re: i0coin UPDATES
Post by: MaGNeT on April 07, 2013, 07:33:40 PM
I0coin is still on the list of projects, it has just fallen down a "few" rungs.
If somebody does not fix it before I can get to it, I promise to take another look at it.
I the mean time, if someone could post a 64 bit executable for i0coin v0.3.25.9 it would allow more miners to keep it alive! I had to stop mining once the 32 bit version died. That would be great :)
Title: Re: i0coin UPDATES
Post by: rav3n_pl on April 07, 2013, 09:12:08 PM
1st that memory issue should be fixed. It is NOT possible that ANY daemon eat so much RAM.
64bit exe will not fix it.
Title: Re: i0coin UPDATES
Post by: twobits on May 01, 2013, 11:05:27 PM
I may take a stab at this, but then the conditions on the bounty seem to make it far less interesting. I would have no control on if Vircurex reenables its support of the chain. So the bounties would have to be changes to just being for the technical end that I can control.
Title: Re: i0coin UPDATES
Post by: doublec on May 01, 2013, 11:45:47 PM
I may take a stab at this, but then the conditions on the bounty seem to make it far less interesting. I would have no control on if Vircurex reenables its support of the chain. So the bounties would have to be changes to just being for the technical end that I can control.
If you can resolve the memory issues I'd be willing to add it to the merge mining pool. I agree conditions involving third parties make the bounty less attractive.
Title: Re: i0coin UPDATES
Post by: markm on May 02, 2013, 01:29:08 PM
I0Coind right now is eating 4.9 gig and GeistGeld typically eats about four gig.
What kills I0Coind though is boost craps out trying to do a DNS lookup.
It is the only coin I have that problem with, I have no idea why it even does DNS lookups once it is up and running, but it dies every day or two or less from this and has to be restarted.
We need a github repo where a recent copy of bitcoin with the merged mining patches, and ONLY the merged mining patches, applied.
Once that is in place, all the merged mined coins can be updated at leisure.
Without that, each time any one of the coins gets updated the whole work of getting the merged mining patches to apply to a new version of bitcoin ends up having to be duplicated for each coin, which is just a total waste of developer-time.
-MarkM-
Title: Re: i0coin UPDATES
Post by: Hazard on June 03, 2013, 04:22:54 PM
I am currently in the process of reviving i0coin. To that end, I need beta testers for the new client. PM if you're interested (and have the i0coin blockchain already).
Also, merged mining support would not be available in the initial release, but the door is open for it to be added later.
Title: Re: i0coin UPDATES
Post by: markm on June 04, 2013, 08:23:45 AM
I am currently in the process of reviving i0coin. To that end, I need beta testers for the new client. PM if you're interested (and have the i0coin blockchain already).
Also, merged mining support would not be available in the initial release, but the door is open for it to be added later.
You need to use -testnet then so you don't screw up the real net. Even better would be to help get the merged mining patch to apply cleanly to current bitcoin, so a proper update all the way to recent code can be done. -MarkM-
Title: Re: i0coin UPDATES
Post by: Smoovious on June 04, 2013, 04:09:39 PM
I am currently in the process of reviving i0coin. To that end, I need beta testers for the new client. PM if you're interested (and have the i0coin blockchain already).
Also, merged mining support would not be available in the initial release, but the door is open for it to be added later.
You need to use -testnet then so you don't screw up the real net. Even better would be to help get the merged mining patch to apply cleanly to current bitcoin, so a proper update all the way to recent code can be done. -MarkM- Using -testnet wouldn't let us test against the current blockchain to make sure it is being reloaded properly with all of the past forks and changes to the chain being followed properly. It wouldn't screw up the real net unless there was more hashpower than the non-testing people have, and we're not hashing at this point, just trying to validate the current chain. Could really use a block explorer right now tho... anyone still have an i0c block explorer up? -- Smoov
Title: Re: i0coin UPDATES
Post by: dreamwatcher on June 04, 2013, 04:40:02 PM
I would be willing to put up a block explorer, when an i0coin daemon (testing or release) is given to me that uses a reasonable amount of memory.
The state of the client/daemon now would require too much VPS memory for me to put on CCE.
Title: Re: i0coin UPDATES
Post by: Smoovious on June 04, 2013, 05:52:09 PM
I would be willing to put up a block explorer, when an i0coin daemon (testing or release) is given to me that uses a reasonable amount of memory.
The state of the client/daemon now would require too much VPS memory for me to put on CCE.
Yeah, that's the thing... by that time, I wouldn't need one anymore. I'm trying to find out where a fork occurs in my blk0001.dat file. We're past one of the fork points which Hazard was able to find, since it happened at a specific block, but there is another fork (or a couple) before the merge-mining fork at 160000. I can currently follow the bad fork (since I didn't update at the time until after I found myself forked off, so still have the orphaned blocks in my chain) but can't backtrack to find where it happened. I had thought about taking the trimmed blk0001.dat file from the testing build, and re-importing it into the old daemon, to see how far it gets before it rejects my supposed-to-be-orphaned blocks, but it doesn't import well, and have had no success. (Hazard is handling the code, I'm just doing testing) -- Smoov
Title: Re: i0coin UPDATES
Post by: steelhouse on June 06, 2013, 03:00:37 AM
I have an old blk0001.dat from 10-3-2012. doublec might have later blk and latest client.
http://i0coin.bitparking.com/
Title: Re: i0coin UPDATES
Post by: doublec on June 06, 2013, 03:24:42 AM
I can currently follow the bad fork (since I didn't update at the time until after I found myself forked off, so still have the orphaned blocks in my chain) but can't backtrack to find where it happened.
The forks I know of were at 14640, 150,000 and 160,000.
Title: Re: i0coin UPDATES
Post by: rsnel on September 15, 2013, 07:30:58 AM
Hello all, Since I'm behind the current I0coin resurrection, I'd like to claim all applicable bounties. Here is a list of things I did to get the coin healthy again: - analyze the problem (https://bitcointalk.org/index.php?topic=224744.60)
- implement a clean fix (https://github.com/rsnel/i0coin/commit/95a3d586994dba1d6a7e00694d355912b1863d04) for the issue
- provide windows binaries (on the new I0coin homepage (http://i0coin.snel.it/) / rebranded the QT client using Lightlord's logos)
- provide DNSseed (https://github.com/rsnel/i0coin/tree/i0coin-0.8.x/contrib/phpdnsseed), since irc seed support is removed from bitcoin
- initiated a hardfork (https://bitcointalk.org/index.php?topic=276483.0), to fix a current hardfork-requiring issues, making the coin future proof
- informed Vircurex of my progress, in an attempt to get the coin re-enabled, which they have done (https://bitcointalk.org/index.php?topic=294490)
I'd like to thank: - markm for joining the discussion at an early stage and keeping the coin alive (by running the only connectible node, AFAIK)
- doublec, the previous i0coin maintainer, for supporting me as new maintainer and including the coin in his pool (http://mmpool.bitparking.com/pool/).
- all miners that are sending more than 20 TH/s to the coin
- all other people that have contributed in some way to the success of this resurrection
Scanning though this thread, I find the following offerings (my list differs from the list in the first post; please correct me if I have misinterpreted something): Lightlord: I0C 20000 (https://bitcointalk.org/index.php?topic=124316.msg1335982#msg1335982) (paid!) pyra-proxy: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336117#msg1336117), I0C 5000 (vircurex bonus), I0C 10000 (merged mining) (https://bitcointalk.org/index.php?topic=124316.msg1338397#msg1338397) (101% paid!) steelhouse: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336251#msg1336251) (110% paid!) paladin_avatar16: I0C 20000 (merged mining), I0C 10000 (vircurex) (https://bitcointalk.org/index.php?topic=124316.msg1339121#msg1339121) (166 2/3% paid!) ayayay: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1335982#msg1335982) (can't find a real source, this is just a quote) (paid! (in IXC)) If you think I am eligible to receive a bounty you posted, please transfer the appropriate amount of coin to jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE and post the transaction ID below, so I can mark the amount as paid. Greetings, Rik.
Title: Re: i0coin UPDATES
Post by: pyra-proxy on September 16, 2013, 01:37:41 PM
pyra-proxy: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336117#msg1336117), I0C 5000 (vircurex bonus), I0C 10000 (merged mining) (https://bitcointalk.org/index.php?topic=124316.msg1338397#msg1338397) (open)
First part of mine to deliver to you is from 050d408b4b6d5536f410c796dfc946b9faf26e7fd5b9668317225ba2591af0d9 Unfortunately, In the intervening months since the disappearance of I0Coin I've lost a decent portion of my old balance to the aether so I'll get the remaining for you shortly. Thanks for the hard work! Apply this 10k to either the first 2 bounties or the last one, you're good on all of them I just need to reaquire the remaining balance due.
Title: Re: i0coin UPDATES
Post by: rsnel on September 16, 2013, 01:54:08 PM
pyra-proxy: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336117#msg1336117), I0C 5000 (vircurex bonus), I0C 10000 (merged mining) (https://bitcointalk.org/index.php?topic=124316.msg1338397#msg1338397) (open)
First part of mine to deliver to you is from 050d408b4b6d5536f410c796dfc946b9faf26e7fd5b9668317225ba2591af0d9 Unfortunately, In the intervening months since the disappearance of I0Coin I've lost a decent portion of my old balance to the aether so I'll get the remaining for you shortly. Thanks for the hard work! Apply this 10k to either the first 2 bounties or the last one, you're good on all of them I just need to reaquire the remaining balance due. Thanks! I'll wait patiently :)
Title: Re: i0coin UPDATES
Post by: markm on September 16, 2013, 01:55:53 PM
rsnel, do you have any hashing power of your own?
So as to be able to merged-mine while you fix up the merged mined coins?
I hope so, so that you can pick up lots of e.g. CoiLedCoin and GeistGeld while you work on them...
I hope you managed to pick up lots of I0Coin and GRouPcoin that way too before they got picked up by mmpool...
-MarkM-
Title: Re: i0coin UPDATES
Post by: rsnel on September 16, 2013, 04:42:44 PM
rsnel, do you have any hashing power of your own?
So as to be able to merged-mine while you fix up the merged mined coins?
I hope so, so that you can pick up lots of e.g. CoiLedCoin and GeistGeld while you work on them...
I hope you managed to pick up lots of I0Coin and GRouPcoin that way too before they got picked up by mmpool...
-MarkM-
I don't have significant SHA256 power available at the moment, but I have preordered a BFL single. I will point it P2Pool (while merged mining everything, unless it impedes my bitcoin yield, must test first), if my stale rate is acceptable (lower than or equal to the network's stale rate) I will keep it there, otherwise I will point it to doublec's pool. Didn't think about GRC, thought it was dead (I read somewhere that it was an abandoned precursor to devcoin). Now I installed it. I mined I0coin until March, couldn't get a stable connection to the network anymore and/or the client wouldn't start anymore. I'm glad you kept it alive, so I was able to fix it (I must have downloaded the blockchain about 5 times from you...). Found the coiledcoin thread. It's great that you keep the blockchains rolling... Will look into it.
Title: Re: i0coin UPDATES
Post by: lenny_ on September 16, 2013, 04:45:06 PM
Thanks for resurrecting this project. I just connected 150GH/s with my p2pool merged mining to support you. I am on good fork? "blocks" : 900857,
"difficulty" : 421974.57799850, Wish you luck with it! :)
Title: Re: i0coin UPDATES
Post by: rsnel on September 16, 2013, 04:51:50 PM
Thanks for resurrecting this project. I just connected 150GH/s with my p2pool merged mining to support you. I am on good fork? "blocks" : 900857,
"difficulty" : 421974.57799850, Wish you luck with it! :) Yes, it is the good fork. Thanks! :)
Title: Re: i0coin UPDATES
Post by: ahmed_bodi on September 16, 2013, 04:53:47 PM
hey why not we're all working on merged mining i'll point my BE toward it when i'm not mining on bytecoin testnet trying out the patch D
Title: Re: i0coin UPDATES
Post by: markm on September 16, 2013, 05:03:04 PM
Didn't think about GRC,
GRP, please. They are all coins, putting a C in the three-letter code is redundant. GRP obviously at a glance means GRouP, so it is much better code to use. Because of the limited time-window to pick up I0C, GRP, CLC and XGG by merged mining, I think block eruptor USBs were worth buying, as lookie now, already I0C and GRP have been picked up by bitparking so are now high difficulty; it was worth grabbing them before that happened. Same likely continues to apply to CLC and XGG. -MarkM-
Title: Re: i0coin UPDATES
Post by: rsnel on September 16, 2013, 05:38:14 PM
Didn't think about GRC,
GRP, please. They are all coins, putting a C in the three-letter code is redundant. GRP obviously at a glance means GRouP, so it is much better code to use. because of the limited time-window to pick up I0C, GRP, CLC and XGG by merged mining, I think block eruptor USBs were worth buying, as lookie now, already I0C and GRP have been picked up by bitparking so are now jigh difficulty; it was worth grabbing them before that happened. Same likely continues to apply to CLC and XGG. -MarkM- Noted; I have updated my system to say GRP. I am currently downloading CLC's blockchain. Thanks for the tip.
Title: Re: i0coin UPDATES
Post by: steelhouse on September 16, 2013, 11:08:57 PM
I sent 5500. 500 for being late.
Title: Re: i0coin UPDATES
Post by: doublec on September 17, 2013, 03:50:50 AM
I am currently downloading CLC's blockchain. Thanks for the tip.
Be careful about the blockchain you get. A while back I had numerous issues getting the right chain (https://bitcointalk.org/index.php?topic=56675.msg1945001#msg1945001) and my client refusing to reorg to the correct one.
Title: Re: i0coin UPDATES
Post by: rsnel on September 17, 2013, 03:54:36 AM
I sent 5500. 500 for being late.
Thanks! :)
Title: Re: i0coin UPDATES
Post by: rsnel on September 17, 2013, 03:57:44 AM
I am currently downloading CLC's blockchain. Thanks for the tip.
Be careful about the blockchain you get. A while back I had numerous issues getting the right chain (https://bitcointalk.org/index.php?topic=56675.msg1945001#msg1945001) and my client refusing to reorg to the correct one. If that's not a one-time fluke; there will be large problem... At the moment: block 294142, hash 46c6d42d2859bb4f91fcc835ea07d58da634e97b1eec841665c6eddbdb9c0247 Greetings, Rik.
Title: Re: i0coin UPDATES
Post by: Tomatocage on September 17, 2013, 05:04:49 AM
I sent 5500. 500 for being late.
Weren't you the one who was pushing to reduce the block reward to 1 i0C/block last year?
Title: Re: i0coin UPDATES
Post by: pyra-proxy on September 19, 2013, 01:46:19 AM
pyra-proxy: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336117#msg1336117), I0C 5000 (vircurex bonus), I0C 10000 (merged mining) (https://bitcointalk.org/index.php?topic=124316.msg1338397#msg1338397) (open)
First part of mine to deliver to you is from 050d408b4b6d5536f410c796dfc946b9faf26e7fd5b9668317225ba2591af0d9 Unfortunately, In the intervening months since the disappearance of I0Coin I've lost a decent portion of my old balance to the aether so I'll get the remaining for you shortly. Thanks for the hard work! Apply this 10k to either the first 2 bounties or the last one, you're good on all of them I just need to reaquire the remaining balance due. Remainder of bounty + bonus from sweeping account paid in 51885b9a0a2a13810f4a48a03d3aca4d45d97519ac9b7e41fbd324f42b9b3696 Thanks again for the hard work and effort you made on this coin! I hope you continue on shepherding this coin! :-)
Title: Re: i0coin UPDATES
Post by: rsnel on September 19, 2013, 04:01:20 AM
pyra-proxy: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336117#msg1336117), I0C 5000 (vircurex bonus), I0C 10000 (merged mining) (https://bitcointalk.org/index.php?topic=124316.msg1338397#msg1338397) (open)
First part of mine to deliver to you is from 050d408b4b6d5536f410c796dfc946b9faf26e7fd5b9668317225ba2591af0d9 Unfortunately, In the intervening months since the disappearance of I0Coin I've lost a decent portion of my old balance to the aether so I'll get the remaining for you shortly. Thanks for the hard work! Apply this 10k to either the first 2 bounties or the last one, you're good on all of them I just need to reaquire the remaining balance due. Remainder of bounty + bonus from sweeping account paid in 51885b9a0a2a13810f4a48a03d3aca4d45d97519ac9b7e41fbd324f42b9b3696 Thanks again for the hard work and effort you made on this coin! I hope you continue on shepherding this coin! :-) Thanks :). Since I0coin is just Bitcoin with different parameters, it shouldn't be too much work to maintain it. So I intend to do it.
Title: Re: i0coin UPDATES
Post by: paladin_avatar16 on September 20, 2013, 07:14:34 PM
Hello all, Since I'm behind the current I0coin resurrection, I'd like to claim all applicable bounties. Here is a list of things I did to get the coin healthy again: - analyze the problem (https://bitcointalk.org/index.php?topic=224744.60)
- implement a clean fix (https://github.com/rsnel/i0coin/commit/95a3d586994dba1d6a7e00694d355912b1863d04) for the issue
- provide windows binaries (on the new I0coin homepage (http://i0coin.snel.it/) / rebranded the QT client using Lightlord's logos)
- provide DNSseed (https://github.com/rsnel/i0coin/tree/i0coin-0.8.x/contrib/phpdnsseed), since irc seed support is removed from bitcoin
- initiated a hardfork (https://bitcointalk.org/index.php?topic=276483.0), to fix a current hardfork-requiring issues, making the coin future proof
- informed Vircurex of my progress, in an attempt to get the coin re-enabled, which they have done (https://bitcointalk.org/index.php?topic=294490)
I'd like to thank: - markm for joining the discussion at an early stage and keeping the coin alive (by running the only connectible node, AFAIK)
- doublec, the previous i0coin maintainer, for supporting me as new maintainer and including the coin in his pool (http://mmpool.bitparking.com/pool/).
- all miners that are sending more than 20 TH/s to the coin
- all other people that have contributed in some way to the success of this resurrection
Scanning though this thread, I find the following offerings (my list differs from the list in the first post; please correct me if I have misinterpreted something): Lightlord: I0C 20000 (https://bitcointalk.org/index.php?topic=124316.msg1335982#msg1335982) (paid!) pyra-proxy: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336117#msg1336117), I0C 5000 (vircurex bonus), I0C 10000 (merged mining) (https://bitcointalk.org/index.php?topic=124316.msg1338397#msg1338397) (101% paid!) steelhouse: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1336251#msg1336251) (110% paid!) paladin_avatar16: I0C 20000 (merged mining), I0C 10000 (vircurex) (https://bitcointalk.org/index.php?topic=124316.msg1339121#msg1339121) (open) ayayay: I0C 5000 (https://bitcointalk.org/index.php?topic=124316.msg1335982#msg1335982) (can't find a real source, this is just a quote) (open) If you think I am eligible to receive a bounty you posted, please transfer the appropriate amount of coin to jR8YJ3XL7PdsodCZCYocu7iDgBEi5gD5vE and post the transaction ID below, so I can mark the amount as paid. Greetings, Rik. Well, here I am - beeing out of the loop for a while ... And when I come back? I find i0coin fixed ... Well bounty 1 + 2 + a "little" extra is on the way (c831b5a2ba243b9e7b5f59a2990226e66be647b3abb7e62abfc2615fd30646a4-000) ... Hope you keep maintaining the coin ... THX
Title: Re: i0coin UPDATES
Post by: rsnel on September 20, 2013, 07:49:34 PM
Hi paladin_avatar16, Well, here I am - beeing out of the loop for a while ... And when I come back? I find i0coin fixed ...
Well bounty 1 + 2 + a "little" extra is on the way (c831b5a2ba243b9e7b5f59a2990226e66be647b3abb7e62abfc2615fd30646a4-000) ...
Hope you keep maintaining the coin ...
THX
Thanks, you're very generous! I intend to keep maintaining I0coin. Greetings, Rik.
Title: Re: i0coin UPDATES
Post by: com911 on September 21, 2013, 07:32:58 AM
Why is "-datadir" not working?
Can't change data directory for i0coin, it still downloading in "Application data", even after launching with -datadir=d:\AnotherDataFolder
Title: Re: i0coin UPDATES
Post by: CYPER on September 22, 2013, 11:47:48 PM
Why is "-datadir" not working?
Can't change data directory for i0coin, it still downloading in "Application data", even after launching with -datadir=d:\AnotherDataFolder
Works for me. Which version of the client are you using? D:\i0coin\i0coin-qt.exe -datadir=D:\i0coin\Blockchain
Title: Re: i0coin UPDATES
Post by: Aseras on October 10, 2013, 01:05:49 PM
Nice to see iocoin back. I had pretty much given it up for dead.
|
