Topic: [NEWS] eMunie: Some general news and 100% Anonymity - page 3. (Read 5391 times)
Sounds pretty interesting.. I might have to give this a try when available.
Join us at forum.emunie.com
Sounds pretty interesting.. I might have to give this a try when available.
Yes they are encrypted with the same address keys, but messages are not stored in the block tree, they are handled by a different service withing the client.
Only transaction messages are stored in the block tree.
Only transaction messages are stored in the block tree.
So then all text messages sent with eMunie is also encrypted?
So then all text messages sent with eMunie is also encrypted?
Looks like they are. But it's really bad idea to use the blockchain to IM-style chat. Imagine that you've sent a bit frivolous message with it. Time passes and after ten years, divorce and new marriage your words are still here, waiting for Moore law and cryptography to catch up. What's worse, when your message finally gets decrypted there is a bold chance that it can be provably linked to you.
So then all text messages sent with eMunie is also encrypted?
Imagine that Bob has a subscription with John's service/product. Bill sends a payment to John, John saves address 12345 as Bill. Next month Bill sends another payment, but due to the nature of the beast, BitCoin creates a new spend address, say 56789. John gets a payment from 56789, but he has no idea who it is from unless Bill contacts him, OR, John has to call ALL his customers to find out who it is.
For subscription services (or mining pool payouts, exchange deposits etc) new unique address is generated for every payer and all payments to this address are deemed to be from the same person. But to spend coins payee have to use his private key repetitively (or hoard money at that address). And my concern is that such reuse of private key causes the key to wear out.
Indeed, you are kind of on the right track. The "throw away" key pair with the S1-S2 pair is your proof that you own those eMu from that transaction. So your actual address is never seen.
It is only in the sender and receiver data packets for records sake, so you can use the same address for receiving transactions over and over.
That address, or public key, is publicly available in the block tree, as it is needed for actually encrypting the receiver transaction data packets (public key/addr pairs are broadcast to all clients), they are also used sending encrypted messages and other services.
I had a major gripe with Bitcoin (and Litecoin and *insert alt here*) with the following use case that will IMO severly hinder mass adoption...
Imagine that Bob has a subscription with John's service/product. Bill sends a payment to John, John saves address 12345 as Bill. Next month Bill sends another payment, but due to the nature of the beast, BitCoin creates a new spend address, say 56789. John gets a payment from 56789, but he has no idea who it is from unless Bill contacts him, OR, John has to call ALL his customers to find out who it is.
Bill public, and John merchant now have extra admin to do to use/offer services, and it just wont cut it.
If BitCoin was able to use the same address for all transactions, then there wouldn't be a problem, but it can't do that, otherwise anyone could see who was sending what to where.
With eMunie, you can now meet the re-use address requirements for that exact scenario (and many others), safely and without worry.
It is only in the sender and receiver data packets for records sake, so you can use the same address for receiving transactions over and over.
That address, or public key, is publicly available in the block tree, as it is needed for actually encrypting the receiver transaction data packets (public key/addr pairs are broadcast to all clients), they are also used sending encrypted messages and other services.
I had a major gripe with Bitcoin (and Litecoin and *insert alt here*) with the following use case that will IMO severly hinder mass adoption...
Imagine that Bob has a subscription with John's service/product. Bill sends a payment to John, John saves address 12345 as Bill. Next month Bill sends another payment, but due to the nature of the beast, BitCoin creates a new spend address, say 56789. John gets a payment from 56789, but he has no idea who it is from unless Bill contacts him, OR, John has to call ALL his customers to find out who it is.
Bill public, and John merchant now have extra admin to do to use/offer services, and it just wont cut it.
If BitCoin was able to use the same address for all transactions, then there wouldn't be a problem, but it can't do that, otherwise anyone could see who was sending what to where.
With eMunie, you can now meet the re-use address requirements for that exact scenario (and many others), safely and without worry.
Which you can do, as the inputs (and thus the required S2 component) are stored in the block tree. The S2 component can only be provided by the valid receiver of those EMU's, so you can be sure that the input & outputs in question are legitimate and can be spent, without ever divulging the address.
All you need to know is that whoever is sending them, is allowed to, which this protocol can achieve. You need to know nothing about sender and receiver.
If I catched the idea correctly, every address (in Bitcoin sense of word) is covered by an alias unique for each transaction. Were addresses used once and only once, there is no edge over Bitcoin system. But for reusable addresses such aliasing reduces the load on private ECDSA key and provides some protection from bad entropy sources (google "Debian SSL fiasko").All you need to know is that whoever is sending them, is allowed to, which this protocol can achieve. You need to know nothing about sender and receiver.
UPD. Probably I was wrong comparing eMunie with vexel, but let's wait for whitepapers.
If only the recipient (and sender) can read a transaction, how can you verify that the transaction is valid and based on previous unspent transactions (that you can't read)? You then have to be able to verify those previous unspent transactions are valid by checking the previously unspent transactions they depend on too.
I can't imagine how any sort of anonymous system could work besides one that abused BIP 32 or used Zerocoin's innovations.
I can't imagine how any sort of anonymous system could work besides one that abused BIP 32 or used Zerocoin's innovations.
Which you can do, as the inputs (and thus the required S2 component) are stored in the block tree. The S2 component can only be provided by the valid receiver of those EMU's, so you can be sure that the input & outputs in question are legitimate and can be spent, without ever divulging the address.
All you need to know is that whoever is sending them, is allowed to, which this protocol can achieve. You need to know nothing about sender and receiver.
eMunie can potentially improve how cryptocurrency works at the most fundamental level, rather than a patch up here and there. Definitely one to watch.
If only the recipient (and sender) can read a transaction, how can you verify that the transaction is valid and based on previous unspent transactions (that you can't read)? You then have to be able to verify those previous unspent transactions are valid by checking the previously unspent transactions they depend on too.
I can't imagine how any sort of anonymous system could work besides one that abused BIP 32 or used Zerocoin's innovations.
I can't imagine how any sort of anonymous system could work besides one that abused BIP 32 or used Zerocoin's innovations.
Very interesting. I'm excited that there is another innovative ALT currency coming on the scene. It seems that development is moving along nicely. I wish you good luck on the development & release.
All the pump and dump/copycat coins will be worthless in comparison to something that is truly ground breaking such as eMunie.
Cheers,
Ch
All the pump and dump/copycat coins will be worthless in comparison to something that is truly ground breaking such as eMunie.
Cheers,
Ch
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.
Operation
Transactions 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.
Anonymity
From 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.
Closing
The 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.
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.
Operation
Transactions 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.
Anonymity
From 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.
Closing
The 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.
Jump to: