[ANN] MemoryCoin

[Sondey10mg]

stuck at block 2060 here

[torbank]

Running the latest code, I was getting a SEGFAULT on start up (whilst checking the Genesis block).

I had to revert PoWHash() to the original scrypt() call to get it to work. PoWHashScratchPad() seems to work fine with the new scryptscratchpad().

[torbank]

The good news is I am also seeing improved mining performance.

 

[FreeTrade]

All 3 my machines went down at block 2060 so it looks as if there are still some problems with grant-block processing.
As I mentioned before, once the problem is solved that you can load the blockchain while mining, this will prove the client is stable enough to run without crashing.

Okay, that sounds like stability issue 1 . . . it's weird that you'd be seeing problems on all your machines, when many others don't have any stability problem . . . I wonder what might be common to all three machines.

I'm assuming these aren't hard machine crashes, as you know which block you're going down on. It would be helpful to get the tail end of the debug.log file after a crash . . it will probably have crashed somewhere in the middle of the grant allocation code, and then there will be some superfluous network activity . . . just before the network activity is where the interesting stuff is.

[FreeTrade]

Some thoughts on next steps for MC -
http://21stcenturymoneytalk.org/index.php/topic,34.0.html

Interested in everyone's thoughts on next steps for the coin.

[FreeTrade]

Running the latest code, I was getting a SEGFAULT on start up (whilst checking the Genesis block).

I had to revert PoWHash() to the original scrypt() call to get it to work. PoWHashScratchPad() seems to work fine with the new scryptscratchpad().

Thanks for this - it was causing the 32 bit crash too. I'll take it out of the release and get a new version up soon.

[jestronix]

Some thoughts on next steps for MC -
http://21stcenturymoneytalk.org/index.php/topic,34.0.html

Interested in everyone's thoughts on next steps for the coin.

Definitely what needs to happen, one other fix would be the ability to kick off mining before its fully synced, but have the app wait rather then the user having to come back and kick it off.  A pool is a great idea and will get things moving along, a website is a must.

My wallets are stuck too, about 2 hours now since last block, usually get a few an hour. 

[SlyWax]

FreeTrade,
can you put a "win32 {" around all your "C:\" stuff in the beginning of file "bitcoin-qt.pro"
that would be nice.
you can put the "BOOST_LIB_SUFFIX=-mgw46-mt-sd-1_54" line inside too...

It miss some leveldb building too,
I have to build the daemon to make them available.
or remove the comment in front of :

Code:

    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a
and
    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a && $

Still it crash on Ubuntu 32bits

[torbank]

FreeTrade,
can you put a "win32 {" around all your "C:\" stuff in the beginning of file "bitcoin-qt.pro"
that would be nice.
you can put the "BOOST_LIB_SUFFIX=-mgw46-mt-sd-1_54" line inside too...

It miss some leveldb building too,
I have to build the daemon to make them available.
or remove the comment in front of :

Code:

    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a
and
    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a && $

+1

[FreeTrade]

FreeTrade,
can you put a "win32 {" around all your "C:\" stuff in the beginning of file "bitcoin-qt.pro"
that would be nice.
you can put the "BOOST_LIB_SUFFIX=-mgw46-mt-sd-1_54" line inside too...

Sure, can you send the updated file to me at memorycoincc@gmail.com - I'm still not too comfortable with git and github yet.

[FreeTrade]

Definitely what needs to happen, one other fix would be the ability to kick off mining before its fully synced, but have the app wait rather then the user having to come back and kick it off.

Agreed.

My wallets are stuck too, about 2 hours now since last block, usually get a few an hour. 

That's happening sometimes - check the block viewer to see if you're on the latest block, if not, a restart should nudge it to update.

[B.T.Coin]

All 3 my machines went down at block 2060 so it looks as if there are still some problems with grant-block processing.
As I mentioned before, once the problem is solved that you can load the blockchain while mining, this will prove the client is stable enough to run without crashing.

Okay, that sounds like stability issue 1 . . . it's weird that you'd be seeing problems on all your machines, when many others don't have any stability problem . . . I wonder what might be common to all three machines.

I'm assuming these aren't hard machine crashes, as you know which block you're going down on. It would be helpful to get the tail end of the debug.log file after a crash . . it will probably have crashed somewhere in the middle of the grant allocation code, and then there will be some superfluous network activity . . . just before the network activity is where the interesting stuff is.

You assume righ about it not being hard machine crashes. The program looks fine but the only way to tell it's not working is by opening the debug window and looking at the block number. My 6-core and 4-core both got stuck on a block again tonight.
When I close the program, I have to go into the windows task manager to kill the memorycoin.exe*32 process manually or I can't start the client again.
I will E-mail you the tail ends of the debug.log files but I don't think you will find anything interesting there. All I could see were some connection timeouts.
AFTER I killed the memorycoin process manually in the task manager, these lines were added to the debug.log on both machines:
net thread interrupt
dumpaddr thread stop
opencon thread interrupt
addcon thread interrupt

On my 2-core celeron machine the program crashed due to a runtime error. I will include that debug.log too.

[FreeTrade]

New release - fixes startup crash on some systems.

https://docs.google.com/file/d/0B-5Ax5kejTpMelRIUFp4Z2s5Q1E/edit?usp=sharing

[Stinky_Pete]

Updated yesterday evening to 'releaseAllocatedMemory'. Everything seems to be running as usual, but I've got no new blocks mined since then. Previously I've always had several overnight.

Just bad luck, or something more sinister? Latest info -

{
"blocks" : 2072,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00024218,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespersec" : 25.28735632,
"pooledtx" : 0,
"testnet" : false
}

[FreeTrade]

Just bad luck, or something more sinister? Latest info -

"difficulty" : 0.00024218,

I think the answer is in the question - difficulty going up because of the more efficient and stable releases.

[stas]

have updated both of my 32bit clients (win7 and vista)

both are now getting better hashpersec numbers than they were previously by 20%-30%
thank you:)

[auctioneeeeer]

New release - fixes startup crash on some systems.

https://docs.google.com/file/d/0B-5Ax5kejTpMelRIUFp4Z2s5Q1E/edit?usp=sharing

This is the release I've been waiting for.  I can now run all of my 10 core Ivy Bridge Xeons with genproclimit set to -1 and no crashes!      

(and it appears better performance too!)

[21stcenturymoney]

FreeTrade,
can you put a "win32 {" around all your "C:\" stuff in the beginning of file "bitcoin-qt.pro"
that would be nice.
you can put the "BOOST_LIB_SUFFIX=-mgw46-mt-sd-1_54" line inside too...

It miss some leveldb building too,
I have to build the daemon to make them available.
or remove the comment in front of :

Code:

    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a
and
    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a && $

Still it crash on Ubuntu 32bits

I still prefer the fix that changes it to fetch that information from environmental variables on all the platforms.  Our windows build environment needs different values and this does not let us easily override them.

https://bitbucket.org/mytwobits/memorycoin/commits/c5c6674e0be0acd8cfe6d21ebfd1b9b6d0ca2288

[albon]

I keep getting a runtime error

Happens 2-3 times a day and I have to restart the client

I am running on Win 7-64

[21stcenturymoney]

FreeTrade,
can you put a "win32 {" around all your "C:\" stuff in the beginning of file "bitcoin-qt.pro"
that would be nice.
you can put the "BOOST_LIB_SUFFIX=-mgw46-mt-sd-1_54" line inside too...

Sure, can you send the updated file to me at memorycoincc@gmail.com - I'm still not too comfortable with git and github yet.

You could try https://bitbucket.org/mytwobits/memorycoin/raw/cce51b91caf06d251af550eb6945fa8b68549752/bitcoin-qt.pro

Then you would either need to make bat file to set up those variables for your environment or code them in similar to the way the mac ones are later in the file.

This also fixes it so the mac ones can be overridden finally,and lets the environmental variable overrides work in all three build environments now instead of just linux.