Risks List

This is the risk list of all Mochimo related projects together.

Aim and explanation

The aim of this risk list is to put on paper what might be considered as a risk for he project. It can be of any type: Technical, exchanges related, wallet related, blockchain, block explorer, transactions, cryptography, algorithms, discord server issues, marketing related, and so on. It can also involve several components, and yet the reporter doesn't even need to know which part or person it would be realted to. If the risk grows too much we can categorize them.

The advantage of such a risk list is that anybody, from most experienced developers from team members to first comers, can provide a risk item related on some experience he had that was bad or he wonders how it would behave, and that he felt was really important or could potentially jeopardize the project, as he thinks. He might be wrong, but the risk for him is there. By expressing it in this risk list as a new risk item, it allows Mochimo experts to answer to that risk supposition, validating or invalidating it, provide solutions or mitigations for it, conducting tests to dismiss it, correct a bug or involve people to work on them to lower that risk likelyhood or impact. The newcomer can also define a risk rating, if the impact of such a realized risk would be very high or quite little if he has an idea of it. Usually a risk item will translate in new bugs tickets created in one or more projects, but it doesn't have to. Generally, this list is maintained by the project manager, because he must make sure that the project will be successful in the end, and he has the role to enforce making sure the risk is not real, or solve it with his team. However in an open source project it can be different, but a maintainer should have enough self responsability to be willing to take this role.

Risk lists allow having a more in-depth view of what is going on in the project, what are the current most important risks and if someone is taking care of them or not, trying to provide solutions. Generally it is especially used by directors, to know what are the biggest issues the project is facing. Also the project manager will be able to show them this risk list to demonsrtate that more ressources or money is needed to be able to reach the time and features goals.

For project managers, it can really help them concentrate on the most important tasks, and organize the project schedule to synchronize all components needed to be able to move to the next step, and assign ressources appropriately. It usually helps a lot to generate the timeline like with Microsoft project for example, and helps him adapt it when needed.

More specifically for projects, devs can see what other devs are facing as issues and try to figure out powerful solutions in just a few seconds thinking of it, which brings a huge distribution of ressources and optimizations that one dev wouldn't even see himself. It helps communication and reduces drastically the time to solve an issue or implement something, thanks to other specialists that are queried about each situations, if they know about. They can provide a technology name to do it for example. It puts all brains quickly on a situation and the best solution is found and validated by the whole core team, or else the impact rating can be increased, to show that something needs to be investigated on that point. Also, it helps keep track of quite common risks that people think about, and to know quickly if this is a fake risk, a real one and what mitigation or solution has been or is being implemented to counter it.

It is important that anyone interested in the project, especially core developers, try to be "risk-aware" and create a new risk item in this list as soon as they have a doubt about something and feels that things might become complicated or risky if this or that situation is not solved. Either in their own code or in the code of someone else. Usually in a meeting one dev will say to another "hey, did you think about that? what happens if... Please have a look, or else write the risk item so we can take care of it when we can".

Risks shall not be removed, nor their number be changed. We need to keep them and just put the likelyhood rating to 0 once it is mitigated. This helps people to know it cannot happen and helps remind what was the solution for it.

Definition of a risk item

It is a simple line in a table that contains several columns, usually in a spreadsheet to be able to compute points and categorize them easily. The only required field is the description of the risk. All others are optional and can be filled by the risk maintainer or anyone of the core members who knows what to do with this item at best. Other members can also provide corrections, suggestions about that risk and a solution or mitigation to it, directly in the table. Each risk item has two ratings: a likelyhood rating that the risk occurs and an impact rating (on the whole project), each in a scale between 0 and 10. There is a mitigation field where either a solution is provided by fixing a bug, or a mitigation is given to reduce the risk, to bring it to an acceptable level that is very unlikely to happen, which is usually a workaround or blocking a feature, etc...

Example: The project manager knows his team and he sees that the project will take probably longer as expected, because there is too much work in the end. He needs more people to work on a specific part. He will enter a risk that shows the importance of that risk like this: Description: The milestone set for this date will probably not be met due to unexpected work overhead, not enough ressources Likelyhood rating: 7/10 (it might very well happen) Impact rating: 10/10 (the impact will be big, the expectations will not be met at that date) Mitigation: hire more devs or delay the milestone.

The director will see this risk list with the project manager and as the director has promised this feature to be done quickly to his board of directors, he allows $1M more, and the risk is mitigated, the timeline should still be met unchanged due to this action.

Risk list

Item #	Description	Likelyhood rating / 10	Impact rating / 10	Mitigation	Next step	Mitigated	Reported by	Assigned to
0	Model line [Description]	0 [Likelyhood]	0 [Impact]	[Mitigation]	[Next step]	[Mitigated]	[Reported by]	[Assigned to]
1	Block explorer not showing all movements on a tag since block 1 might rebuke exchanges or users	5	6	Correct the block explorer so it shows all transactions per tag and wots addresses	Implement mitigation suggestion	No	sputnik	-
2	Not enough trading volume on coinsbit.io might kick MCM out of it, like stated on their terms of use	8	4	Check with exchange if it can really happen or if there is a specific exemption for MCM. If real, ask if chances are that some bot will come in automatically. Else figure out how to motivate bots to come or evaluate if possible to create one	Take contact with exchange	No	sputnik	-
3	The tag address is very small, it could be hacked or recovered very easily	0	4	This cannot happen because the tags are only pointers to much bigger WOTS addresses, so there is no risk that they could be recovered or find out cryptographically.	None. There is nothing to do, it is safe	Yes	newcomer	-
4	Newcomers on discord Mochimo server might be flagged as spammers by the bot spam incorrectly. This might lower the number of people really willing to join.	0	2	There is a hidden channel that all new users have access to where they can alert us if they are having problems doing the Captcha. When legitimate users have problems and contact us in that channel, we gladly let them in.	None	Yes	sputnik	-
5	Fountains might be down or overloaded, which would not allow people to crate tags anymore in case there is huge tag resitration increase.	1	4	First mitigation would be to add new fountains quickly to handle the load. Second mitigation proposed by NickP05 is to implement some API to let wallets check the status of the fountain, if it is overloaded or not and check for another fountain if it is the case (MIP to be done). Sputnik suggests a simple TCP port check to know if it is up. In both cases, they could not be added easily as they are in the properties of the wallet. MIP-0008 suggests a distributed way to share the fountain list, MIP-0006 shows another way to implement it but with a DNS formatting.	None	No	sputnik	-
6	Fountains might be down when the user registers a tag and it causes an issue or fails the tag registration.	7	3	Check the fountain TCP port if it is open before doing the tag registration so that this would not happen. Still a very little time where this might happen if fountain fails between the two requests but it should solve 99% of the situations.	Change net wallet version	No	sputnik	-
7	Payments from a raw WOTS address with same amount done two times (typically from a WOTS address that received mining rewards) could provide the same TXID even with Mochimo 3.0, and hence make it impossible for miners to recover their money.	8	5	Even if this is specified that it must not be done, the system should prevent this situation so that nobody can even generate it. It might cause blockchain inconsistencies, where the total money is not the one speicifed and remove coins, like burning them. And each transaction must have only one TXID.	Discuss the best way to reach this goal.	No	sputnik	-
8	If a chain split happens and a miner got a mining reward just before the split, he will not see his reward in the new chain or could spend it twice.	7	4	This issue is the same with bitcoin. This is why they implemented a system where coinbase coins cannot be retrieved during 100 blocks	Check if something similar is implemented in MCM	No	sputnik	-
9	The other MCM coin called 'Money Cash Miner' might cause issues with people mixing up their coin with ours and exchanges not accepting Mochimo due to that.	6	2	Removing this coin from remaining exchange to try to help about that	Wait for southxchange answer	In progress	sputnik	Stackoverflo
10	Code not being regularily commited or publicly available on Github might rebuke people's interest in the project, and hence potentially miss new developers, investors, convinced people, helpers of any kind. That could draw the coin down in many ways. Also it will make it very hard to be accepted by exchanges as this is usually a strong request from them.	5	7	Put all code publicly available on Github, and perform regular commits and pushes (every week maximum)	Discuss the subject	No	sputnik	-
11	Withdrawing funds from exchanges can fail	3	3	A new bug has been filed about that so that it can track these failures and provide more info: github bug. If found that it is an improvement that should be made on Mochimo, then it would be good to fix it.	Investigate why these failures happen and if there is only one type or several ones.	No	sputnik	-
12	There is no way to check that the ledger corresponds to the blockchain. This might rebuke people to adopt Mochimo, them not being sure that the system really works or has been hacked at one point	7	3	MIP-0009 has been proposed to present a Ledger check system	Check if this can be done	No	sputnik	-
13	Impossible to retrieve transactions older than 6 months. This might rebuke people when tey see that they cannot see the detail of their old transactions.	7	3	MIP-0009 has been proposed to provide a block explorer with Ledger and blockchain mixture	Check if possible to implement.	No	sputnik	-