[ANN] MemoryCoin

[MrJiggledaddy]

Just wondering if there's any update/success on tracking down the instability issues (getting hung on a block seems to be the most common, I have seen it once with the new client as well)

[1714955626]

1714955626

[1714955626]

1714955626

[1714955626]

1714955626

[1714955626]

1714955626

[1714955626]

1714955626

[1714955626]

1714955626

[FreeTrade]

Just wondering if there's any update/success on tracking down the instability issues (getting hung on a block seems to be the most common, I have seen it once with the new client as well)

JD, I'm focused on making sure the fork is successful right now. I think the next approach I'll take with the block hanging issue will be to update to the latest core Bitcoin code to see if that helps, but it'll be after the fork at the earliest.

[Eli0t]

loving the new icon and splash screen, very smart

[SlyWax]

I'll be away from my computer, revolution pool payment will be made around 17 sept.
Sorry for the inconvenience.

[superresistant]

What is the calculation for the time to find a block from the current difficulty and the hash per second please ?

Someone posted a formula for this - I think in this thread. Let us all know if it seems to be accurate based on your experiences.

I found the formula and I am posting it for everyone :

(my hash per second x 60 x 60 x 24 hours) / (current difficulty x 16^8) = theoretical number of blocks per day

real number of blocks per day = theoretical number of blocks per day * 0.33

0.33 is based on an estimate of someone that posted in this thread but more data are necessary.

[B.T.Coin]

JD, I'm focused on making sure the fork is successful right now. I think the next approach I'll take with the block hanging issue will be to update to the latest core Bitcoin code to see if that helps, but it'll be after the fork at the earliest.

Please don't take this the wrong way, this is not meant to be sarcastic, but how are you 'focussing' on making sure the fork is successful? Are you staring at your screen all day watching the blocks count up to 8710? You haven't even made the effort to bump this topic up once a day so I guess I'm taking care of that today.
You have to agree that the very best way to get everybody to update his client would be by releasing a (more) stable version.

[superresistant]

It's been more than 3 days that I'm mining, no block, how to determine what is wrong ?

UPDATE : I am sure it is not working. I'm trying to find a solution, will update.

[B.T.Coin]

It's been more than 3 days that I'm mining, no block, how to determine what is wrong ?

"hashespersec" : 2.26142017,

At that hashrate it is possible that you have not found a block for 3 days but that also includes some bad luck.
If you are not using your PC for anything else, you can set genproclimit to the actual number of cores your CPU has (I guess 2 by your hashrate).

[superresistant]

Something curious happened.

I was mining with a high priority process.
I changed it to normal and here is what I got :
{
"blocks" : 7897,
"currentblocksize" : 1273,
"currentblocktx" : 1,
"difficulty" : 0.00011544,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespersec" : 2.09863589,
"pooledtx" : 1,
"testnet" : false
}

The currenblocksize changed from 1000 to 1273 and I've got a currentblocktx : 1.

Priority and transactions in the block aren't related

[B.T.Coin]

The currenblocksize changed from 1000 to 1273 and I've got a currentblocktx : 1.

I looked back into my console where I pull up mininginfo a few times a day and my currentblocksize is 1273 as well with currentblocktx 1, while it was 1000 and 0 on block 7780 so it has nothing to do with your priority setting.
I'm pretty sure these numbers have something to do with the transactions that are inside the block.

[FreeTrade]

I looked back into my console where I pull up mininginfo a few times a day and my currentblocksize is 1273 as well with currentblocktx 1, while it was 1000 and 0 on block 7780 so it has nothing to do with your priority setting.
I'm pretty sure these numbers have something to do with the transactions that are inside the block.

Yes, the blocksize will reflect how many transactions are in the block - starts at 1000 for 0 transactions. Priorty and transactions in the block aren't related. Note the new default behaviour is that -1 will only use half of the available processors. Your hashrate looks pretty low - maybe 1 processor.

setgenerate true <numberofcores>

to increase number of cores used.

[bahamapascal]

Proposal for a Voting GUI

Hi every one, I have been thinking for a while about implementing a GUI system for the Voting
Here is my prototype of the GUI (made with Gimp, not actually implemented in the client yet):


My thoughts are that every user can divide there Voting Power (VP) on up to 100 different addresses by giving each address 1 VP. If I give 60 VP to the MCF, that would mean that 60% of my coins are voting for this address, while my other 40% would still be free to vote for other addresses.
As you can see, you can add and subtract VP, so if the initiative you have supported dose not full fill its promises, you can remove your VP and use them on other addresses.
On the left bottom you can see a button saying " Generate grant address", when clicking on that a window should appear with a impute field for the description where you can put the name/reason and link to a website/forum for more info; also when creating a new grand address you have to pay a fee of lets say 25MEG, which will be refunded should the address get enough Vote support or else, if it dosn´t get enough VP after lets say 7 days, your address will be removed from the list and at the same time you will get the 25MEG back; though there should  be a notification about that in the same pop up window as the description field.Should you have the required funds and have filled the text field you can then proceed to generate the address, which then will get listed in the List.
The 25MEG are there to prevent people/bots to spam the List with hundreds,thousands or even millions of grand proposals, which would/could brake the system.
I hope I explained my idea good enough and have not confused you all, but I hope the image will help you understand
Please think about it, discuss it and add new Ideas if you have some!
If this idea gets positive feedback and we have a final prototype, we can look into the technical stuff of getting it implemented, though for that we would need someone how knows how to program.
I cant program, but if this idea gets the backing of the community then I hope to find someone that will help out or if I don´t we could set up a bounty were every one can contribute to for a professional to do it.
I think a coin is as good as the dev and the community behind it, lets demonstrate that Meomorycoin is a good coin

[superresistant]

Any updated client for linux ?

[FreeTrade]

Proposal for a Voting GUI

Pascal, thanks for your proposal for a GUI for voting preferences.

I think the imminent fork is going to mean that the voting will be of less importance to coin owners, especially smaller holders. As only one grant will be awarded after the fork, it'll simplify the voting and mean that preferences come into play less.

The voting will be effectively be AV or instant runoff voting

http://en.wikipedia.org/wiki/Instant-runoff_voting

Instructions to new coin holders on voting for MCF are very straightforward -

Send .00000001 MEG (1 satoshi) to MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN to vote for the MemoryCoin foundation.

While it would still be nice to have a GUI for allocating preferences, I don't see it as a priority right at this moment. But feel free to undertake any development or improvements you wish. I can't guarantee they'll be included until I've seen them, but I've no objection.

[bahamapascal]

Proposal for a Voting GUI

While it would still be nice to have a GUI for allocating preferences, I don't see it as a priority right at this moment. But feel free to undertake any development or improvements you wish. I can't guarantee they'll be included until I've seen them, but I've no objection.

FreeTrade, thanks for you reply
Ok, you are right, the GUI dose note really make seance any more when there is one fixed Grand fore one fixed address...tough I would say that this Fork should only be temporary until we have a better solution for the voting, as for when the Fork comes into affect the howl point of MEG, which was the voting system, will be taken out.
For now the 1 Grand system might be the correct choice, but I think we have to look for a good alternative ASAP.

I do see some great potential with the voting system, though it would need some changes in the grand system.
For now the grands are only be there to support developers that support the coin, but what would be in two years, when (hopefully) the coin has already bean established and the dev work will supcide to maintenance work, so no more grands would be needed for that, well as far as I understand it the grands will get reduced with blockreword so there won,t be any grands really.
Now my Idea would be to make the Grands as a fixed amount, so there will always be grand rewards....Why? Because then Memory coin could actually be used to support all kinds of research, help all kinds of organizations to get funded. So in the future MemoryCoin could actually be used help fight the poverty in Africa for example, what organization gets funded depends on the users logicaly.
But for that I do see user friendly GUI really important.

So my Proposal would be change the grand system to give out a fixed amount of MEG to 100 grant addresses with the most votes, the Grand reward should then be divided depending on the amount of voting power recived.
What do you think about that FreeTrade?
Also would be nice to hear some one elses opinion on that matter

[stas]

100 grant addresses =  would mean that about 100 people who have the most coins would get those grants.
That's why FreetTrade has changed his code at the first place:)

[MrJiggledaddy]

I think the grants are a great idea, but simply allowing anyone to make a grant address and have it voted on may not be the best way to accomplish a meaningful dent in the crypto world (people will always be greedy, and do anything they can to game the system).

My idea would be to implement a system where grants are proposed (and explained, maybe make a minimum # of words on explanation) through a "grant" tab on the QT miner, and need a certain number of votes (separate from sending satoshis) from mining addresses with >40MEG (or whatever number would work) to become a valid grant proposal, at which point they can be sent satoshis to receive grant status.  It still fits the theme of decentralization since there is no central authority deciding what is a valid grant, it would just require tuning of the # of votes and amount of required MEG per valid voting address to make a grant.

If you also allowed down-voting of a grant, it would ultimately give the masses capability to add or subsequently remove a grant if it was decided it should not be receiving grant coins anymore, as I'm sure would be the case if an individual managed to game that system and vote themselves a personal grant like is currently happening.

This system could allow as many grants as were necessary, and grants could receive a weighted # of the total grant money depending on how many votes they have received (this could be limited by only giving each valid voting address a set # of votes which can be used or retracted at any time, or unlimited to allow groups of miners to jockey for small grants).  The overall idea is simply to give the grant system some checks and balances, to ensure that people are supporting a grant, not just one person.

If I knew anything beyond basic C++, I'd attempt this myself, however I lack the knowledge or programming experience to even have a chance of success.  If anyone can point out any major flaws or necessary refinements in this idea, feel free to.  If we can agree on a system that would be fair and have some semblance of balance, I'd be happy to donate whatever I can to anyone willing to undertake the actual assembly of the code.

Beyond that, I'm still having trouble going more than a day or two without the miner hanging on a block...right now I firmly believe that's the primary hindrance to this coin's success.  People don't want to have to constantly monitor their miners just to make sure they're still mining, and if they have to, they'll move on to a coin that doesn't require this.

[B.T.Coin]

Beyond that, I'm still having trouble going more than a day or two without the miner hanging on a block...right now I firmly believe that's the primary hindrance to this coin's success.  People don't want to have to constantly monitor their miners just to make sure they're still mining, and if they have to, they'll move on to a coin that doesn't require this.

While both you and QuantPlus make valid statements on the grant system, your last remark really hits the nail on the head.
No matter how the grant system is implemented, as long as there are stability issues the coin will not be mined by a broad audience.
Fixing the stability issues should be the #1 priority on FreeTrades list and instead he is focussing on 'fixing' the grant system.
What will happen when the big grant after block 8710 will not go to FreeTrade? Will he go on strike again or do another fork to 'fix' the grant system again?
As you said, people will always play the grant system for their own profit, and I don't see any problem with that since this would require someone to mine the coin intensively (or buy on exchanges) and not sell coins, which all benefits the value of the coin. The only way to get grants awarded that are supported by a large user base, would be to first get a large user base to start with, which can only be done by a reliable stable client.
Even though QuantPlus is a quite hard on FreeTrade, the basics of what he is trying to tell do make sense.

[bahamapascal]

100 grant addresses =  would mean that about 100 people who have the most coins would get those grants.
That's why FreetTrade has changed his code at the first place:)

Well, Yes and No...
When the voting is done over a GUI (Graphical User Interface) most coin holder will vote...and the mass of people with normal balance will have way higher Voting power then a single holder that has large amounts of coins. I guss most users would vote for the MemoryCoinFundation, so it will most likely get most of the grand reward. Ofcours some large coin holders will be able to vote for them self, but that won´t be too bad, as they will not get to  much of the Grant reward. For the beginning it might actually be a good idea to have a high minimum Voting Power before an address gets funded...something like 30k maybe? And then reduce that limit as time passes by? So that would/should stop big coin holders from voting for there self.
What do you think about that? Dose this sound logical or am I overseeing something?
Thanks for your reply by the way

[Stinky_Pete]

Beyond that, I'm still having trouble going more than a day or two without the miner hanging on a block...right now I firmly believe that's the primary hindrance to this coin's success.  People don't want to have to constantly monitor their miners just to make sure they're still mining, and if they have to, they'll move on to a coin that doesn't require this.

While both you and QuantPlus make valid statements on the grant system, your last remark really hits the nail on the head.
No matter how the grant system is implemented, as long as there are stability issues the coin will not be mined by a broad audience.
Fixing the stability issues should be the #1 priority on FreeTrades list and instead he is focussing on 'fixing' the grant system.
What will happen when the big grant after block 8710 will not go to FreeTrade? Will he go on strike again or do another fork to 'fix' the grant system again?
As you said, people will always play the grant system for their own profit, and I don't see any problem with that since this would require someone to mine the coin intensively (or buy on exchanges) and not sell coins, which all benefits the value of the coin. The only way to get grants awarded that are supported by a large user base, would be to first get a large user base to start with, which can only be done by a reliable stable client.
Even though QuantPlus is a quite hard on FreeTrade, the basics of what he is trying to tell do make sense.

+1.
I'm getting tired of checking and have shut a couple of machines down. First a stable coin, then an exchange, otherwise MemoryCoin will just fade away. How about 'suspending' the grants and voting system until the basics are sorted.