Topic: [ANN] MemoryCoin - page 14. (Read 100341 times)

Well, there's a irony about cpu-only coins...and more so when it's designed to hit L2 memory.  The cpu is an 'all-purpose' chip, and yet, when the MemoryCoin client is run on a personal computer in a household, the computer becomes basically paralyzed.  Performance degrades a lot when constantly accessing L2 memory and cpu resource usage is at 100%.  So you want to promote this, but to who?  And for what?  To paralyze your personal computer and not allow you to do anything else?  No, unfortunately, cpu-only coins are botnet canon fodder until they are no longer profitable.  And so far, the price action of cpu-only coins depicts this to be the case.

While getting my graduate degree in Mathematics, the main thing that was constantly pounded into my head by professors was don't try to 'reinvent the wheel'.  In other words, just use the work of someone else who worked on the problem before me and try to add to it.  In the art world, Picasso says something similar, "Good artists copy.  Great artists steal." 

Every development project starts somewhere.  And in time, the successful projects add to their origins and evolve.

-Merc

today's value on BTER is ~16000 MEG
It's more than 10% of all current supply
So things are not that bad.
Once again, the priority would be the pool and a better exchange than making voting system better:)

@ FreeTrade:
I don't think that coin is dying. We do need a pool and a better exchange (criptsy)
The trading value of MEG is much better than many other coins, so is the price.
Considering the fact that not many people know/use BTER exchange, I would say the coin is doing OK. 

Stas

I'm trying to update but I get this error while starting up

Linux noob so please help


root@Memorycoin:~/memorycoinupdate/memorycoin/src# ./bitcoind --daemon
root@Memorycoin:~/memorycoinupdate/memorycoin/src# Bitcoin server starting
*** Error in `./bitcoind': munmap_chunk(): invalid pointer: 0x00000000024f169a ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7f576)[0x7f3249e63576]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSs6assignERKSs+0x86)[0x7f324a784666]
./bitcoind[0x47d639]
./bitcoind[0x5d5dbb]
./bitcoind[0x497822]
./bitcoind[0x4982c5]
./bitcoind[0x4540b8]
./bitcoind[0x4727f5]
./bitcoind[0x41ac11]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f3249e05ea5]
./bitcoind[0x41e8f1]
======= Memory map: ========
00400000-00772000 r-xp 00000000 fd:00 264725                             /root/memorycoinupdate/memorycoin/src/bitcoind
00971000-00973000 r--p 00371000 fd:00 264725                             /root/memorycoinupdate/memorycoin/src/bitcoind
00973000-00974000 rw-p 00373000 fd:00 264725                             /root/memorycoinupdate/memorycoin/src/bitcoind
00974000-00978000 rw-p 00000000 00:00 0
023f8000-02559000 rw-p 00000000 00:00 0                                  [heap]
7f3240000000-7f3240021000 rw-p 00000000 00:00 0
7f3240021000-7f3244000000 ---p 00000000 00:00 0
7f3244a3c000-7f3244cfd000 rw-p 00000000 00:00 0
7f3244cfd000-7f3244cfe000 ---p 00000000 00:00 0
7f3244cfe000-7f32454fe000 rw-p 00000000 00:00 0                          [stack:14061]
7f32454fe000-7f32457c7000 r--p 00000000 fd:00 921502                     /usr/lib/locale/locale-archive
7f32457c7000-7f32499c9000 rw-p 00000000 00:00 0
7f32499c9000-7f32499df000 r-xp 00000000 fd:00 1049547                    /lib/x86_64-linux-gnu/libz.so.1.2.7
7f32499df000-7f3249bde000 ---p 00016000 fd:00 1049547                    /lib/x86_64-linux-gnu/libz.so.1.2.7
7f3249bde000-7f3249bdf000 r--p 00015000 fd:00 1049547                    /lib/x86_64-linux-gnu/libz.so.1.2.7
7f3249bdf000-7f3249be0000 rw-p 00016000 fd:00 1049547                    /lib/x86_64-linux-gnu/libz.so.1.2.7
7f3249be0000-7f3249be3000 r-xp 00000000 fd:00 1049502                    /lib/x86_64-linux-gnu/libdl-2.17.so
7f3249be3000-7f3249de2000 ---p 00003000 fd:00 1049502                    /lib/x86_64-linux-gnu/libdl-2.17.so
7f3249de2000-7f3249de3000 r--p 00002000 fd:00 1049502                    /lib/x86_64-linux-gnu/libdl-2.17.so
7f3249de3000-7f3249de4000 rw-p 00003000 fd:00 1049502                    /lib/x86_64-linux-gnu/libdl-2.17.so
7f3249de4000-7f3249fa2000 r-xp 00000000 fd:00 1049550                    /lib/x86_64-linux-gnu/libc-2.17.so
7f3249fa2000-7f324a1a1000 ---p 001be000 fd:00 1049550                    /lib/x86_64-linux-gnu/libc-2.17.so
7f324a1a1000-7f324a1a5000 r--p 001bd000 fd:00 1049550                    /lib/x86_64-linux-gnu/libc-2.17.so
7f324a1a5000-7f324a1a7000 rw-p 001c1000 fd:00 1049550                    /lib/x86_64-linux-gnu/libc-2.17.so
7f324a1a7000-7f324a1ac000 rw-p 00000000 00:00 0
7f324a1ac000-7f324a1c0000 r-xp 00000000 fd:00 1049598                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f324a1c0000-7f324a3c0000 ---p 00014000 fd:00 1049598                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f324a3c0000-7f324a3c1000 r--p 00014000 fd:00 1049598                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f324a3c1000-7f324a3c2000 rw-p 00015000 fd:00 1049598                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f324a3c2000-7f324a4c5000 r-xp 00000000 fd:00 1049496                    /lib/x86_64-linux-gnu/libm-2.17.so
7f324a4c5000-7f324a6c5000 ---p 00103000 fd:00 1049496                    /lib/x86_64-linux-gnu/libm-2.17.so
7f324a6c5000-7f324a6c6000 r--p 00103000 fd:00 1049496                    /lib/x86_64-linux-gnu/libm-2.17.so
7f324a6c6000-7f324a6c7000 rw-p 00104000 fd:00 1049496                    /lib/x86_64-linux-gnu/libm-2.17.so
7f324a6c7000-7f324a7ac000 r-xp 00000000 fd:00 918072                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f324a7ac000-7f324a9ab000 ---p 000e5000 fd:00 918072                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f324a9ab000-7f324a9b3000 r--p 000e4000 fd:00 918072                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f324a9b3000-7f324a9b5000 rw-p 000ec000 fd:00 918072                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f324a9b5000-7f324a9ca000 rw-p 00000000 00:00 0
7f324a9ca000-7f324a9e2000 r-xp 00000000 fd:00 1049600                    /lib/x86_64-linux-gnu/libpthread-2.17.so
7f324a9e2000-7f324abe1000 ---p 00018000 fd:00 1049600                    /lib/x86_64-linux-gnu/libpthread-2.17.so
7f324abe1000-7f324abe2000 r--p 00017000 fd:00 1049600                    /lib/x86_64-linux-gnu/libpthread-2.17.so
7f324abe2000-7f324abe3000 rw-p 00018000 fd:00 1049600                    /lib/x86_64-linux-gnu/libpthread-2.17.so
7f324abe3000-7f324abe7000 rw-p 00000000 00:00 0
7f324abe7000-7f324ad98000 r-xp 00000000 fd:00 1049544                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f324ad98000-7f324af98000 ---p 001b1000 fd:00 1049544                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f324af98000-7f324afb3000 r--p 001b1000 fd:00 1049544                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f324afb3000-7f324afbe000 rw-p 001cc000 fd:00 1049544                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f324afbe000-7f324afc2000 rw-p 00000000 00:00 0
7f324afc2000-7f324b015000 r-xp 00000000 fd:00 1049549                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f324b015000-7f324b215000 ---p 00053000 fd:00 1049549                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f324b215000-7f324b218000 r--p 00053000 fd:00 1049549                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f324b218000-7f324b21e000 rw-p 00056000 fd:00 1049549                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f324b21e000-7f324b21f000 rw-p 00000000 00:00 0
7f324b21f000-7f324b3dc000 r-xp 00000000 fd:00 928411                     /usr/lib/x86_64-linux-gnu/libdb_cxx-5.3.so
7f324b3dc000-7f324b5dc000 ---p 001bd000 fd:00 928411                     /usr/lib/x86_64-linux-gnu/libdb_cxx-5.3.so
7f324b5dc000-7f324b5e4000 r--p 001bd000 fd:00 928411                     /usr/lib/x86_64-linux-gnu/libdb_cxx-5.3.so
7f324b5e4000-7f324b5e5000 rw-p 001c5000 fd:00 928411                     /usr/lib/x86_64-linux-gnu/libdb_cxx-5.3.so
7f324b5e5000-7f324b5fe000 r-xp 00000000 fd:00 930974                     /usr/lib/libboost_thread.so.1.49.0
7f324b5fe000-7f324b7fe000 ---p 00019000 fd:00 930974                     /usr/lib/libboost_thread.so.1.49.0
7f324b7fe000-7f324b800000 r--p 00019000 fd:00 930974                     /usr/lib/libboost_thread.so.1.49.0
7f324b800000-7f324b801000 rw-p 0001b000 fd:00 930974                     /usr/lib/libboost_thread.so.1.49.0
7f324b801000-7f324b85d000 r-xp 00000000 fd:00 931205                     /usr/lib/libboost_program_options.so.1.49.0
7f324b85d000-7f324ba5d000 ---p 0005c000 fd:00 931205                     /usr/lib/libboost_program_options.so.1.49.0
7f324ba5d000-7f324ba60000 r--p 0005c000 fd:00 931205                     /usr/lib/libboost_program_options.so.1.49.0
7f324ba60000-7f324ba61000 rw-p 0005f000 fd:00 931205                     /usr/lib/libboost_program_options.so.1.49.0
7f324ba61000-7f324ba7f000 r-xp 00000000 fd:00 930714                     /usr/lib/libboost_filesystem.so.1.49.0
7f324ba7f000-7f324bc7f000 ---p 0001e000 fd:00 930714                     /usr/lib/libboost_filesystem.so.1.49.0
7f324bc7f000-7f324bc80000 r--p 0001e000 fd:00 930714                     /usr/lib/libboost_filesystem.so.1.49.0
7f324bc80000-7f324bc81000 rw-p 0001f000 fd:00 930714                     /usr/lib/libboost_filesystem.so.1.49.0
7f324bc81000-7f324bc84000 r-xp 00000000 fd:00 930693                     /usr/lib/libboost_system.so.1.49.0
7f324bc84000-7f324be83000 ---p 00003000 fd:00 930693                     /usr/lib/libboost_system.so.1.49.0
7f324be83000-7f324be84000 r--p 00002000 fd:00 930693                     /usr/lib/libboost_system.so.1.49.0
7f324be84000-7f324be85000 rw-p 00003000 fd:00 930693                     /usr/lib/libboost_system.so.1.49.0
7f324be85000-7f324bea8000 r-xp 00000000 fd:00 1049594                    /lib/x86_64-linux-gnu/ld-2.17.so
7f324c01e000-7f324c01f000 rw-p 00000000 00:00 0
7f324c01f000-7f324c04f000 r--s 00000000 fd:00 264747                     /root/.memorycoin/blocks/index/000005.sst
7f324c04f000-7f324c05f000 rw-s 00000000 fd:00 264746                     /root/.memorycoin/chainstate/MANIFEST-000012
7f324c05f000-7f324c060000 rw-p 00000000 00:00 0
7f324c060000-7f324c070000 rw-s 00000000 fd:00 264751                     /root/.memorycoin/blocks/index/MANIFEST-000011
7f324c070000-7f324c09b000 rw-p 00000000 00:00 0
7f324c09b000-7f324c09e000 rw-p 00000000 00:00 0
7f324c09e000-7f324c0a5000 r--s 00000000 fd:00 917816                     /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
7f324c0a5000-7f324c0a7000 rw-p 00000000 00:00 0
7f324c0a7000-7f324c0a8000 r--p 00022000 fd:00 1049594                    /lib/x86_64-linux-gnu/ld-2.17.so
7f324c0a8000-7f324c0aa000 rw-p 00023000 fd:00 1049594                    /lib/x86_64-linux-gnu/ld-2.17.so
7fff84b3d000-7fff84b72000 rw-p 00000000 00:00 0                          [stack]
7fff84bfe000-7fff84c00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Mr Wax,

Not sure if you noticed, but I'm concerned the coin is dying a slow death in its present form and radical surgery is needed to save it. I've proposed a fork.
https://bitcointalksearch.org/topic/memorycoin-grant-system-285232

Interested to hear your thoughts on it as your fund has clearly shown that you have a good understanding of the grants and votes - although I'm sure you'll be conflicted as it aims to kill your fund along with the other interest payment grants.

Also, logo competition is over. A decent logo should help the coin's image.

Come on Quantplus,

the thing that is interesting with this coin is the voting system.
If you want to mine a clone coin with no innovation, there is plenty out there.

The fact that FreeTrade get one of the 5 grant is perfectly normal since he didn't premine.
But yet we can chose at any-time to remove this grant from him.
And that's what happened once already, and he has the right to whine about it.

This is far better than premine, because he can't dump it all at once, and he need to keep on with the support of the coin, otherwise we can remove the grant from him.

As far as the market, I think FT is not the kind of vocal man, who shout everywhere to promote the coin, and it's ok since he is a developer, not a salesman or public relation.
So what memorycoin lack is some kind of promotion.
And I guess as a collective we have to take that in charge.

So if you want more byers, then move your ass and promote the coin !

+1

Hi, FreeTrade!
I hope You are not paying attention to what some nuts have to say about your coin and yourself.

 

I think the money is dead， only  to sell, no one to buy

That's a lot for a small VPS - if it was a octo-core going full blast for the full month, that would be about right.

Currently three highest balances are -

->Balance:12615 - MVF4kgdRuCQoFHxuy63Ses5F3QpfDNJvGy

->Balance:12557 - MTukQztMUSXVrNhf9Wa2APd9tt5vKmCoeo

->Balance:10520 - MDHA5R3Z8wLdwxBUZs8ZS4ukrsc4b3zypC

I think two of them are Bter.

I tried everything and nothing seems to work. But I think it's safe to say that it was a fork and it would be impossible to mine 13200 MEG's with a small VPS in one month otherwise?

Make sure you're using the latest version of the client.

Here's what I do whenever I have a problem with startup (on any coin, not just MEG) Try each of these in turn . . any might fix the problem . .  each takes a bit longer than the previous one, try the first one first.

1. Try deleting the chainstate directory and restarting.
2. Try re-index
3. Try delete block directory.
4. Try delete everything except your wallet.dat

I think i was on a fork (~5700 blocks) so I deleted my blockchain. Now I get this: terminate called after throwing an instance of 'std::runtime_error'
  what():  CreateNewBlock() : ConnectBlock failed

Any ideas what to do?

Thanks for this. I've been looking into it this evening. Looks like my update to halt mining until the block chain was up to date wasn't working. The client was trying to mine and update at the same time, and as we established before, this causes crashes.

I've reverted the changes to the .bat files so that mining is not automatically enabled. Mining needs to be enabled manually again - so after the blockchain is upto date type

setgenerate true

(-1 will cause it to use half available cores)

I've updated the client - will use a fixed address in future for latest client -
http://memorycoin.org/downloads/memorycoin-qt-latest.zip

And dude why the hell did he want to buy coins off me then? eh work that out, I was the biggest miner of this coin at the start, had the top wallet for a while, when the Dev wants to buy some, it means HE DIDNT PREMINE!!!!! or intent to run people,  I got in early, he wanted to buy some, just like any other alt coin buyer at he time.  I had no trouble mining.  The guy put in more effort than a lot of copy paste merchants out on the wild seas, tried to make something different, wheres your coin buddy !! make a better coin then you can lay down the shit. till then wtf

MemoryCoin grant system failing - surgery proposed.

https://bitcointalksearch.org/topic/memorycoin-grant-system-285232

Freetrade purposefully kept UPnP support out of the client so that people would not be able to get onto the Memorycoin network.
He figured he could mine a lot of MEG while keeping the network close to failure, and then add UPnP support later after he's got his bunch coins.

Remember, there's 50 little alts, even all the ones made by newbies have UPnP support, only Memorycoin does not.

This is how he lied to all of you, and he is a con artist.
He tricked you, pulled it right past all of you.
You didn't notice what was going on.

Looks like I've overestimated the resolution of stability issues. I'm still looking at these, but the low hanging fruit is gone now, so fixes are going to be slower to come as the remaining problems are more difficult to track down.

Are you getting this error with the RPC, when you send a second transaction before the first one has received a confirmation? Not sure what might be causing that. Try using the sendmany command if you need to do a lot of transactions - that seems to be working fine.

There was no problem with the wallet, it was synced and continued working as normal as soon as the first transaction received one confirmation.

What I'm pointing is different behaviour if you use the send command in the QT binaries, than sending command to the QT binaries with RPC, via the daemon binaries (tested under ubuntu).

The situation is :
1) you have all your coin on one address.
2) you send some to an external address, and the remainder is automatically send to the originating address.
3) you try to send another transaction, without waiting for the first one to have one confirmation (ie: 0 conf).
4) Depending on the method : you can send it or you get the error : unsufficient fund

I think this come from the check with getbalance which maybe is done differently in the UI than in the RPC.
It remove the sent amount from the balance, but didn't include the received one (since it didn't got one conf)
A patch would count the received one also even with 0 conf, if it comes from the same address.

So far I found the RPC one, not the UI one. If you could help me by telling me where it is, I could check further.