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

Actually, I believe we want to encourage community based grants for these funds, it would encourage adoption of the coin by allowing communities of miners to compete with each other for a chunk of the grant.  If you also include a maximum amount of the total grant a single proposal can capture (say 20%), then once a grant hits 20%, people no longer have any need to put more of their limited votes to it, and if they do, they're effectively wasted.

While there's always the possibility that these "interest fund" grants would grow to capture more than one individual grant once the first hits 20%, it's incredibly unlikely that this would ever cause you or MCF to actually lose your grant.  If you also allow more than 5 grants (maybe not unlimited, but a lot, in this sense I agree with the 100 grants idea), then you may not get a full 20% of the grant coins, but however much you do receive would fully be a reflection of the mining community's perception of how well you're doing as a developer.  Additionally, even if these interest funds captured 80% of the grants in total, that would simply be an indication of the community mindset in general, and if the mindset is truly that greedy overall, it's very likely that those interest funds will eventually capture your single grant in the planned fork.  The bottom line is that as long as you let people vote on where free money goes, there will be a certain percentage that will always vote for it to go to themselves.

As for the potential of having a voted on regulator to approve grant proposals, I believe it would be detrimental in that the regulator would inevitably make a decision that upset some people, and these people would rally/rage/abandon the coin.  If this were to happen to a large enough extent, or if a malicious group managed to gain control of this regulatory position it could effectively kill the coin by giving them too much control.  If, instead, you allow your users to directly control approval of grant proposals before they're even voted to be funded, the only blame for a bad decision is on the community itself, and people tend to get less angry when they're the one making the decisions, even if they're stupid decisions that backfire.

There's merit to this. While awarding interest through grants is unfair . . . interest is not evenly distributed, it does create a source of demand for the coin. Coin owners can find themselves in a position where they only need 1% additional coins to secure a 4% grant. This creates competition and demand. Demand is essential for a coin and creating demand in the early stages is worth looking at.  However it may create a bubble, and I wonder if a new coin would survive the subsequent bust.   

Making a special Grant "tab" for people to vote on new grand addresses is definitely a interesting idea! Though I personally think that it might make it more complicated then necessary.
I think that this problem should get taken care of automatically by getting enough voting support or not. And I think for the beginning we should set minimum required vote support, for a grant address to be accepted, rather high (maybe 30k Voting Power? ).
In case you over read my initial post:


Hmm, so you suggest making a option to use your VP to cast a negative vote, is this correct? Interesting idea, will think about it some more, but I think that might be a nice option.



Hey thanks, that would be grate if you would help donate fore development ...but let´s first get the ideas straightened out, then when we have agreed on a plan we can look into development and donations.
Yes the hanging on a block is still annoying, though lately I have gone several days before it hang on a block, so that's an improvement from the beginning If you are not already, try starting the normal memorycoin-qt.exe (and not the "start.bat"). I have way less problems with errors since I start without the add noods....tough this might just be coincidence, don´t know.

And thanks for your thoughts and support, really appreciate it

This is an interesting idea - but I wonder if it would be possible to structure it in a way that prevents a Mr. Wax style interest fund - where a broad base of coin holders collaborate to split interest payments. Some more discussion on that here -
https://bitcointalksearch.org/topic/m.3093133

For a multiple grant system - this is the idea I'm leaning towards -
https://bitcointalksearch.org/topic/m.3086702

+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.

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

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.

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.

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:)

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

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.

Any updated client for linux ?

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

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

to increase number of cores used.

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.

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

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).

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.

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.

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.