Quote from: isaacgoldbourne on December 26, 2013, 04:29:06 pm

Quote from: reorder on December 26, 2013, 04:25:58 pm

Quote from: isaacgoldbourne on December 26, 2013, 04:05:27 pm

Quote from: lest on December 26, 2013, 04:01:33 pm

Currently there is one pool with almost 100% hashpower. It makes MemoryCoin very unsecure at the moment.

We definitely should do something with it.

The creator has sold the source code to "a few" people.

Personally I feel it should be opensourced.

Still got a few days until they create pools :S has the damage already been done?
I am asking how much it will cost to buy, but I imagine it is a ridiculous sum. I would have a pool up by this evening however.

Opesourced to community of greedy, selfish miners who don't mind to mine with every bit of cpu power they can get for free or steal? Hmm, what could possibly be wrong with this?

The fact that they are already doing this, but on a pool that can damage the network

Not this early. You do not want to 51% the coin you have income in, that would kill it right away.

On the contrary -- this is the perfect time to cement your own business and damage everyone else. You don't have to destroy the currency as such, you *are* supporting it, but are the only party who can mine as much as desired -- and you can let others mine, or not mine as you please.
Until, say difficulty rises and you lose interest.

It is *really* bad idea to release new crypto currencies without already designed mechanism to start pools -- with open source software. People will mine anyway -- making sure that only few will have the privilege to benefit from this is bad. Wasting lots of resources by building closed source "sort of works" pools is expensive for everyone.

Software compiled from source.  With

cd src
gmake -f makefile.unix

When run for the first time, it downloads the block chain, and "works". But restarting it always dumps core.
Deleting the block chain and leaving only the wallet -- works again, then after restart it is dumping core again.
Seems it is not liking it's on disk block chain.

If a strack trace helps:

(gdb) bt
#0  0x0000000800fb8779 in std::string::assign (this=<value optimized out>,
    __str=<value optimized out>) from /usr/local/lib/gcc46/libstdc++.so.6
#1  0x000000000047d952 in CBlockHeader::GetHash (this=0x7fffffffbf80)
    at error_code.hpp:499
#2  0x00000000005811fd in CBlockTreeDB::LoadBlockIndexGuts (
    this=<value optimized out>) at error_code.hpp:499
#3  0x000000000047c34a in LoadBlockIndexDB () at error_code.hpp:499
#4  0x000000000047cb2f in LoadBlockIndex () at error_code.hpp:499
#5  0x0000000801c62b18 in ?? ()
#6  0xdd6f08c5dbd62905 in ?? ()
#7  0x0000000804e59e80 in ?? ()
#8  0x000001432ba19a7c in ?? ()
#9  0x0000000000000048 in ?? () at error_code.hpp:184
#10 0x0000000800fcf1cd in operator new (sz=140737488341456)
    at ../../.././../gcc-4.6.4/libstdc++-v3/libsupc++/new_op.cc:52
#11 0x0000000000447aa1 in AppInit2 (threadGroup=@0x7fffffffd5e0)
    at error_code.hpp:499
#12 0x00007fffffffc400 in ?? ()
#13 0x0000000800aeab6b in r_debug_state () from /libexec/ld-elf.so.1
Previous frame inner to this frame (corrupt stack?)

tried few different compilers, same result. Also, why is it producing bitcoind excitable?