Topic: Monero Economy Workgroup - The MEW Thread - page 12. (Read 37978 times)

They both have almost identical levels (well the votelist has base metals instead of "wad of green toiletpaper" ) Perhaps David can copy some of the design elements to the official votelist to make it look less official...

Speaking 100% out of personal opinion here, but I found the quirkiness of the MHoF to be more compelling than a relatively dry/official votelist.

I'd suggest merging the two somehow.

Funny enough, we had a longish discussion about it. Since I am the creator of both some important parts of the MEW and the Community Hall of Fame, I can decide that the MEW votelist ranks higher in precedence. It is a sign of an ongoing commitment, not only of one-time donation.

Will be, as MEW (not as individual donators).

Additional selfish question (partly kidding): is it then reported in the hall of fame?

Immediate answer: Yes.

Sorry if the info is somewhere in the thread, I didn't see it in the FAQ, and have no time to crawl through.
50% of the subscription fees goes to the devs to support development *immediately*, right?

I was going to ask about this, where is our chatroom but it seems David is inviting the members to a channel on freenode, btw, I know from previous experiences that freenode is not safe to anything that must be kept private, their ircops pry, I suggest we open our own irc server.

1. WIF (wallet import format) for private keys and seed defined and implemented (import/export RPC and CLI methods)
Needed for  paper wallets, coin-wallets....
Rationale: There are lead times for making items that can be quite long in some cases.  Having this will start the clock rolling on that.  So I put it first.

2. OTK Address and transaction signing (one time key).
This feature allows proof of ownership of an address, or a transaction.  This should include format definition and the methods implemented.
Rationale: This is something business and accounting will require.  To me, the killer app for Monero is not the "I fear my government" folks.  No, it is the 100% legal high finance and multinational business enterprises internal settlement accounts.
Here's why: If you are the C-level exec doing business internationally, and you are looking to expand in a foreign region, you are going to run up against entrenched interests.  In many/most areas, these will include the local banking systems.  If you want to keep your business advantage of first mover and avoid industrial espionage risks letting the in-country folks collude against you, you want a way to move your money within your company in private OUTSIDE THE BANKING SYSTEMS. Sure you could use Bitcoin for this, but with its public ledger, if the opposition has half a clue, they can track it.  Sure you could take steps to obfuscate the transactions, but then you can't delegate it to your low level functionaries.
MONERO solves these problems in ways we do not expect Bitcoin to address anytime in the near future.
And here's the kicker, that market is 100x what Bitcoin is today.  Even if the only one doing it was Apple Computer, it would overwhelm the total market cap of Bitcoin today, and there are 10,000 companies in this situation.
It's #2 because there are a lot more pieces needed to do this, but this one is crucial.  It will have to be perfectly internally auditable, and perfectly obfuscated externally.

3. AUTH Develop and implement HTTP/HTTPS/RPC simple authentication between components.
This allows merchants to run the daemon on a separate server and communicate securely.  (not every waiter in the restaurant has to have a full block chain on their bill pay device)
Rationale: Small and Medium Enterprise function.  Merchants will need this.

4. GRACE Upgrade error handling in the daemon to either use a "graceful shutdown"
Better stability of bitmonerod by determining if it is necessary to shut down (absolute worst case), or retry indefinitely. the daemon should only die under the most dire of circumstances, and provide alarmable output for manual intervention and remediation.
Rationale: for basic reliability.  We have to have usage, but when they have it, it needs to not break.  I think if we asked our developers to do them in this order, we would be well suited to engage marketing solutions more swiftly.