[NEWS] eMunie: Some general news and 100% Anonymity

[Fuserleer]

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.

[1714737810]

1714737810

[1714737810]

1714737810

[1714737810]

1714737810

[1714737810]

1714737810

[1714737810]

1714737810

[1714737810]

1714737810

[smolen]

Sounds like eMunie is some unusual kind of vexel rather than cryptocurrency.
Quoting in full to preserve text for future generations, just in case

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.

[CoinHoarder]

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

[AgentME]

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.

[ilostcoins]

eMunie can potentially improve how cryptocurrency works at the most fundamental level, rather than a patch up here and there. Definitely one to watch.

[Fuserleer]

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.

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.

[smolen]

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").

UPD. Probably I was wrong comparing eMunie with vexel, but let's wait for whitepapers.

[Fuserleer]

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.

[smolen]

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.

[mrvegad]

So then all text messages sent with eMunie is also encrypted?

[smolen]

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.

[Fuserleer]

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.

So then all text messages sent with eMunie is also encrypted?

[Blazed]

Sounds pretty interesting.. I might have to give this a try when available.

[theblazehen]

Sounds pretty interesting.. I might have to give this a try when available.

Join us at forum.emunie.com

[smolen]

What a coincidence!

I have only seen this discussed in the newbies section so I thought I would open a thread here for a more technical discussion of this issue.

Several people have reported their BTC stolen and sent to https://blockchain.info/address/1HKywxiL4JziqXrzLKhmB6a74ma6kxbSDj

As you can see the address currently contains 55.82152538 stolen coins.

It has been noticed that the coins are all transferred in a few hours after a client improperly signs a transaction by reusing the same random number.  As discussed here  http://en.wikipedia.org/wiki/Elliptic_Curve_DSA the reuse of the same k value allows anyone to be able to recover the private key.

It appears that this is what may be happening.

It appears that the bug occurs in both the blockchain.info android wallet and the Andreas Schildbach Android Wallet so I suspect a bug in a crypto library or an implemention detail shared by both applications.

This has been discussed in this thread https://bitcointalk.org/index.php?topic=251743.0 with the more technical posts being these two:

https://bitcointalk.org/index.php?topic=251743.msg2890179#msg2890179
https://bitcointalk.org/index.php?topic=251743.msg2890736#msg2890736

Check out the two transactions posted here (which did lead to a theft of 0.9184236 BTC in this transaction https://blockchain.info/tx/211c135e58dc55bcce4c71dc02eae2dffc5a55387c29e8144bf1cd1e8878e52e)

@Xeno-Genesis

For you the bad transactions were
https://blockchain.info/tx/b6350f4339a59faf09bfc2a4086c2261598f46f257517ce53785145c964799bc
https://blockchain.info/tx/38fbb8a3ff718dd7c8006feb6aa9ed6add1772522781b0db95abb350a859220b

which use the same R-value in the signature.  It is strange that the same random number was generated in two transactions that are four days apart.  This doesn't fit the usual pattern. Which bitcoin client do you use?

The stealing transaction occured less then five hours after the transaction that reused the R-value.

[Fuserleer]

I think you are confusing k to mean key, it doesn't.  k is a random number that you apply to components of the key to create a signature.  The same private key can be used many times providing that k is random for each successive signing/encryption.

As per your referenced wiki doc...

CURVE    the elliptic curve field and equation used
G    elliptic curve base point, a generator of the elliptic curve with large prime order n
n    integer order of G, means that n * G = O


    Calculate e = \textrm{HASH}(m), where HASH is a cryptographic hash function, such as SHA-1.
    Let z be the L_n leftmost bits of e, where L_n is the bit length of the group order n.
    Select a random integer k from [1, n-1]. - This is what counts
    Calculate the curve point (x_1, y_1) = k * G.
    Calculate r = x_1 \pmod{n}. If r = 0, go back to step 3.
    Calculate s = k^{-1}(z + r d_A) \pmod{n}. If s = 0, go back to step 3.
    The signature is the pair (r, s).

If k is static then yes you can recover the private key.  eMunie doesn't use a static k, that would be rather foolish.

[eCoinomist]

Where is Etlase2?

Oh.. wait! ...is he busy coding Decrits? 

[billotronic]

Where is Etlase2?

Oh.. wait! ...is he busy coding Decrits? 

That is strange. I saw him on our forums after this post was made, but nothing here. booo.

[smolen]

k is a random number that you apply to components of the key to create a signature.  The same private key can be used many times providing that k is random for each successive signing/encryption.

Even proper reuse of ECDSA private key makes it less secure. Satoshi did very good work protecting Bitcoin from possible future advances in cryptography - new addresses are created whenever it is appropriate, before first (and, ideally, the last) use public key is secret, only hash of it (address) is exposed to the public. But Satoshi did not forbid intentional address reuse, thus making key reuse possible.

CURVE    the elliptic curve field and equation used
G    elliptic curve base point, a generator of the elliptic curve with large prime order n
n    integer order of G, means that n * G = O

    Calculate e = \textrm{HASH}(m), where HASH is a cryptographic hash function, such as SHA-1.
    Let z be the L_n leftmost bits of e, where L_n is the bit length of the group order n.
    Select a random integer k from [1, n-1]. - This is what counts
    Calculate the curve point (x_1, y_1) = k * G.
    Calculate r = x_1 \pmod{n}. If r = 0, go back to step 3.
    Calculate s = k^{-1}(z + r d_A) \pmod{n}. If s = 0, go back to step 3.
    The signature is the pair (r, s).

And every (r, s) pair derived from the same dA and exposed to the public means more food for hyperlinearization and SAT-solvers. (Some day those two beasts will meet together and produce fertile offspring )

Looks like key wearing problem is solved by eMunie, be it intentionally or accidentally And I certainly don't suspect you in using constant as random number generator

[Fuserleer]

That I understand.

Perhaps I need to make some particulars of the operation a little more clear.  The public key of an address is used only to encrypt the data, and "wear" of a private key in that manner I have seen no evidence of.  Even if the same "issue" is apparent, with data I would imagine it is a LOT harder to solve the private key as the data is not a fixed length or quantity or form as a hash, as the data could be anything, which adds to the entropy in that scenario.  If you have a link to anything that suggests otherwise, then I would like it read it

Signatures you are correct, using the same private many times on many signatures can open a possibility of finding that private key eventually as you have many samples to test against.

In eMunie, the signatures use "throw away" key pairs, they are used once and discarded, the private key is never stored or transmitted.  In this manner it is impossible for any situation like you describe as each transaction has a new key pair to sign signatures.

So "Looks like key wearing problem is solved by eMunie, be it intentionally or accidentally" is VERY intentional.