How do you ensure global transaction ordering and double spend prevention? Centralization (PayPal style), PoW, PoS, consensus (Ripple style) or something different?
Why is chat, mail and IMing part of your financial trading software, does it not increase attack surface? How does the benefit outweigh this cost?
That's quite an all encompassing question and needs almost a whitepaper in itself to answer
The paper is currently being written and I hope to have that finished next week. However this being a forum post and not really the place to go into huge detail, I'll point out the major aspects that provide information relevant to your question and save a little on the detail.
Until then if you have any more specific queries related to the following, please do send me a PM here or over on the eMunie forums and I'll converse with you on them until a time when I have the paper published then I can link you to that.
Ledger & OrderingThe transaction ledger at the heart of eMunie is not a single chain like with BitCoin and other crypto-currencies of the moment. eMunie adopts more of a tree style ledger where many branches of transactions can exist and co-reference transactions living on other branches.
Ultimately the system does attempt use the most trusted branch for new transactions, that trust is determined from the age of the inputs that make the transactions, how many transaction iterations they have been through, and also the trust of the Hatcher that verified them.
There are times when the most trusted branch can not be used, specifically when that branch has recently had a new transaction appended to it, that branch then has to fulfil a certain maturity time (which assists in the double spend that I will explain shortly).
When the most trusted branch in the system is undergoing this maturity time, the next most trusted branch is used (and so on), so at any one time, there might be a number of high trust branches in the system.
Taking the above into consideration, global transaction ordering is almost "automatic" via the trust mechanisms in place and is also driven by the verification methods used to ensure that transactions are valid and not double-spent. Which leads me neatly onto how double spends are prevented, detected and cured.
Transaction Verification & Double Spend PreventionThere are a number of policies in place that deal with preventing potential double spend attacks in the eMunie network, the main line of defence being the Hatchers themselves. Hatchers serve to verify that transactions placed with them are indeed fund-able and do not violate the balance of the system via double-spends or other fraudulent activities.
When a transaction is itself created and requires verification, the dependency transactions that it requires are included in the verification instruction. This is to ensure that a Hatcher that may be behind with it's copy of the ledger doesn't agree to clear a transaction that it may not have all the dependency information for and that only Hatchers that have all the required dependencies to verify that transaction correctly respond to the call for a Hatcher from the requesting client.
Once a number of Hatchers have responded, the client performs a crude check to ensure that these Hatchers are indeed in sync, selects one randomly from the list of respondents, and transmits the transaction to that Hatcher for verification. The client also broadcasts to other nodes it is connected to about the transaction verification event, and also to any Seeders that is connected to (there will always be at least 1 Seeder connected).
Nodes identified as a Hatcher receive a constant stream of these transaction verification event notifications from other Hatchers and Seeders as a priority over other traffic in the network to ensure that all Hatcher nodes are as up to date as possible at all times.
Average transit times for notifications about a transaction verification happening somewhere in the network is between 4-5 seconds, longer transit times can of course happen, but that is not really of a concern due to the following.
Hatchers "hold" transactions they have been selected to process until it itself receives that transaction verification notification from a Seeder and another Hatcher, this ensures that the notification is moving around the network as it should, and provides some assurance that other verifying nodes in the system now know about it and have not called "foul play" on that transaction.
Unlike other crypto-currencies that are open-loop, with no inter-communication possible between "miners", eMunie's verification model is very much closed-loop.
Because Hatchers are identifiable from other node types in the network, it is very easy for them to communicate with each other specifically, passing information between themselves regarding transactions that they are processing. With this closed-loop communication between Hatchers being possible, and because transactions are verified by one hatcher only and not all nodes in the system, it is possible for one Hatcher to respond to another informing it that the transaction it is about to process is using an input that it also has a transaction attempting to use.
The two Hatchers can then abort verifying that transaction and broadcast to other Hatchers that the transactions they were working on were in-fact a double spend attempt, provide details about the attempted double spend and generate a failure response to the requesting client that the transaction has failed.
The selected Hatcher performs verification of the transaction by validating that the inputs presented are in-fact spendable by the party trying to spend them, and checking against the various notifications being received about transaction verification events happening in other places in the network that these inputs have not already been spent.
If all is well, the transaction is then broadcast to the network with the verifying Hatcher's signature, and all nodes perform a more lightweight verification against the ledger data that they have and include it (assuming it passes these checks).
In the previous section I mentioned about transaction maturity and this comes into play at this point. Prior to a transaction being broadcast to the network, a maturity time is calculated for that transaction. Some transaction may have zero maturity time, others may have longer maturity times and depends on a set of circumstances. All nodes in the network are able to calculate this same maturity time, and it not persisted with the transaction.
The major determining factors for this maturity time are the age of the transaction inputs used, the trust of the transactions they are within, the trust of the Hatchers that verified them and if any issues prior with these inputs have been discovered (double spend attempt).
These transactions can not be spent until the maturity time has expired, and as a result, no further transactions can be chained to it, or onto the branch where it resides. This allows other Hatchers in the system of the same or higher trust rating to the Hatcher that verified the transaction to perform a "2nd pass" verification on transactions with these maturity times set to ensure that the transactions are indeed good.
If any Hatcher finds that the transaction is indeed a candidate for "foul play", then a system broadcast can be dispatched and all nodes in the system can then remove that transaction from its ledger.
Additionally, should any regular nodes discover that a transaction in its ledger is attempting fraud, that node is able to report that event to a Hatcher that will either resolve the fraudulent activity itself, or can relay that discovery to a Hatcher with sufficient trust.
There are other factors in play to ensure Double Spend prevention, but they are more minor than the policies described in the above section and will be covered in the white paper.
Chat, IM & e-MailThese services run independently from the transaction service at the core, so attacking them will not yield any exploitable holes.
The system is designed to be very modular, with services being able to interact with others and make use of whatever features they have visible for use outside of their own domain.
For example, it is possible from the chat service to request a transaction be made to a particular user of a chat room that you may be conversing with, but that request has to go through the exact same channels as sending a transaction from the main client GUI, or from the available command API set for headless clients and remote stations, and is restricted by the same set of rules.
Should an attacker be successful in disrupting the e-Mail service, the transaction service and the entire network as a whole would continue as if nothing had happened. Only the users of e-Mail at the time would see any problems.
