General Overview
MicroCash is an open banking or economic system that is completely decentralized and that anyone can join at any time. Is entirely free and no one owns it or controls it. It requires zero trust in anyone to have a secure account or to send funds to anyone, anywhere in the world. Anyone can join the MicroCash network and verify and view every transaction over it, unlike existing hidden banking networks and credit card merchants (Visa/Mastercard/etc). However joining the network directly itself is not required to actually use MicroCash, it is useful for businesses and to ensure the open nature of the network for those that are curious.

MicroCash aims to be more competitive than all existing fiat currencies in the world which are controlled by governments or wealthy people with morals that are often dangerous to everyday people, and with goals that are unclear or hidden. In MicroCash there is no goal, there is no agenda, as there is no human behind the system. Just a simple set of fixed economic rules that everyone can understand and verify themselves whenever they want. Backed by public key cryptography so there is no need to trust anyone to keep your money secure.

Features

• Instant transactions that are 100% irreversible. No need to trust a miner (proof of work) or rich person (proof of stake) to not reverse your transactions. No need to wait, at all.
• An account system that mimics existing banking accounts, making it easy to progress from existing financial system to MIcroCash. Store extra data there to help with your business or set yourself apart from the world. Give it a name so people can send payments to your name rather than a crypto address.
• Extremely efficient. Can already scale past Visa, Mastercard and PayPal transaction levels COMBINED on a normal PC
• 100% entirely new C++11 source code. Designed to be easy to understand and work on. Not derived from Bitcoin or any other crypto project. 100% free (MIT license).
• 100% independent from external libraries to ensure integrity and efficiency
• All financial rules are 100% decentralized over the P2P network, every single node has to verify every single transaction for it to count. Nothing can slip by, ever. Outside of world changing cryptography breaks - MicroCash is able to be verified to be 100% secure in regards to the MicroCash financial "state" where all the money is stored.
• Sidechain support from the start. You can add your PoW, PoS, first-comes, cryptokey, or whatever system to MicroCash easily. You don't even need to do it in C++, just hook into the node via the extremely fast API.
• HTTP server built in to the node so it can serve a wallet directly to any web browser. Access your wallet from anywhere in the world at any time, to send money instantly. No more waiting.
• Easy API access to develop businesses around. Because it is 100% secure and instant it will be extremely easy to slot into any existing payment system. No need to wait for confirms or worry about anything at all. If money comes in, then you have the money until you want to spend it, it is as simple as that. No one can take it away from you.
• Multiple P2P nodes in the same binary. Control them from the web interface. Start, stop them or change their settings. See the nodes they are connected to. All in real time. No more cryptic command line routines to remember.
• Built in account and transaction explorer. No need for external 3rd party services to see what should be standard information in a financial network. The state of the system. Look at any account you want, look at any transaction you want. But unless you own that account there is nothing you can do to it! Well, besides send money to it of course!

 

Just updated main post with a text overview too.

 

Hi invigiator, yes you can ask anything. Every node has the entire ruleset embedded in its programming. So the actual financial state of the network is decided by every node, and the state could differ in regards to a time point but not the same time point, if that makes sense. ie A node at transaction 1000 is more advanced than a node at transaction 900. The transactions are made instant by not requiring nodes to have to assign an integer order to them, so the ordering is made separate from the security rules and financial state.

I don't know how the supply is managed as that is yet to be finalized, people, like you, have to come up with the best method and I and others can help implement it. I don't know if there is any perfect solution to that.

Transaction fees can be fixed for the types of transactions required, Which is important for businesses and something I always wanted for Bitcoin. All fees, both account and transaction are destroyed currently. If you have a better solution then you are free to suggest it. Thanks for your interest!

 

Conflicting transactions are only a problem if the ordering is not synced. You have to ask yourself what is the real problem with P2P when it comes to consensus. Is it a problem with all the financial rules that matter? Or is a problem with something stupid like assigning an integer to a transaction? I see the problem like a multithreaded problem, you need to separate the syncing of ordering from the rules that matter. No one cares what number a transaction has in a ledger, they care about what it is actually doing. No one wants a tranasction to double spend, to spend funds they don't have, etc. So you separate the rules that matter from the rules that stop transactions being instant and irreversible and then you have the MC solution to that problem.

In bitcoin we have a couple nodes now that not only decide when a transaction is valid, but the order and if other transactions in the past are valid at all. This is a much worse system than one which is instant and irreversible. But of course many people have many opinions and you are free to have a different one. Thanks again for your interest.

 

I already mentioned that it is impossible to double spend. The consensus of transaction order is a separate P2P problem with MC then the P2P consensus of financial rules. If there is ever a conflict in regards to this consensus of transaction order then nodes pause and await user intervention. So in your theoretical case a node at tx 900 receives a transaction 901 that is different than the node at 1000 had. This node will then notify other nodes "I have this transaction at 901 with this hash", other nodes will jump on this as they already are past this point, grab the tx and query it.

All nodes share all transactions, including security related ones like that of incorrect transaction order. So if it were to ever occur the nodes will all quickly share such security information, pause and await intervention. The chances of this happening with MicroCash are nearly nill as there is no reward in doing so, besides downtime. The P2P consensus for transaction order therefore has to be designed for resiliency to minimize this potential downtime.

In such a paused state then the community can select a different P2P mechanism to order their transactions, it doesn't require a source update or anything like this. MicroCash is designed so that any security threat is immediately obvious and the network is paused to prevent any potential security harm. This is how it has 100% financial security, which is important for a currency. MicroCash does not promise 100% uptime, I know of no system which can promise that, but it should get close to 100% regardless.

Uptime is an interesting concept. To me something like Bitcoin is having "Downtime" any time a 10 minute block window is missed. So say a block takes 3 hours to find a hash for, this means it has had 2 hours 50 minutes of downtime, by my measure. I know other people will disagree with this assessment but as an owner of a business that is how it should be seen. If I rely on 1, 2 or 3 confirmations in Bitcoin then any time that is not 10, 20 or 30 minutes (at most) is downtime. MicroCash is an instant system, so anything over instant is downtime. MicroCash has a lot more pressure under these rules but I think if you measure downtime in this form you will see that something like MC thrashes any PoS or PoW efforts, regardless of the potential issues I raised of a network pause. People are way more accustomed to a 1-3 hour downtime every "So often" than they are of that being something that happens regularly.

 

The node at 900 doesn't reverse anything, the transaction it may receive isn't a double spend, it's a single spend, at least according to its view of the network. Within moments of receiving this transaction it will automatically detect its invalid thanks to the other nodes it is connected to. This transaction wouldn't even go around the network in a normal way, it would signify that there is a consensus issue and all the nodes would immediately update to the "State" that it can no longer rely on transaction order consensus using their existing method, so they will pause until they can.

Every "past 900" node that transaction came in contact with would not send the transaction in the normal way, it would be sent as an "illegal transaction" which would notify all the nodes to immediately halt with proof of the reason for halting. So the last transaction up until this point is still valid. Any illegal transactions ability to spread through the P2P network is made near impossible, as the majority of nodes would be up to date and hence pass it differently to alert all nodes. In terms of time this would happen within seconds, each transaction is small and easy to pass around. So when you combine the inability to spread the transaction and time taken to alert other nodes you can see that the nodes react to it very quickly.

Is it possible for nodes to be sybil'd? Yes, of course, no P2P network is immune to such attacks which is why making sure you are part of a healthy network and that the nodes are distributed in many places makes that potential threat vector limited, but not impossible. The larger the network, and the more nodes there are the harder it is to have any such attack, as you may know. But unlike proof of work and proof of stake systems pulling of a successful sybil in MicroCash is a lot harder because not every node can order transactions, so breaking into that system to then pull off a sybil attack on weak/splintered nodes would be quite a task. Sybil attacks in MicroCash can also be made to be a lot harder than the same in Bitcoin, for a few reasons that are lengthy to get into. But at no point will I say MC is sybil immune because it is impossible to be if you are in a trustless P2P system.

It is not that people will not want to do it, but attempting it requires more than you need in a pow or pos system. You don't even need to sybil in bitcoin or POW/POS if you are a miner, as you can just control the network anyhow, which makes the whole discussion a bit pointless imo.

In regards to downtime I think we have different views on what is acceptable. If non instant transactions, the risk of double spends, transaction reversals and general financial state distrust is your baseline, and then you include all the attack vectors we just mentioned that are applicable to both MC and BTC... Well, it makes a clear case for the superior option given the two, don't you think? Bitcoin is susceptible to severe downtime if enough miners leave, this has happened to many altcoins based on Bitcoin. It is a flaw in it, and the flaw is even visible today due to block variance, just on a smaller scale. Most people do not care about downtime as long as it is manageable downtime.

 

Thanks for the responds. But considering that doing a sybil on bitcoin still is an easy prank to pull. Only thing it does is delay the network and confuse nodes. Having some kind of trusted node concept (user picked ofc). would be preferable. (Like connecting to own network node and/or working with a trusted node system). Ofc its impossible to prevent sybil for now. Giving an trusted node would be ok imo

Edit: Just to be clear i'm not advocating centralized nodes. Just the option to work on your own node. (Which if you are a good actor, shouldnt produce problems. And with that elliminating the "noise" from the badactors)

//offtopic. Dude. You have paint.net. Use it.

 

Yes there are many ways to reduce likelihood, or prevent sybil. But it is impossible in a trustless system. If you do what you say, add some node you trust then you shift the burden to hoping those nodes you trust aren't involved in some big espionage.

And I'm a programmer not an artist, where are the artists to turn my junk into art!!!

 

You ask some very good question invigiator, thanks for allowing me to discuss this with you. There are two scenarios here,

1) In a normal scenario where node is connected to network with at least one good actor. All nodes, including this one will build themselves up to the latest proven point, once the illegal transaction is received, no matter at which point the node is on, the entire network will pause. As long as there is one good node you are connected to it is impossible to receive an illegal transaction.

2) The node is 100% sybil'd with bad nodes and those bad nodes have transaction ordering capability. This sybil'd node will believe the transaction story beings told by all the bad nodes, so in theory it is possible to have the main network thinking it is going fine and this one sybil'd node connected to 16+ bad nodes that have ordering transaction capability on a completely different network. All the same rures apply, so it cannot have a transaction reversed in this scenario or have funds spent that aren't spent by owners of the respective acccounts, but it can certainly have a different "financial state" then the valid one.

Once the node connected to the real network and found out it was sybil attacked AND was somehow operating upon transactions in this state it is possible it could have a financial disparity. Once joining the real network it would be able to send proof the ordering system is broken and the whole network would pause until the solution put in place. At no point is any attack able to be hidden because eventually it would connect to the real network, if anyone gets sybil'd like this, then it is reported and the network pauses.There is crypto proof of this crime that is shared among all nodes, which is another feature of MicroCash.

It is hard to see how this attack could be pulled off in the real world because you would have to attack new nodes that are catching up and/or hope they are only connected to you (you can't tell if they are or are not). If you could somehow manage to separate nodes away from all valid ones with your bad ones and that node was running in a very permissive way it is also possible for this attack vector.

All of these things can be pretty much fixed by making your node connect to as many nodes as possible, combined with a fair IPv4 and IPv6 distribution which is already part of the join code. Or even just before you go live with your business ensure you are up to date and have connected with other nodes you think are reliable. So don't connect your site until you are sure things are good, which should be how anyone runs a business or their own wallet. I found anyone who has big money involved in P2P projects knows you need to avoid being sybil'd and hopefully take steps to ensure it doesn't happen. I would hope big businesses would join themselves to each other to ensure the risk of being targeted is made even more unlikely.

I want each user to have a way to set their tolerance level when they want their node to pause to avoid the risks, which scenarios they think are safe and ones they do not. ie number of connected nodes drops below X so pause (in a DDoS to setup bad nodes valid nodes could drop out). ie If my connection to NODE X,Y,Z fails, then pause. We can set up some defaults for this but I want it all configurable as running an exchange I felt at certain times I wanted more security.

As you seem pretty educated on this if you have any solutions or ways to make (2) better I would love to hear them.

 

Yeah I had thought of allowing nodes to identify themselves by an address when they start communications. It would be good as an option, maybe, but forcing it wouldn't be right. MC is a different system than PoW or PoS so already not having an easy way that an attacker can begin ordering transactions already puts it a big step ahead of the game. But not impossible.

The important thing is what we start with will work well with the goal of security and resilience, and the global financial state is never corrupted by invalid behavior of the ordering *IF* it does get attacked somehow. MC is designed this way on purpose to put security above all else, which is why it pauses rather than just continue on and letting people get attacked with no recourse. No system will ever be perfect in every way, however with MicroCash as long as you make sure to run your node correctly you will never suffer from such a fate. I also feel like it is nearly pointless, besides griefing, to ever pull off such a thing in MicroCash because you can never weigh your chances of success. A node may have a connection to a valid node and as soon as you send that invalid transaction the entire network would shutdown. You achieve nothing, and that will always be the most likely outcome, that the network shuts down immediately, just by the odds of a node losing all connections to valid nodes. But we should always strive to be better at whatever we do and use the best systems possible for that. MC has the freedom to move forward on that aspect without touching the financials unlike other cryptos.

 

MicroCash has no concept of inputs and outputs. Just accounts. The ordering of the transactions ensures an account cannot spend more than it contains.