If that the case then so be it, and those questions will be answered as and when I am confident that the systems that deal with them are complete and comprehensive. This post was about anonymity and the security of the transactions themselves, not about double spending, or wallet theft or a multitude of other security related issues.
Your problem is the aggression in your pursuit of answers to these questions, which comes across as acute arrogance and a disrespectful attitude. Both of which I have no patience for.
I am neither an inexperienced developer, or full of hot air, and while I more than have the credentials and experience to back myself up, preaching about these on various forums would make me sound a complete twat, so I refrain from doing so. The proof is in the pudding so to speak, but that pudding isn't ready yet, so calling bluff on something unfinished is just childish. That not being your intention matters not, as your execution of it is what causes friction and disgruntlement.
For what its worth, puppets require puppet masters, and I don't influence supports of eMunie on what they post, they have their own minds and the opinions they express are there own.
Topic: [NEWS] eMunie: Some general news and 100% Anonymity - page 2. (Read 5382 times)
Last time I checked transmission was different to encryption. Encryption was only the part of it.
omg statements like these... How is this in any way a response to what I said? It doesn't even mean anything.
Quote
I've never attacked anything of yours, your decrits idea is not a bad one, and yet you seem to be hell bent on criticizing me and my work. I aspire to be professional at all times but tbh I'm getting quite royally fucked off with it.
Right, criticizing meaning: I asked questions in the initial thread about the security model that are unanswered to this day, and someone asked me to provide thoughts on emunie in my thread to which your puppet army took to task. And the only reason I posted in this thread, because it once again is meaningless if your security model is inept, is because puppet #1 just had to send a pm going "look, it's secure!" when this is clearly no network security model.
The major questions of emunie's viability remain unanswered, thus any proposed bells and whistles are uninteresting. There is nothing for me to criticize except the lack of detail.
Regardless of if I succeed or not, at least I'm actually attempting it instead of just blabbering on about it for 13 months.
+1
That is strange. I saw him on our forums after this post was made, but nothing here. booo.
Oh I was just double checking that the guy proposing to patent this didn't know what ECIES was a week ago.
There is also prior art, and what looks to be a much better idea than yours and that one here. Time for a rewrite again, lol. Also prior art on using ECDSA to encrypt.
I believe Dan answered your question here:
https://bitcointalksearch.org/topic/news-emunie-some-general-news-and-100-anonymity-270909
Did you have a chance to check that out?
https://bitcointalksearch.org/topic/news-emunie-some-general-news-and-100-anonymity-270909
Did you have a chance to check that out?
What does ECDSA security have to do with double spending? (Nothing.) This does not answer anything about the viability of the network's security model. It also throws out any notion of your eMugraph, as if it had any viability to begin with. Still working on that AI to determine how much money to create?
Last time I checked transmission was different to encryption. Encryption was only the part of it.
I've never attacked anything of yours, your decrits idea is not a bad one, and yet you seem to be hell bent on criticizing me and my work. I aspire to be professional at all times but tbh I'm getting quite royally fucked off with it.
Regardless of if I succeed or not, at least I'm actually attempting it instead of just blabbering on about it for 13 months.
So "Looks like key wearing problem is solved by eMunie, be it intentionally or accidentally" is VERY intentional. 
OK, OK, take no offense
Your main concerns are (as I understand your posts) anonymity and ease of use for merchants and customers; I was concerned about key wear problem. So if there was any miscommunication I'm sorry for it.No problem and no offense taken. Constructive communication is whats key.
coming out of the blue with implied theoretical attacks requires a bit of exposition, don't you think?
I don't
Whatever, it's hard to take you seriously when you bring up a bad implementation of ECDSA as evidence of a problem with ECDSA. I am always open to learning more about cryptography, but coming out of the blue with implied theoretical attacks requires a bit of exposition, don't you think?
There is no "key wear" problem with ECDSA as long as k is random
Is your opinion based on your own research?Actually, I am partially incorrect, it should be (apparently) as long as k is chosen carefully.
Piss-poor implementations of ECDSA such as the thread you linked to earlier is hardly evidence of a problem of key wearing.
Alternate cryptocurrencies are not alt.crypto There is no "key wear" problem with ECDSA as long as k is random
Is your opinion based on your own research?Actually, I am partially incorrect, it should be (apparently) as long as k is chosen carefully.
Piss-poor implementations of ECDSA such as the thread you linked to earlier is hardly evidence of a problem of key wearing.
That is strange. I saw him on our forums after this post was made, but nothing here. booo.
Oh I was just double checking that the guy proposing to patent this didn't know what ECIES was a week ago.
There is also prior art, and what looks to be a much better idea than yours and that one here. Time for a rewrite again, lol. Also prior art on using ECDSA to encrypt.
I believe Dan answered your question here:
https://bitcointalksearch.org/topic/news-emunie-some-general-news-and-100-anonymity-270909
Did you have a chance to check that out?
https://bitcointalksearch.org/topic/news-emunie-some-general-news-and-100-anonymity-270909
Did you have a chance to check that out?
What does ECDSA security have to do with double spending? (Nothing.) This does not answer anything about the viability of the network's security model. It also throws out any notion of your eMugraph, as if it had any viability to begin with. Still working on that AI to determine how much money to create?
From those links u posted it looks similar but it is not the same, also from what I can tell it looks like a lot of talk but no action. Has there been any implication on these ideas? If so please provide links.
There is no "key wear" problem with ECDSA as long as k is random
Is your opinion based on your own research?UPD: I saw an odd hint in one of http://en.wikipedia.org/wiki/Nicolas_Courtois publications that some very novel approach is being developed in this area. For me that's enough to start worry.
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...
[snip]
[snip]
Bitcoin v09 will offer significant merchant improvements including recurring payments support - http://thegenesisblock.com/significant-merchant-improvements-planned-for-bitcoin-v0-9
So "Looks like key wearing problem is solved by eMunie, be it intentionally or accidentally" is VERY intentional.
There is no "key wear" problem with ECDSA as long as k is random, so it's rather odd that you've fixed a vulnerability that doesn't exist.
That is strange. I saw him on our forums after this post was made, but nothing here. booo.
Oh I was just double checking that the guy proposing to patent this didn't know what ECIES was a week ago.
There is also prior art, and what looks to be a much better idea than yours and that one here. Time for a rewrite again, lol. Also prior art on using ECDSA to encrypt.
I believe Dan answered your question here:
https://bitcointalksearch.org/topic/news-emunie-some-general-news-and-100-anonymity-270909
Did you have a chance to check that out?
https://bitcointalksearch.org/topic/news-emunie-some-general-news-and-100-anonymity-270909
Did you have a chance to check that out?
What does ECDSA security have to do with double spending? (Nothing.) This does not answer anything about the viability of the network's security model. It also throws out any notion of your eMugraph, as if it had any viability to begin with. Still working on that AI to determine how much money to create?
So "Looks like key wearing problem is solved by eMunie, be it intentionally or accidentally" is VERY intentional.
OK, OK, take no offense
Your main concerns are (as I understand your posts) anonymity and ease of use for merchants and customers; I was concerned about key wear problem. So if there was any miscommunication I'm sorry for it.
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.
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.
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 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).
)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 
That is strange. I saw him on our forums after this post was made, but nothing here. booo.
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.
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.
Jump to: