MemoryCoin - Grant System

[MrJiggledaddy]

This is just a repeat of OP.

CLIFF NOTES

FreeTrade gets 20% of the coins (400,000 out of 2,000,000)... OR HE QUITS.

This is the 2nd time FT has threatened to QUIT... if not 20% CUT go to his POCKET.

Let's be real here...
The "Foundation" will not be feeding orphans in the streets of Calcutta...
This is a skewed, "highly deflatinonary" coin designed as a fairly sophisticated Pump n' Dump...
Where FT plan was to get 30-40% of the coin in 6 months, dump, and disappear.

Maybe make $10K or minimum wage for his P n' D. This is shameful, baby.

MemoryCoin has zero chance of long term success...
FT is broke/cheap and is up against better, VERY well financed coins...
Coins with serious Dev teams and real staying power.

On the other hand...
I sold 500 MEG yesterday @0.00025 = Mining Cost...
So it will probably drift up to 0.0002 or whatever Mining Cost is.

"Wise men speak because they have something to say; fools because they have to say something."

[1714994046]

1714994046

[1714994046]

1714994046

[1714994046]

1714994046

[1714994046]

1714994046

[1714994046]

1714994046

[1714994046]

1714994046

[YukonCoinelius]

Changing from 5 grants to 1 grant likely will not solve anything. That will probably be gamed into an interest pool too. Here are some other ideas:

MemoryCoin Voting - Ideas and Suggestions, 2013-Sept

• A long way to solution is first of all massively slowing down the grants - to give a reasonable timeframe for drawing up proposals, laying them out, users understanding them, voting on them. Even something like 1 grant round per week or two. Or maybe the addresses encode a time period through which they are valid. Or a voting round ends when there's a threshold winner, as I mention below. You could keep the 5 parallel lines. If you want to keep the same relative proportion of grants to total mint, you can increase the grant amount per round, or have it on a different schedule (so the grant awards go out past the 2 years, after mining subsidy has dropped).
  
  
• To stop the exchanges or largest holders from dominating the voting, you could cap the vote power at some moderate amount (e.g. max vote is 100 coins), or make it a logarithmic scale. For example 1 coin = 1 vote, 10 coins = 2 votes, 100 coins = 3, etc.  Or make a “House/Senate” system where the decision has 2 components: the proportional coin amount as currently, plus a new component of 1 address = 1 vote.
  
  This would counter the self-grant pooling, because the primary motivators for such pools would likely want to divide the proceeds on a proportional basis; small holders would not benefit in such pools, and thus vote for something else, and on a log scale their small vote is more significant.   (This might still be game-able - for example, by mass-splitting a wallet, but hopefully that would be more trouble than it's worth?)
  
  
• A 1-address 1-vote component could also have some interesting uses for “American Idol” style votes -- even on issues completely separate from the coin itself. This could generate high interest and demand for MemoryCoin. i.e. General popularity votes, with repeat voting allowed as a “measure of enthusiasm”, yet constrained by the non-zero cost. Consider 2 million Idol viewers seeking 0.10 MEG accounts to vote (!!)
  
  
• You could set a minimum percent of the total outstanding mint needed for a vote to succeed. Instead of just beating all the others, it has to both win and be above N%. So proposals need widespread community response to win. Grants that don't reach the minimum are not allocated and the funds carry forward to subsequent rounds.
  
  
• Maybe votes should automatically reset after each round? (This should be a relatively easy code change too - just count the voting transactions over the last N blocks, instead of forever.)
  
  
• Can MEG support multiple styles of voting -- all the above and more, encoded in some way, like in the grant addresses. There should also be votes de-coupled from money awards (this is possible with the current system, but could be made easier to use - so the whole community, or subsets of users could be running their own distributed votes on lots of issues simultaneously).
  
  
• I had been thinking from early on, that maybe some grant addresses should be a scarcer resource, or subject to a level of pre-validation. Say they had to be issued and digitally signed by the MemoryCoin Foundation at (small) fee, with some preliminary statement about the purpose. That would give a better record of what the proposals involve, and potentially deter self-grants. Plus it's an additional source of funds for the MCF. And it's reasonable to have the coin foundation enforcing the one rule that “you can't wish for more wishes” (i.e. no self-grant votes)
  
  

[YukonCoinelius]

A 1 or 2 week voting round, with a nice summary of the open proposals each week, would give people some time to read, assess, vote - even if they only dropped in to the forums a couple times per week. The default voting case should be “status quo” (versus the current “streaming firehose”), so the voting system can be running and tabulating things, but monies are not actually awarded until the community is really at a consensus.

Also I'd say advertise and apply the voting system as a *Feature* more. Seems to me you missed a golden opportunity just now with the logo prize - a tailor made issue for the community to vote on, and really belonging to them. (this oversight could be a little what's driving the “quantplus” voices -- that you are talking “community/foundation”, but actions have a flavor of “sole proprietor”. To my perception you are at least trying to balance that line to get the coin bootstrapped, but others may see it differently.)

Remember, voting in itself takes time and overhead -- people are not going to do it unless it is clear, simple, and there is some definite purpose and benefit. “More coins for me” everyone understands -- beyond that you get into promises, philosophy and abstraction. It also needs documentation, and an easier UI.

Also, in a pure community consensus, you would have to accept if they don't want a “Foundation” and demand the developer(s) bug off and “stop stealing their coins” It doesn't help to “strike” or “raise awareness” about it. There's a limit to the enlightened self-interest out there, and generally speaking miners want 110% of a coin that somehow also has a market value, and automatically keeps working forever with no developer support.

However, it seems you as the designer envision MemoryCoin must have a Foundation support structure (a reasonable position, imo) -- even if it requires dictatorial override. So then you cannot be in pure consensus. Instead just send 1 or 2 or 5 of the grant streams to MCF permanently and that's that. I think a significant part of the community would support that.

By the way, whatever the MCF grant amount is, I would recommend just grant yourself something for development work out of those funds, in an open way. Having 1 stream for the MCF that you admin, and then be soliciting more grants for your work, may give users a sense they are “paying twice”.

Finally, you probably need the foundation to have more directors/steering committee before too long.

[SlyWax]

FT please remove "failing" from the title,
use "rework" or "change needed" !

Otherwise we are continuing the marketing havoc !

Think of the people who just read titles, you are putting something bad in their memories and it's not a memorycoin  !!!

[QuantPlus]

-------------:
Vote Count:
-------------:
---Current Balances------

->Balance:22007 - MUPoRVH2cZBkfaP9JB7PdFugVyWy97GBcv

->Balance:11532 - MVF4kgdRuCQoFHxuy63Ses5F3QpfDNJvGy

->Balance:10520 - MDHA5R3Z8wLdwxBUZs8ZS4ukrsc4b3zypC

->Balance:9998 - MNNFraHV8KfeLoqib6Vwf6P31twihjRqQD
--Preference 1 10000 MVTEoEohmThgMYijuR2oPZSmStTdycrGzp
--Preference 2 20000 MVTEoEogmJxZ9k7iyxE7B85e8xgyJAh5RN
--Preference 3 30000 MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT
--Preference 4 31000 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 5 32000 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 6 33000 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:7989 - MHT3fBXt4822Vxpy1LMuBp3gocmqniNorv
--Preference 1 30 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 2 33 MVTEoEotER3e9NfAMPi1c1E68h5bthH4K4
--Preference 3 35 MVTEoEoPjXcay3aJU1uZCsipX7pf9xryW4
--Preference 4 40 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 5 50 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:7596 - MLdZXb6PTZ1Pz9iSsUF2UGtkTJ28Ek4GTS
--Preference 1 110 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 2 113 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 3 116 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
--Preference 4 120 MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N
--Preference 5 130 MVTEoEorLyJKdtGFXfFTt3Joevk7PeRvzh
--Preference 6 1000000 MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT

->Balance:6303 - MBw4baArvAshpJtogWM4A39MBcrXoxkfAB
--Preference 1 5 MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
--Preference 2 10 MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6
--Preference 3 30 MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N
--Preference 4 35 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 5 40 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 6 50 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:5774 - MJK1i3vRbvPKnsAR5tCsaCTe1E2jxgfSxJ
--Preference 1 140000 MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT
--Preference 2 170000 MVTEoEogmJxZ9k7iyxE7B85e8xgyJAh5RN
--Preference 3 200000 MVTEoEohmThgMYijuR2oPZSmStTdycrGzp
--Preference 4 420000 MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6

->Balance:5172 - MJWmKpLXQe7ynkDZsZWRQc8hDn5rc1UWFg

->Balance:4413 - MCXkEvc9bgseKeg5yzuPWr1ZuzfhjZ937Z
--Preference 1 3000100 MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT
--Preference 2 4000000 MVTEoEogmJxZ9k7iyxE7B85e8xgyJAh5RN
--Preference 3 4500000 MVTEoEohmThgMYijuR2oPZSmStTdycrGzp
--Preference 4 4600000 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 5 4700000 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 6 4800000 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
--Preference 7 5000000 MVTEoEo2Sq1UHbGM8CN6hUPFB1n4QqR8ZK

->Balance:4000 - MEuQsvcdbnfddGHGhXKw9roaPRviynuJNw

->Balance:3901 - MK5EBBmTsuJthCvaQMr7dYobQFyJPXtsGH

->Balance:3500 - M8ZDY4Si2wXUFuRbZ52ng9VYcMapnK1oNo
--Preference 1 40 MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N

->Balance:3400 - MUXXjstFsQuFchUcBK4hCtQ79tfrkRDQGr

->Balance:2639 - MVZEBcsue2Y2MBFPQ6Mru5uL8vZEAPiMcm
--Preference 1 2 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 2 11 MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
--Preference 3 14 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 4 16 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:2430 - MLC881tEdvtNXyAgj32nKy8WUCDDjgvLxv

->Balance:2120 - MUHNQBgMpFQPoVFxhWAAgzmo9tcWhRGUuR

->Balance:2000 - MMsfCTbjecQ9yKpWcZugbgmVEBup6bt11m

->Balance:1799 - MHBJLX7T7yLKAJunqKNuztRtf559k1dyuE
--Preference 1 10 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:1754 - MHSRfiWe9bka53T33pKRTEXXXJKFQWt1x3

->Balance:1751 - MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
--Preference 1 20 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 2 1000000000 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:1650 - MV4ScnPhAheeQsaGnuMK88Z7UruH3Fzs4x

->Balance:1621 - MG7BQJRFfVjwgoJqXDGy7Sqx6scQr6jRqa
--Preference 1 20 MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
--Preference 2 30 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 3 40 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
--Preference 4 50 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3

->Balance:1560 - MJ9JoYwv1duKTgyX41ZsC6Q2c8azL2nuV3

->Balance:1536 - MFZoWrJu4WxugGLcbrKPYHykXE8c9B45SN

->Balance:1499 - MDuPPqqSUWHrYYL1PR7dnPrrxF4sSCVKXv

->Balance:1488 - MBMtZbRwaVX8LgUgc25unK9pTMLfPff1Cm
--Preference 1 800 MVTEoEorjtwtccACwSTb53uJcjmjUnyexu
--Preference 2 900 MVTEoEoiZ8QhdkbiFmvWqA8RcWhg5QX9JA

->Balance:1481 - MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 1 10 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3

->Balance:1460 - MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 1 20 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
--Preference 2 40 MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N
--Preference 3 50 MVTEoEorLyJKdtGFXfFTt3Joevk7PeRvzh
--Preference 4 1301039890 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN

->Balance:1451 - MRNrnpP9tVdi46MwD8BNsWbwUTh452prgt
--Preference 1 10 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN

->Balance:1434 - MN3mo8xaxzKuj9Nm1Mc6dbu6JJ7BKKZCA1
--Preference 1 4 MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
--Preference 2 10 MVTEoEoz64v8PH7nTLZaHvra3qnFYSsBcS
--Preference 3 11 MVTEoEotER3e9NfAMPi1c1E68h5bthH4K4
--Preference 4 12 MVTEoEoPjXcay3aJU1uZCsipX7pf9xryW4
--Preference 5 20 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 6 30 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
--Preference 7 32 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 8 50 MVTEoEot8ZGKWmDi8pZS6tJMHR5ba9MnNN
--Preference 9 61 MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N
--Preference 10 75 MVTEoEorLyJKdtGFXfFTt3Joevk7PeRvzh

->Balance:1368 - M9Nw6YQahKdrGdsqEETL7rZ6uFMtuRNJKn

->Balance:1367 - MFQKaVRiCDMZjLwCUFKcSGCudzjVYXhD8n

->Balance:1353 - MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
--Preference 1 2 MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb

->Balance:1345 - MALwYdqkQwUfBjjb1Nzwtzyk8yUfvHy2AS

->Balance:1274 - MCJR541x2pt2cghPLXtniMec2Z3JEaLfkr
--Preference 1 9 MVTEoEocT88fm2fZuyNFgrD9W5nEKVtqaH
--Preference 2 10 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:1169 - MLceYcAbSzXDWrZjsMdAtr4tJszADeEcW9
--Preference 1 9 MVTEoEocT88fm2fZuyNFgrD9W5nEKVtqaH
--Preference 2 10 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z

->Balance:1096 - MLtX6dhtw1Aufq5m8Vm2rsTDfYEZaJw4Wn

->Balance:1033 - MTBwEVgf86o8xsVPaXkDtcKvDgT46M2vY3

->Balance:1020 - MFD1TRKxJqjHUGjjLu3uKYi5K3B1K5ZVV8

->Balance:1000 - MLMAnjERopycPfoVwuwX6YZLiJDLisUXRc

->Balance:892 - MESibqmrfYSHqiXzyKWcGDg8kkkuraiFuA

->Balance:878 - M8m7Zy1xdizyayKgK5B5FYCMiaN3rDi1Zd
--Preference 1 9 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 2 12 MVTEoEot8ZGKWmDi8pZS6tJMHR5ba9MnNN
--Preference 3 15 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN

->Balance:870 - MDnQHzXuADPbcuHgJeXivpQwDdgvYFWTgh

->Balance:866 - MHodpHe3qVMzGKtgcrjwRQdvUTEyaXfHPE
--Preference 1 10 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
--Preference 2 30 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
--Preference 3 35 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
--Preference 4 100 MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N

->Balance:853 - MQva9hjVyFJA6qLesuXNGvYfFwAQMaq8tq
--Preference 1 2 MVTEoEoX1qsfoBUMejjjBuzUfbSDaT3JK9
--Preference 2 50 MVTE3E2B63YE3MUj59Ai2xmvDVqPhXEZ8g
--Preference 3 130 MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN

->Balance:806 - MGDXpdrDgjEnAesSgVAbzpUFaYaBYJTWRY

->Balance:802 - M9tX3DrD4nrgAtmgV7PkE224hZntAHV6BN

->Balance:802 - MFgAeqaAzzob9fMRcY2jpkxWPyUb3A7tdv

->Balance:797 - MUbK5o7SRLztrJ43e4nTq87T6S87BNKeA6
---End Balances------
--------Grant Voting--------
Total coin issued: 185192
Total of Voters' Balances: 72060
Percentage of total issued coin voting: 38percent
Droop Quota: 12010
-------------:
Award Round:0
Candidate Elected: MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3 (14779)
Surplus Transfer Value: 0.187357
-------------:
Award Round:1
Candidate Elected: MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb (12880)
Surplus Transfer Value: 0.0675797
-------------:
Award Round:2
Candidate Elected: MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN (12352)
Surplus Transfer Value: 0.0277011
-------------:
Award Round:3
Candidates Eliminated (21)
Candidate Eliminated: MVTEoEorjtwtccACwSTb53uJcjmjUnyexu 1488
Candidate Eliminated: MVTEoEoiZ8QhdkbiFmvWqA8RcWhg5QX9JA 1488
Candidate Eliminated: MVTEoEocT88fm2fZuyNFgrD9W5nEKVtqaH 2467
Candidate Eliminated: MVTEoEoJ1vP6NHHcCTTBPy4bXfejbAqV5N 3925
Candidate Eliminated: MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z 7315
Candidates Eliminated (1)
Candidate Eliminated: MVTEoEorLyJKdtGFXfFTt3Joevk7PeRvzh 1601
Candidates Eliminated (1)
Candidate Elected: MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT (10622)
Surplus Transfer Value: 0
-------------:
Award Round:4
Candidate Elected: MVTEoEohmThgMYijuR2oPZSmStTdycrGzp (10409)
Surplus Transfer Value: 0
--------End Grant Voting--------
Add grant award to Block MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3 1954815000
Add grant award to Block MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb 1954815000
Add grant award to Block MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN 1954815000
Add grant award to Block MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT 1954815000
Add grant award to Block MVTEoEohmThgMYijuR2oPZSmStTdycrGzp 1954815000
---Current Balances------

->Balance:22007 - MUPoRVH2cZBkfaP9JB7PdFugVyWy97GBcv
---->No Vote: (Add Some Voting Preferences)

->Balance:11532 - MVF4kgdRuCQoFHxuy63Ses5F3QpfDNJvGy
---->No Vote: (Add Some Voting Preferences)

->Balance:10520 - MDHA5R3Z8wLdwxBUZs8ZS4ukrsc4b3zypC
---->No Vote: (Add Some Voting Preferences)

->Balance:9998 - MNNFraHV8KfeLoqib6Vwf6P31twihjRqQD
---->9998 supported MVTEoEohmThgMYijuR2oPZSmStTdycrGzp

->Balance:7989 - MHT3fBXt4822Vxpy1LMuBp3gocmqniNorv
---->7767 supported MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
---->221  wasted (Add More Preferences)

->Balance:7596 - MLdZXb6PTZ1Pz9iSsUF2UGtkTJ28Ek4GTS
---->6173 supported MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
---->1383 supported MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
---->39 supported MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT

->Balance:6303 - MBw4baArvAshpJtogWM4A39MBcrXoxkfAB
---->5877 supported MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
---->425  wasted (Add More Preferences)

->Balance:5774 - MJK1i3vRbvPKnsAR5tCsaCTe1E2jxgfSxJ
---->5774 supported MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT
---->0 supported MVTEoEohmThgMYijuR2oPZSmStTdycrGzp

->Balance:5172 - MJWmKpLXQe7ynkDZsZWRQc8hDn5rc1UWFg
---->No Vote: (Add Some Voting Preferences)

->Balance:4413 - MCXkEvc9bgseKeg5yzuPWr1ZuzfhjZ937Z
---->4413 supported MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT
---->0 supported MVTEoEohmThgMYijuR2oPZSmStTdycrGzp

->Balance:4000 - MEuQsvcdbnfddGHGhXKw9roaPRviynuJNw
---->No Vote: (Add Some Voting Preferences)

->Balance:3901 - MK5EBBmTsuJthCvaQMr7dYobQFyJPXtsGH
---->No Vote: (Add Some Voting Preferences)

->Balance:3500 - M8ZDY4Si2wXUFuRbZ52ng9VYcMapnK1oNo
---->3500  wasted (Add More Preferences)

->Balance:3400 - MUXXjstFsQuFchUcBK4hCtQ79tfrkRDQGr
---->No Vote: (Add Some Voting Preferences)

->Balance:2639 - MVZEBcsue2Y2MBFPQ6Mru5uL8vZEAPiMcm
---->2145 supported MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
---->461 supported MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
---->32 supported MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN

->Balance:2430 - MLC881tEdvtNXyAgj32nKy8WUCDDjgvLxv
---->No Vote: (Add Some Voting Preferences)

->Balance:2120 - MUHNQBgMpFQPoVFxhWAAgzmo9tcWhRGUuR
---->No Vote: (Add Some Voting Preferences)

->Balance:2000 - MMsfCTbjecQ9yKpWcZugbgmVEBup6bt11m
---->No Vote: (Add Some Voting Preferences)

->Balance:1799 - MHBJLX7T7yLKAJunqKNuztRtf559k1dyuE
---->1799  wasted (Add More Preferences)

->Balance:1754 - MHSRfiWe9bka53T33pKRTEXXXJKFQWt1x3
---->No Vote: (Add Some Voting Preferences)

->Balance:1751 - MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
---->1423 supported MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
---->328  wasted (Add More Preferences)

->Balance:1650 - MV4ScnPhAheeQsaGnuMK88Z7UruH3Fzs4x
---->No Vote: (Add Some Voting Preferences)

->Balance:1621 - MG7BQJRFfVjwgoJqXDGy7Sqx6scQr6jRqa
---->1512 supported MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
---->106 supported MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
---->3  wasted (Add More Preferences)

->Balance:1560 - MJ9JoYwv1duKTgyX41ZsC6Q2c8azL2nuV3
---->No Vote: (Add Some Voting Preferences)

->Balance:1536 - MFZoWrJu4WxugGLcbrKPYHykXE8c9B45SN
---->No Vote: (Add Some Voting Preferences)

->Balance:1499 - MDuPPqqSUWHrYYL1PR7dnPrrxF4sSCVKXv
---->No Vote: (Add Some Voting Preferences)

->Balance:1488 - MBMtZbRwaVX8LgUgc25unK9pTMLfPff1Cm
---->1488  wasted (Add More Preferences)

->Balance:1481 - MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
---->1204 supported MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
---->277  wasted (Add More Preferences)

->Balance:1460 - MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
---->1460  wasted (Add More Preferences)

->Balance:1451 - MRNrnpP9tVdi46MwD8BNsWbwUTh452prgt
---->1411 supported MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
---->40  wasted (Add More Preferences)

->Balance:1434 - MN3mo8xaxzKuj9Nm1Mc6dbu6JJ7BKKZCA1
---->1337 supported MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
---->96  wasted (Add More Preferences)

->Balance:1368 - M9Nw6YQahKdrGdsqEETL7rZ6uFMtuRNJKn
---->No Vote: (Add Some Voting Preferences)

->Balance:1367 - MFQKaVRiCDMZjLwCUFKcSGCudzjVYXhD8n
---->No Vote: (Add Some Voting Preferences)

->Balance:1353 - MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
---->1262 supported MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
---->91  wasted (Add More Preferences)

->Balance:1345 - MALwYdqkQwUfBjjb1Nzwtzyk8yUfvHy2AS
---->No Vote: (Add Some Voting Preferences)

->Balance:1274 - MCJR541x2pt2cghPLXtniMec2Z3JEaLfkr
---->1274  wasted (Add More Preferences)

->Balance:1169 - MLceYcAbSzXDWrZjsMdAtr4tJszADeEcW9
---->1169  wasted (Add More Preferences)

->Balance:1096 - MLtX6dhtw1Aufq5m8Vm2rsTDfYEZaJw4Wn
---->No Vote: (Add Some Voting Preferences)

->Balance:1033 - MTBwEVgf86o8xsVPaXkDtcKvDgT46M2vY3
---->No Vote: (Add Some Voting Preferences)

->Balance:1020 - MFD1TRKxJqjHUGjjLu3uKYi5K3B1K5ZVV8
---->No Vote: (Add Some Voting Preferences)

->Balance:1000 - MLMAnjERopycPfoVwuwX6YZLiJDLisUXRc
---->No Vote: (Add Some Voting Preferences)

->Balance:892 - MESibqmrfYSHqiXzyKWcGDg8kkkuraiFuA
---->No Vote: (Add Some Voting Preferences)

->Balance:878 - M8m7Zy1xdizyayKgK5B5FYCMiaN3rDi1Zd
---->713 supported MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
---->164  wasted (Add More Preferences)

->Balance:870 - MDnQHzXuADPbcuHgJeXivpQwDdgvYFWTgh
---->No Vote: (Add Some Voting Preferences)

->Balance:866 - MHodpHe3qVMzGKtgcrjwRQdvUTEyaXfHPE
---->842 supported MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
---->23  wasted (Add More Preferences)

->Balance:853 - MQva9hjVyFJA6qLesuXNGvYfFwAQMaq8tq
---->853  wasted (Add More Preferences)

->Balance:806 - MGDXpdrDgjEnAesSgVAbzpUFaYaBYJTWRY
---->No Vote: (Add Some Voting Preferences)

->Balance:802 - M9tX3DrD4nrgAtmgV7PkE224hZntAHV6BN
---->No Vote: (Add Some Voting Preferences)

->Balance:802 - MFgAeqaAzzob9fMRcY2jpkxWPyUb3A7tdv
---->No Vote: (Add Some Voting Preferences)

->Balance:797 - MUbK5o7SRLztrJ43e4nTq87T6S87BNKeA6
---->No Vote: (Add Some Voting Preferences)
---End Balances------

Winner Support:

--MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
-->6173 MLdZXb6PTZ1Pz9iSsUF2UGtkTJ28Ek4GTS
-->2145 MVZEBcsue2Y2MBFPQ6Mru5uL8vZEAPiMcm
-->1423 MVTEoEomFfe7WuSEepMLsorgYzCQGBVw1z
-->1204 MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3
-->713 M8m7Zy1xdizyayKgK5B5FYCMiaN3rDi1Zd
-->349 MAxkTCzYLXxDz13Gbg8crVK6KemgdB61zF
-->0 MUeywvnSFJkGXmUeQUmU5R2xaZCbJzfWFo

--MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT
-->5774 MJK1i3vRbvPKnsAR5tCsaCTe1E2jxgfSxJ
-->4413 MCXkEvc9bgseKeg5yzuPWr1ZuzfhjZ937Z
-->349 MVTEoEohmThgMYijuR2oPZSmStTdycrGzp
-->41 MFTo6Zi9MSSaqPJgHN81vmx7a2JTvEbMQP
-->39 MLdZXb6PTZ1Pz9iSsUF2UGtkTJ28Ek4GTS
-->4 MCkYX4Pb8VkjHmPpSdMsRJXvSNCQaShibs
-->0 MVTEoEogmJxZ9k7iyxE7B85e8xgyJAh5RN

--MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN
-->7767 MHT3fBXt4822Vxpy1LMuBp3gocmqniNorv
-->1411 MRNrnpP9tVdi46MwD8BNsWbwUTh452prgt
-->1383 MLdZXb6PTZ1Pz9iSsUF2UGtkTJ28Ek4GTS
-->842 MHodpHe3qVMzGKtgcrjwRQdvUTEyaXfHPE
-->195 MCtcVHKJ5TE2ApMQ98NGgJgqAHNo1jUKg4
-->163 MSekCT8Ku8MfZoBLsf3TxmRY9jvY6QttdC
-->106 MG7BQJRFfVjwgoJqXDGy7Sqx6scQr6jRqa
-->60 MK7qLauMb3KpPiTaewxZ86Yz7sd8uez8q7
-->42 MPbaj3wMtjpBA7tFp7fJv5j8tqnzey2o8y
-->32 MVZEBcsue2Y2MBFPQ6Mru5uL8vZEAPiMcm
-->1 MNBETvfQMJofkwPXAu5ASH147KTCeDbSaL
-->1 MRuwaBbpWYYfmbiSqX4xrfAxrke8CLp6aS
-->1 MRNNhufU7PcmRa5xRz3TAKQo57uw2sxgkE
-->0 M9rJudKWdiE4dQd2K6DD9bLtkviKwnhNZG

--MVTEoEohmThgMYijuR2oPZSmStTdycrGzp
-->9998 MNNFraHV8KfeLoqib6Vwf6P31twihjRqQD
-->370 MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT
-->41 M9Xjv58st5QKsgk46hJr8usuk5tm8Xbwnz
-->0 MJK1i3vRbvPKnsAR5tCsaCTe1E2jxgfSxJ

--MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
-->5877 MBw4baArvAshpJtogWM4A39MBcrXoxkfAB
-->1512 MG7BQJRFfVjwgoJqXDGy7Sqx6scQr6jRqa
-->1337 MN3mo8xaxzKuj9Nm1Mc6dbu6JJ7BKKZCA1
-->1262 MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb
-->601 MPbaj3wMtjpBA7tFp7fJv5j8tqnzey2o8y
-->461 MVZEBcsue2Y2MBFPQ6Mru5uL8vZEAPiMcm
-->287 MQK9ZavrzxcddELgvmNwN9xbEVYfzLFWMc
-->247 MD1d4fmmR6L5WVLkDnXW6q97nLR4gdoFX2
-->206 MWVPeDDTzGLnTNmN2N6RwuXkBTAt1EdqTZ
-->81 MVvYBMGfriDRwXnQexNC3btQT3BHM5aGpr
-->55 MCkYX4Pb8VkjHmPpSdMsRJXvSNCQaShibs
-->21 MNBETvfQMJofkwPXAu5ASH147KTCeDbSaL
-->20 MRuwaBbpWYYfmbiSqX4xrfAxrke8CLp6aS
-->18 MHHi9szgTGWV8GcqqQMCosh8RV2963QopV
-->18 MRNNhufU7PcmRa5xRz3TAKQo57uw2sxgkE
-->0 MWzGk6zAvXdwrY98RmpXG7VxZHcXeSeXHK

[QuantPlus]

The above cryptic text file is what people see IF THEY...

(1)  Set a command line switch before running the Client.

(2)  Actually find this file and can be bothered to decipher it.

No Developer can possibly be this incompetent...
So it's obvious to me that the OBSCURITY IS BY DESIGN.

And has been from Day One... go read the early August.

[QuantPlus]

For example, this simple summary COULD be displayed:

------- Grant Voting -------

Total coin issued: 185192
Total Votes:        72060
Pct Voting:         38
Droop Quota:      12010

---------- Results -------------------- Vote --- Grant ------ Identity

(1) MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3.... 14,779  19.54815... FreeTrade
(2) MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb..  12,880  19.54815... Revolution Fund
(3) MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN...  12,352  19.54815... FreeTrade
(4) MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT.. 10,662  19.54815... unknown
(5) MVTEoEohmThgMYijuR2oPZSmStTdycrGzp..  10,409  19.54815...  unknown

But just this shows FreeTrade with 14% of the coins...
And he no doubt has significantly more.

FreeTrade is on record claiming he has only 9% of the coins...
He posted this about 3-4 days ago... A Point Blank Lie.

It's all about pumping and dumping 20-40% of the coins in a few months...
And most of the posters in this thread are suffering from Stockholm Syndrome...
You have become part of the Pump and Dump.

[xan_The_Dragon]

I knew this woukld be a problem from the start, way  too predictable!

[MrJiggledaddy]

For example, this simple summary COULD be displayed:

------- Grant Voting -------

Total coin issued: 185192
Total Votes:        72060
Pct Voting:         38
Droop Quota:      12010

---------- Results -------------------- Vote --- Grant ------ Identity

(1) MVTEoEo5LgYAMVh95oBBfGPj2eCDzkuJC3.... 14,779  19.54815... FreeTrade
(2) MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb..  12,880  19.54815... Revolution Fund
(3) MVTEoEoXmYzFydRfg5uNJRewt9tZ329fAN...  12,352  19.54815... FreeTrade
(4) MVTEoEoHX4XhRkJnkGVLKDYhHG4MbJDVCT.. 10,662  19.54815... unknown
(5) MVTEoEohmThgMYijuR2oPZSmStTdycrGzp..  10,409  19.54815...  unknown

But just this shows FreeTrade with 14% of the coins...
And he no doubt has significantly more.

FreeTrade is on record claiming he has only 9% of the coins...
He posted this about 3-4 days ago... A Point Blank Lie.

It's all about pumping and dumping 20-40% of the coins in a few months...
And most of the posters in this thread are suffering from Stockholm Syndrome...
You have become part of the Pump and Dump.

Stop cluttering up an otherwise productive thread with useless misinformation.  I do appreciate the fact that there was an actual suggestion for a new UI for voting, but given that it was sandwiched between heaps of slander and unsubstantiated claims, please just go away.

[FreeTrade]

Thanks - some interesting ideas - some comments

Changing from 5 grants to 1 grant likely will not solve anything. That will probably be gamed into an interest pool too.

With the 5 grant system I think coin owners were happy to try to grab one, hoping other owners would support the community grants. But as other coin owners saw the unfairness of this, they wanted in on it too . . . soon anybody who supported the community grants was feeling like a mug, because they were the only ones not getting any interest.  I don't think this will happen with a single grant system - either coin owners will support a foundation type grant or they kill the coin. I think there might be disengagement (regrettable), and maybe revolution (fine), but not interest payments.

A long way to solution is first of all massively slowing down the grants - to give a reasonable timeframe for drawing up proposals, laying them out, users understanding them, voting on them.

I was hoping this would happen, but it didn't and I don't see any way to encourage or incentivize it at this point. Maybe when then coin is more mature - but how to get to that point?

To stop the exchanges or largest holders from dominating the voting, you could cap the vote power at some moderate amount (e.g. max vote is 100 coins), or make it a logarithmic scale. For example 1 coin = 1 vote, 10 coins = 2 votes, 100 coins = 3, etc.  Or make a “House/Senate” system where the decision has 2 components: the proportional coin amount as currently, plus a new component of 1 address = 1 vote.

This would counter the self-grant pooling, because the primary motivators for such pools would likely want to divide the proceeds on a proportional basis; small holders would not benefit in such pools, and thus vote for something else, and on a log scale their small vote is more significant.   (This might still be game-able - for example, by mass-splitting a wallet, but hopefully that would be more trouble than it's worth?)

Yes, pretty sure anything that adds a cap will cause wallet splitting, and be gamed that way. Maybe not worth it presently, but as the coin grew, this would become the intractable problem.

A 1-address 1-vote component could also have some interesting uses for “American Idol” style votes -- even on issues completely separate from the coin itself. This could generate high interest and demand for MemoryCoin. i.e. General popularity votes, with repeat voting allowed as a “measure of enthusiasm”, yet constrained by the non-zero cost. Consider 2 million Idol viewers seeking 0.10 MEG accounts to vote (!!)

That would be an interesting feature for a coin . . . however I generally regard those tv shows and votes to be pretty obnoxious (stealing money from the young). I don't think there is a way to use it for useful votes because of the wallet splitting problem though. There's no way to enforce one person, one vote. All that works is 'one coin, one-vote' which is proof of stake voting, only really useful for issues related to the coin.

You could set a minimum percent of the total outstanding mint needed for a vote to succeed. Instead of just beating all the others, it has to both win and be above N%. So proposals need widespread community response to win. Grants that don't reach the minimum are not allocated and the funds carry forward to subsequent rounds.

Maybe votes should automatically reset after each round? (This should be a relatively easy code change too - just count the voting transactions over the last N blocks, instead of forever.)

Think these would require a greater level of understanding and engagement with the voting - not sure how to encourage that yet.

Can MEG support multiple styles of voting -- all the above and more, encoded in some way, like in the grant addresses. There should also be votes de-coupled from money awards (this is possible with the current system, but could be made easier to use - so the whole community, or subsets of users could be running their own distributed votes on lots of issues simultaneously).

Think a coin could be used this way as a method of voting - it would be an interesting coin. You'd need an authority to validate users as individuals, unless you were happy to use proof-of-stake in a coin to be a suitable weighting.

I had been thinking from early on, that maybe some grant addresses should be a scarcer resource, or subject to a level of pre-validation. Say they had to be issued and digitally signed by the MemoryCoin Foundation at (small) fee, with some preliminary statement about the purpose. That would give a better record of what the proposals involve, and potentially deter self-grants. Plus it's an additional source of funds for the MCF. And it's reasonable to have the coin foundation enforcing the one rule that “you can't wish for more wishes” (i.e. no self-grant votes)

Trying to avoid any type of centralization. I think crypto-currencies need to be immune from shutdown, so must avoid a required central authority. The main reason for having voting at all is that MCF can be removed by vote when something better comes along.

[FreeTrade]

Also I'd say advertise and apply the voting system as a *Feature* more. Seems to me you missed a golden opportunity just now with the logo prize - a tailor made issue for the community to vote on, and really belonging to them. (this oversight could be a little what's driving the “quantplus” voices -- that you are talking “community/foundation”, but actions have a flavor of “sole proprietor”. To my perception you are at least trying to balance that line to get the coin bootstrapped, but others may see it differently.)

Remember, voting in itself takes time and overhead -- people are not going to do it unless it is clear, simple, and there is some definite purpose and benefit. “More coins for me” everyone understands -- beyond that you get into promises, philosophy and abstraction. It also needs documentation, and an easier UI.

Also, in a pure community consensus, you would have to accept if they don't want a “Foundation” and demand the developer(s) bug off and “stop stealing their coins” It doesn't help to “strike” or “raise awareness” about it. There's a limit to the enlightened self-interest out there, and generally speaking miners want 110% of a coin that somehow also has a market value, and automatically keeps working forever with no developer support.

However, it seems you as the designer envision MemoryCoin must have a Foundation support structure (a reasonable position, imo) -- even if it requires dictatorial override. So then you cannot be in pure consensus. Instead just send 1 or 2 or 5 of the grant streams to MCF permanently and that's that. I think a significant part of the community would support that.

Because the value of the coin had reached almost zero, it was a market signal that the coin needed redesign. That does need to be a little dictatorial. With this fork, I'm open to persuasion, but I need to take a lot of things into consideration - the development required, state of the code, distribution of coins. I'm open to persuasion, but I haven't been persuaded against my original plan yet.  Once it's bootstrapped and has value, it's not appropriate to be making any hard forks - I'm hoping that it will reach a balance where the MCF is directed by large coin owners voting for it, or diverting their votes to another similar organization.   

By the way, whatever the MCF grant amount is, I would recommend just grant yourself something for development work out of those funds, in an open way. Having 1 stream for the MCF that you admin, and then be soliciting more grants for your work, may give users a sense they are “paying twice”.

That would make it a 'postmine'. Probably postmining would be better for a new coin than premining . . but I think stake holder voting is more dynamic so is better again.

Finally, you probably need the foundation to have more directors/steering committee before too long.

Yes, would you be interested in serving?

[FreeTrade]

Stop cluttering up an otherwise productive thread with useless misinformation.  I do appreciate the fact that there was an actual suggestion for a new UI for voting, but given that it was sandwiched between heaps of slander and unsubstantiated claims, please just go away.

Don't worry, he's just trash talking the coin to drive down the price so he can accumulate. Worry when he starts talking it up again - that means he's about to sell - watch out below!

[QuantPlus]

reserved

[FreeTrade]

Ok - I'm pressing ahead with the hard fork on block 8710. That's 1 week from now, and should give everybody enough time to get the updated code.

I've uploaded a new client here -
http://memorycoin.org/downloads/memorycoin-qt-latest.zip

and Github is updated with the new source.

From block 8710 onwards, only 1 large grant rather than 5 small ones will be awarded in the block chain. This change has been made to ensure that awards are only made to grants that enjoy broad community support. The total amount of awards won't change so the inflation rate will remain unaffected.

[FreeTrade]

I had been thinking from early on, that maybe some grant addresses should be a scarcer resource, or subject to a level of pre-validation. Say they had to be issued and digitally signed by the MemoryCoin Foundation at (small) fee, with some preliminary statement about the purpose. That would give a better record of what the proposals involve, and potentially deter self-grants. Plus it's an additional source of funds for the MCF. And it's reasonable to have the coin foundation enforcing the one rule that “you can't wish for more wishes” (i.e. no self-grant votes)

I gave this some more thought and it might be possible to do without centralization.

There could be two levels of voting - one level to elect the regulator - this would be MCF or similar organization. The regulator would be elected at regular intervals in a popular poll and would act to approve grant addresses.

The second level of voting would be for grants - the same as the original MC vision, but only approved addresses would be eligible.

I don't quite have the resources to develop that yet, but it theory, it could all take place in the block chain.

With the new single grant system, it will still be possible for MCF to award grants from its funds according to vote. MCF can announce a prefix for a new vote (M1VTExxx), people can vote on them, and then MCF can run analysis software on the blockchain to see which has the most support. I don't have anything set up for that, but it doesn't require any changes to core software.  Indeed votes could be run this way for any coin where a proof of stake vote is required.

[SlyWax]

FreeTrade, you are pushing a fork which contain your original idea, without asking community approval.
A fork like this require large consensus, this is not a bug patch !

You didn't took account of the nice idea people have sent.
Making a single grant is going to kill the fun of this coin (basically it will be the MemoryCoinFondation grant), and with all clones around what do you have left to keep miners in ?

So that was for the criticism part, now the proposition :

Grant calculus should happen in 2 stages :
- 1st stage : An electable grant candidate need to have at least 50% of vote at any position ( meaning that it doesn’t matter if the candidate is the last choice of a voting address, this vote count in the 50% barrier calculus )
- 2nd stage : Make the regular election calculus as before, but only with grant candidate that passed the first stage 50% barrier.

This way only grant candidate that are accepted by 50% of vote have a chance to compete for the 5 grants award.
What all of you think of that ?

[FreeTrade]

FreeTrade, you are pushing a fork which contain your original idea, without asking community approval.
A fork like this require large consensus, this is not a bug patch !

I think you have to take the context of it into account. The coin had lost all its value, there were almost no buy orders at all. The community was disengaged. The only value the coin had was the development work that I was prepared to put in for free to do surgery. Since I've proposed surgery and released the fork, the coin has been recovering value. That means people think it has a chance again. 

You didn't took account of the nice idea people have sent.
Making a single grant is going to kill the fun of this coin (basically it will be the MemoryCoinFondation grant), and with all clones around what do you have left to keep miners in ?

You could always start a competing foundation - that might be fun! You'll have to consider its aims carefully though - if it's an interest fund and you win the vote, you'll risking killing the coin. I'd like if there were credible alternatives to MCF for people to vote for. 

So that was for the criticism part, now the proposition :

Grant calculus should happen in 2 stages :
- 1st stage : An electable grant candidate need to have at least 50% of vote at any position ( meaning that it doesn’t matter if the candidate is the last choice of a voting address, this vote count in the 50% barrier calculus )
- 2nd stage : Make the regular election calculus as before, but only with grant candidate that passed the first stage 50% barrier.

This way only grant candidate that are accepted by 50% of vote have a chance to compete for the 5 grants award.
What all of you think of that ?

I thought this was a brilliant idea for a few minutes, but as I gave it more thought I started to forsee a problem with it . . . it would kill the private grants, but I think your interest fund would still survive, and if it did, it would grow to capture 2, 3, 4 and maybe all 5 of the grants as interest payments. The problem with 5 grants is that as soon as 1 is subverted as interest . . . everyone wants interest and no-one supports grants that support the coin.

[QuantPlus]

The lack of interest in this is STRIKING.

7 days and 37 posts... and ONLY 670 views...
Can't be more than 20-25 people that care.

Anyway, it's been fun being part of a disastrous launch...
Since one learns an order of magnitude >> from problems and mistakes...
This has been a great resource for the Alt Coin Launch Learning Curve.

Results: 4,300 net MEG sold @0.000389 = 1.5 BTC

Thank you miners... and thank you Heisenberg

[SlyWax]

FreeTrade, you are pushing a fork which contain your original idea, without asking community approval.
A fork like this require large consensus, this is not a bug patch !

I think you have to take the context of it into account. The coin had lost all its value, there were almost no buy orders at all. The community was disengaged. The only value the coin had was the development work that I was prepared to put in for free to do surgery. Since I've proposed surgery and released the fork, the coin has been recovering value. That means people think it has a chance again. 

Some trader want to by but you can't tell why.
And as far as the miners I repeat, you need consensus, otherwise you face a fork in the blockchain.

You didn't took account of the nice idea people have sent.
Making a single grant is going to kill the fun of this coin (basically it will be the MemoryCoinFondation grant), and with all clones around what do you have left to keep miners in ?

You could always start a competing foundation - that might be fun! You'll have to consider its aims carefully though - if it's an interest fund and you win the vote, you'll risking killing the coin. I'd like if there were credible alternatives to MCF for people to vote for. 

I would do it just to prove you wrong, but I'm a peaceful guy.

So that was for the criticism part, now the proposition :

Grant calculus should happen in 2 stages :
- 1st stage : An electable grant candidate need to have at least 50% of vote at any position ( meaning that it doesn’t matter if the candidate is the last choice of a voting address, this vote count in the 50% barrier calculus )
- 2nd stage : Make the regular election calculus as before, but only with grant candidate that passed the first stage 50% barrier.

This way only grant candidate that are accepted by 50% of vote have a chance to compete for the 5 grants award.
What all of you think of that ?

I thought this was a brilliant idea for a few minutes, but as I gave it more thought I started to forsee a problem with it . . . it would kill the private grants, but I think your interest fund would still survive, and if it did, it would grow to capture 2, 3, 4 and maybe all 5 of the grants as interest payments. The problem with 5 grants is that as soon as 1 is subverted as interest . . . everyone wants interest and no-one supports grants that support the coin.

Well, it is a brilliant idea and I guess you are kind of blindfolded her.

The Revolution Pool have barely 18% of the actual votes and 7% if every one voted.
So it's a long way to 50%.
And if it would get those 50% then it'll grab the unique big grant that you are promoting.
And since a unique grant will make people even less interested in voting, then it will be even easier to grab it for the rich motivated people.

Whereas with my method you could even raise the barrier to entry to 75% for example.
But the accepted candidates would then still have a fair fight.

So basically I'm giving you the key to defeat my pool, but you don't see it !?
And let's face it, if 75% of coin holders think some candidate is acceptable, who are you to say the contrary ?

I really would like to have others opinion on this.
It's important that it's not a discussion between FT and me and that others state their opinions.
If someone is not sure to understand fully, feel free to ask.

As a side note, this could be a good opportunity to promote the limited grant address (the ones that will only give a fixed amount to the owner and not more) since they will likely be more prone to get the acceptance ratio.

[bahamapascal]

Just wantet to let you guys know that I made a GUI Proposel over at https://bitcointalk.org/index.php?topic=267522.msg3112937#msg3112937 ....feel free to come over there and let us know your opinion:)
Thanks