It's been a while since I posted here about eMunie but it's news time
Before that though, there has been a number of threads recently that Ive lurked in, both with support and opposition, which is cool, free world and free speech
I decided to keep out of those threads, primarily as I was of course busy working, and secondly, I didn't feel a response to some of the challenges aired in those threads to me warranted a reply just yet.
Some of them still don't, namely the closed source nature of the project for a period of time post launch, and the "pre-mine". There are reasons for both, reasons that are justified and the decision is made...not by me, but by supporters of the project as a collective vote. These are subjects I will not comment on in this thread, so I wouldn't waste your or my time posting about them.
One thing that does come up a lot is the lack of whitepaper and specifics, which is a fair point. However, the way that I like to develop eMunie, and have so with (very large) projects in the past that have all seen great success, is with an agile methodology. Talk less, code more, that gets things done, talking does nothing more than heat up the air around you.
On a few occasions we have had an implementation almost ready, only for someone, somewhere to have a better idea v's that implementation. A member of this board in one of the threads (I forget who) called me out on that and challenged it, arguing that it was bad development practice. I think that in-fact the opposite is true, it would be bad practice to have a better implementation on paper, and continue with the inferior one.
This is the reason behind the lack of whitepaper and concrete specifics, this project has been an evolution, it is my only endeavor at present, and I have sunk a lot of time money and effort into. I am going to get the best implementation, no matter how long it takes, how much it costs, or who I piss off
That also means not wasting my time on whitepapers and specifics due to a potential better implementation being discovered that would warrant a re-write of any documentation or communication.
As of this week, a part of the system has been finalized and will not be changing as it is perfect for our needs and meets all the requirements we had in terms of anonymity and security. Thus I am prepared to disclose some more technical information regarding its operation.
So, with that said, on to the good stuff
Over the past few days, the final components of eMunie's new transaction protocol have been implemented and initially tested. The results are as expected, the protocol functions perfectly. This protocol improves drastically on the previous implemented protocol, and indeed over all other crypto-currency models currently available.
This protocol targets 2 key important requirements of any financial system, especially an online, public, distributed system such as eMunie. That is anonymity and security.
At present, existing crypto-currencies employ a pseudo anonymous protocol for transactions, whereas the sender is difficult to determine, but the receiver of the transaction isn't. Should one have knowledge of an individuals "address", it is easy to discover all incoming transactions to that address and the value. With additional work and effort, it is possible to uncover information pertaining to the senders of these transactions.
The public nature of this information could potentially leave the owner of that address open to attacks from scammers, fraudsters and other illegal activities in an event to steal that owners wallet and the funds within, especially if they hold a large balance.
Many people publish their addresses for alternate crypto-currencies on internet forums and websites, and such undesirable individuals may research that address and the funds it may hold, and target the owner of that address.
eMunie now provides a 100% secure and anonymous transaction protocol, which is able to serve all the other components of the system (POS interest, hatching (mining for the un-educated) earning, etc...), and ensure that all transaction information is safe.
The only publicly available information regarding any transaction is the value of said transaction, and the time it was sent, all other information is encrypted and secure. Information such as the sender, receivers, embedded transaction messages, and other information is private between ONLY the sender and receiver of that transaction.
OperationTransactions are now composed of multiple, separate components, namely:
Transaction header containing total transaction value
(TV), transaction time
(T) and transaction signature
(TS) Transaction outputs containing receiver data
(RD), sender data
(SD), output value
(OV) and transaction secret pt.1
(S1) Transaction data packet which contains information regarding the sender, receiver, user message, transaction secret
(S2), and transaction signature key
(TSK).
Transaction input containing source unspent transaction
(UT), transaction secret
(S2)We have developed a ECDSA/ECIES hybrid that allows both EC algorithms to use the same key pair without compromising security of either algorithm, which are then used to encrypt the transaction data packets, and sign the transaction signature.
Upon sending a transaction, the sender will provide a list of unspent eMu that are able to honor the outgoing transaction. With this list (known as transaction inputs), the corresponding
(S2) and
(TSK) for those unspent eMu , which are available in the Receiver Transaction Data packets of those transaction inputs, are populated into
(S2) of the relevant transaction input.
Transaction Data packets are encrypted with the receivers public ECC key (the sender has the same data encrypted with theirs) embedded in these transactions. Only the receiver and sender can decrypt this information and only the receiver can spend. By ensuring that only the receiver can access and use the
(S2) and
(TSK), it can be proven that these eMu now belong to them.
Transaction outputs are then created to the new receiver of the eMu being spent, sender data and receiver data are created and encrypted with the sender and receivers public ECC keys.
An
(S1) - (S2) pair is created, and stored in the transaction output
(S1) and the Transaction Data packets
(S2). "Throwaway" key pairs are created, one is used to sign the transaction
(TS) and the public key is placed in
(TSK) for the receivers.
Upon a hatcher receiving this transaction, it is able to verify the unspent transactions are not modified by checking the transaction signature
(TS) against the provided
(TSK) and that the spender is allowed to spend by matching the one way mathematical function
(S1) to
(S2).
Save for a general ECC exploit and breach, or the senders keys being stolen, it can be assumed that the sender is permitted and is indeed the owner of these eMu and that they can be spent, as no other party would have access to the required
(TSK) and
(S2) values.
AnonymityFrom the above, you may have noticed that at no point is the receiver and sender eMu address publicly available. It is stored in the Transaction Data packets, but these are encrypted and can only be decrypted by the sender and receiver of that transaction alone.
ECIES (the encryption algorithm used) is strong and currently unbroken (and will likely be for many many years), so it is at very small odds that a 3rd party could crack, and view this information.
Clients will receive a record of all transactions in the network, and will attempt to decrypt them. If that decryption is a success, then the transaction is for that client, if it fails then it is not and there is no way to see the contents of that transaction other than the publicly available data.
ClosingThe above is a short, but concise description of the fundamentals of the system and protocol now in use. Some elements have been omitted, as we may want to pursue patent applications at a future date for these particular elements. However, the omission of them does not in any way dilute the description of the protocol operation above.
As you can see, eMunie is 100% anonymous in the block tree / transactions and is secure.