Hi everyoneI've been quiet for some time again, eMunie takes up every waking hour as of late, but I'm very happy to report that now all the major components of the client are complete and "set in stone", I'll be releasing various documentations over the next week that will describe in a lot more detail how this elusive beast works on the inside.There have been many many questions regarding eMunie on here going back as far as June when I first announced the project, some of which I answered at the time, lots of those explanations have since become obsolete with the various iterations of the client and its changing direction since then.A primer for those that do not know what eMunie is:eMunie is a next generation crypto-currency, similar in many ways to popular first generation crypto-currencies such as BitCoin (BTC), LiteCoin (LTC) and others. eMunie adopts the root principles and objectives of these first generation crypto-currencies and expands upon them both in terms of security and useability scope.Many first generation crypto-currencies are simply copies of BitCoin with minor changes. Typically this means that the open source BitCoin program code as been used as a starting point, with modifications made to it depending on what that particular crypto-currency's goals require.This is not in any way a bad thing, but it does mean that currencies which adopt this approach, are limited by the same factors as BitCoin, and also inherit some or all of its short-comings.eMunie does not use any of the BitCoin program code, and functions in a completely different manner, sharing only the primary ideologies and end goals.eMunie provides a more secure & stable currency by a number of means.transaction information that is able to identify you is encrypted and secure, your privacy is guaranteed. The only parties able to see any identifying information is the receiver and the sender. All other parties in the system are unable to view this information and will never know that a transaction between A -> B happened.To ensure that all transactions are honest and that the system balances, a different scheme of verification is used to current implementations to verify that the spender of any currency units is authorized to do so, while at the same time keeping any identifying information regarding the spender (and receiver) a secret.Even dis-regarding the many other innovative features, this alone allows eMunie to stand above the current state of the art and provide a solution that no other crypto-currency has been able to achieve:eMunie is also packed with innovative, ground breaking features such as:All of the above features will be explained in more detail within the various documentation that I will be making available over the course of the next week or so.So, without further ado, please feel free to ask any questions you may have regarding eMunie and I will be happy to answer themNote: For reasons unknown to me, trolls seem to like eMunie (perhaps it's the mention of goats in previous threads?) and I will not tolerate any trollish behavior in this thread and will not respond to any bait. The purpose of this Q&A thread is to answer legitimate questions regarding eMunie and anything else related, not for the stroking of a troll-ish ego.

Fuserleer



Offline



Activity: 1050

Merit: 1005









LegendaryActivity: 1050Merit: 1005 Re: [eMunie] eMunie Tech & General Q&A Thread - Get Involved November 11, 2013, 06:42:46 PM #12 Quote from: Sukrim on November 11, 2013, 11:24:18 AM 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 & Ordering



The 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 Prevention



There 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-Mail



These 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. That's quite an all encompassing question and needs almost a whitepaper in itself to answerThe 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.The 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.There 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.These 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.



Web - Radix - DLT x.0Web - http://radix.global Forums - http://forum.radix.global Twitter - @radixdlt