musicoin / mcips Goto Github PK

We should consider better collection and presentation of geographical information to a musician since it's a global project with many language diversity. Let's find a better design in "Application" layer.

//This is just a general idea to foster further discussions. It is supposedly to have full MCIPs to summarize all discussion and take actions accordingly.

Ever since $MUSIC blockchain genesis on Feb.11th, we have received several rounds of ebb and flow from miners community and eventually all reflected in market.

The volatility was normal to any new currencies, which was also in my expectations. However, the biggest controversy in the past months, on money policy, didn't get well understood by community. Since it is related to the currency performance, the same time leading to the future of the system, I have to explain more and seek further deliberations.

The design of $MUSIC(or Musicoin the whole project) is to peg with music consumption, or we won't even create this new currency and make it mine-able. It also means it's associated with real world economy. Music industry yield 6-7 Billion USD revenue in digital recording, which is far below the hay days in history. The issuance of a new currency for $MUSIC, seemingly not so significant, but maybe helpful to make it great again. It's the design of the currency and blockchain, and we are here already. I explained many times that music consumption in this world is much valuable than current economic scale, but not well reflected and/or collected because of the wrecked structure of legacy system. $MUSIC is to change the paradigm, it's why a currency should match this vision.

It's why we didn't set the cap of the issuance of the currency and let it naturally emit from the adoption. Nonetheless, I also heard the outcrying from early adopters who wish to invest and see it's up-roaring all the time(it's impossible to any currency, right?). I'm seriously thinking of how to adjust the policy in the next upgrades. Of course, it needs some systematic thinking and holistic thinking. We should keep the faith on the vision, the same considering all the stakeholders along the road. I hope this issue will lead a constructive process to start working toward a more delicate solution in the next move, and give the system a brighter future.

Difficulty bomb is a legacy issue planted in Ethereum blockchain to set a harsh deadline for the project team to switch to POS(proof-of-stake). Yet PoS is still not mature, the difficult bomb is closer to explode for both ETH and ETC(ETC, nevertheless, managed to delay the process with one hard fork).

We need to have a solution to face the deadline as well since it will come inexorably. One idea is to delay it to a longer time(ie. 3 more years) with a hard fork to give enough timespace to think about future solutions; another idea is to leave it along and just boost our investment on development on Proof-of-sharing (different from Proof-of-stake). Either way, we need some concrete roadmap before too long, it's why I create this issue to discuss and all comments are welcome.

Preamble

MCIP:
Title:
Author: trustfarm ([email protected]), 5chdn (...) , im
Type:
Category (*only required for Standard Track):
Status: Draft Proposal
Created: 2017-10-30
Requires (*optional): Consensus of Estimated Feature updates dates
Replaces (*optional):
Simple Summary

Abstract

Prevent replay Attack, enabling the EIP-155 Protocol.

Motivation

Current gmc-v2.0 doesn't applied ethereum's EIP-155 Protocol.
So, there's risk of replay attack on ethereum based chain.
Thus we need to apply this feature on musicoin chain as soon as possible.

Specification

1. apply to above gmc-v2.2x , rmc-v2.2x (parity based musicoin node)
2. when (what blocknumber) enable EIP-155 feature on musicoin chain.

Rationale

I've tested the EIP-155 enabled feature on local environment.
It needs to future blocknumber assign is better for user.

Backwards Compatibility

If node set to N th blocknumber, EIP-155 will node client re-sync from N th block height.
0~(N-1) block height : backward compatible.
above N block : EIP-155 enabled block.

Test Cases

Implementation

above gmc-v2.0 , we can configure what time we apply EIP-155.

Copyright

Copyright and related rights waived via CC0.

MUSIC community has had a broad discussion over Bittrex delisting and expressed deep concern over the fund they hold in custody. There are several big questions we may need to solve socially, technically, or even legally:

1. Upon their notice to close the wallet,
   https://bittrex.zendesk.com/hc/en-us/articles/360032872331, Bittrex didn't disclose how they deal with the residue fund in their wallet, which is obscure and risky to the community.
2. Since there's outstanding bait fund Bittrex didn't return to Musicoin Project, what actions we can take to demand it back or counter their offense.
3. How we can protect the community's biggest interest since there could be a lot of users didn't get well notified to take out their fund from Bittrex wallet. They would face some bigger difficulties in the future to file recovery request.

We'd love to hear more ideas, including any possible moves from our technical side to ensure the utmost of safety and interest for the community members. Please feel free to comment here and we will respond asap to make sure our motions are inclusive enough.