[ANN] MemoryCoin

[stas]

I have installed the latest version on two PC's. So far works fine.

[cryptrol]

It seems the blockchain takes ages to synchronize and the coin is only some days old.

[FreeTrade]

It seems the blockchain takes ages to synchronize and the coin is only some days old.

Yes, the hash takes a long time to run - say 0.5 seconds or so . . . at a block height of only 1,200 . . . that's 600 seconds, 10 minutes. We're going to need a hash-lookup table distributed with the executable at a minimum for new nodes.

[FreeTrade]

Proposal for a restart -
http://21stcenturymoneytalk.org/index.php/topic,30.0.html

[B.T.Coin]

Proposal for a restart -
http://21stcenturymoneytalk.org/index.php/topic,30.0.html

If you move all balances over to block 1 of the restart then I think it's the best thing to do.
I assume we all keep out wallet.dat files?

[albon]

If you can sort out the bugs then I am all for it.
At the moment I can't mine this as every time I try the client crashes.
Yes I do start in non mining mode.

[bahamapascal]

Proposal for a restart -
http://21stcenturymoneytalk.org/index.php/topic,30.0.html

Oh yes, a restart sounds good, though how dose the balance get transferred from this version to the new one?
Will the balance be subtracted from the new block chain? Or will it just be added to the total of one million ?
If it just gets added then that will be relay bad for the distribution, as some people have already mined a ton full and if they get a second chance of mining them easy, some might end up with 10k+, which would just be catastrophic for the price, as when such amounts get dumped the market will be saturated and the price will drop like a stone....
I my self have 192 MEG, which is already quite a bunch and I would of cours love to keep them...but I don't know if that is fare for the newcomers?

On a second note I have a suggestion for a change in the new MemoryCoin chain...
How about changing the block time to 1 min and setting the block reward to 2.4? I love everything about MEG, just that I think its way to slow to send them.
I see nothing bad for a faster block time, or is there something I am not aware of?
Also I think that it would be better to mine with faster block time, as you are more likely to find a block faster, which would be a good thing when the difficulty is high...
Would love to here your thoughts about that

[cryptohunter]

although i have some coins i suggest full restart from scratch to get those that have had issues and left the coin back in the game, no point otherwise only the few still mining and have coins will continue to mine. I see the quark diff has shot up double again now too so i'm guessing a few have jumped back on to that one. A full restart with notice and fair launch i think would be best.

[FreeTrade]

although i have some coins i suggest full restart from scratch to get those that have had issues and left the coin back in the game, no point otherwise only the few still mining and have coins will continue to mine. I see the quark diff has shot up double again now too so i'm guessing a few have jumped back on to that one. A full restart with notice and fair launch i think would be best.

Okay, a few coin owners are saying they'd like a full restart - It might be a good idea, even if you hold a large balance. I think the fairest thing is to hold a vote on it.

If you're in favour of a fresh restart, vote for
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv

If you're in favour of putting existing balances into Block 1, vote for
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6

Whichever gets the higher vote (whichever is awarded first, or eliminated last) in Block 1560 (votes as at 1540), will be the winner and I'll abide by the decision. I'll stay neutral and won't vote.

[FreeTrade]

Is the problem was that 48 coins were distributed in the vote?  If so, it looks like your account.  You could sent a number of coins to MTVEthesecoinsdontcount address (and bogus address) to destroy those coins. 

Was this a widespread issue?

Yes, the grant award code is borked in a sort of random way - it's difficult to predict what it might do - Block 520 is just the first manifestation of wrongly awarded grants.

[cryptohunter]

although i have some coins i suggest full restart from scratch to get those that have had issues and left the coin back in the game, no point otherwise only the few still mining and have coins will continue to mine. I see the quark diff has shot up double again now too so i'm guessing a few have jumped back on to that one. A full restart with notice and fair launch i think would be best.

Okay, a few coin owners are saying they'd like a full restart - It might be a good idea, even if you hold a large balance. I think the fairest thing is to hold a vote on it.

If you're in favour of a fresh restart, vote for
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv

If you're in favour of putting existing balances into Block 1, vote for
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6

Whichever gets the higher vote (whichever is awarded first, or eliminated last) in Block 1560 (votes as at 1540), will be the winner and I'll abide by the decision. I'll stay neutral and won't vote.

Maybe put a thread with a voting facility on, there are probably not 10% of people checking this thread as started reading it upon launch. The coin is  a great idea but i think we need to get a lot of interest in the coin again. Many have left this thread now and mining other things. I understand those that have tons of coins want to get some credit for all of their mining so its a hard choice really. If you do relaunch in full have a big announcement and countdown.

[stas]

I don't like this idea
Even though I do not have that much of a coins.
Next time you will find something else that is not perfect, so Restart again?
is there an end to it?

[B.T.Coin]

I don't like this idea
Even though I do not have that much of a coins.
Next time you will find something else that is not perfect, so Restart again?
is there an end to it?

The idea of a restart is not that bad if everybody gets to keep his coins.
I absolutely hate the idea of a fresh restart with all balances wiped out, so I already cast my vote on keeping the balances.
I burned enough energy to get my coins. Hell, I even bought some coins for hard BTC so wiping all coins would make me walk away from memorycoin forever.

[stas]

I agree with you.
But there is a voting for it.
I have voted for the "restart while keeping the current balances".

[devlin]

I voted to MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6  "putting existing balances into Block 1"

[FreeTrade]

Why not a third option for a Hard Fork?  Yes, there would be inaccurate votes in some prior blocks, but that data is not used after 20 blocks.  Simply update code and hard fork.  The issue is minor and the price for [Experiment] title.

My concern here is that the coin has 2 objectives (as I understand): 1) That voting thingy; and 2) CPU based coin.  To be a successful CPU coin, you may have to update the mining algorithm in the future to block GPU\ASIC from taking over. {Is this the idea behind the coin?}  When this happens, you don't want to keep doing restarts.

Thanks for the suggestion. I'll try this out. If I can get the code changed to fix all the errors, and accept the current block chain, a hard fork would be the better solution.

[B.T.Coin]

A hard fork would be a good option as well. Let's see if the dev can make this work.

In other news, the first votes came in on round 1380 and it looks as if most miners want to keep their coins.
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv rejected in round 1
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6 rejected in round 3

[FreeTrade]

I'm leaning towards a hard fork at 1566 - more details here -

http://21stcenturymoneytalk.org/index.php/topic,30.msg54.html#msg54

[dzhan]

yes, hard fork is a better option.
Restarting the coin would be probably ok as long as early adopters could keep their coins.

[YukonCoinelius]

1) Hard fork is by far the best option.  A "restart" should only be the last resort if the hard fork is impossible, or itself fails  (for example, has an error that kills the new chain, or too many people stay on the old software).

The canonical way to hard fork is you put the old protocol code in IF blocks, like this:

Code:

if (nHeight < NNN)
  {old protocol code}
else 
  {new protocol code}

so the historic part of the chain accepts. Many of the altcoins have such scattered all over the place.


Also, remember to leave a long enough window that people can get the new software installed (several days at least).  I know it seems urgent that faulty votes/credits may be getting in, but discrepancies of a few blocks/coins are minor relative to tossing the entire 30000+ coin history.  Everyone on-board understood and accepted there might be some experimental snags.


2) In a restart scenario, it would be wise to maintain the original idea of preserving the balances (best effort), unless it's just too hard (eg. too many accounts to track by hand).  Most/all your early adopters put in significant energy and time experimenting and shaking out the bugs with that expectation, and a poof scenario will demoralize their enthusiasm and support.


3) In the life of a coin, you get maybe one restart, and after that you're in "can't get fooled again" territory.  And a zero restart, especially on a new port address, is effectively a new coin, with the added baggage of having already "failed" once, and discouraged early adopters.   Especially for a cpu coin, that leaves you the botnetters - not exactly the most community-minded group.  So IMO, we shouldn't even be voting on it, given that the much better options 1 and 2 above are still open.


===========

Other Notes:

* Reducing block maturation from 120 to 45 seems fine, though probably unnecessary.

* In regards switching ports on a restart, keep in mind they are a limited resource, and there is already growing contention among the altcoins.  The community cannot really sustain each coin variant grabbing 1, let alone more.   Is it necessary in the hard fork case?  Other altcoins are hard-forking all the time, and I have never heard of a port change.

* 6 minute block time  (mentioned above) is a *feature* for security and robustness, not a bug.