[XMR] Monero - A secure, private, untraceable cryptocurrency

[Skatebird]

Im willing to buy MRO for 1 btc, so ill take the bet offer, please PM me

[smooth]

Im willing to buy MRO for 1 btc, so ill take the bet offer, please PM me

Best offer is about 1000 on the trading thread. See original post on this thread for the link.

[AnonyMint]

Zerocash will be announced soon (May 18 in Oakland? but open source may not be ready then?).

Here is a synopsis of the tradeoffs compared to CyptoNote:

1. Zerocash hides everything, even the money supply so if the master key was compromised or if the highly complex bleeding edge crypto is cracked, no one will know.

2. They will claim to generate the master key at a ceremony or devise a way to compute in parts, but nothing they can do will insure it isn't compromised. CPUs even have special firmware that allows the NSA to reprogram them remotely, and even computation can be intercepted wireless with RF signals. Whereas we have to place all trust in a single party with Zerocash, with CN the trusted parties are changing on each transaction. Compromising the master key doesn't compromise the anonymity, but does compromise the money supply which could be expanded invisibly. Cracking the highly complex bleeding edge crypto which has not been sufficiently vetted over years, could compromise the anonymity ex post facto (it is all on the block chain).

3. Both CN and Zerocash use a form of cryptography which is not immune to quantum computation attack, if that becomes a reality in the future.

4. Zerocash transactions add up to 3 minutes of additional transaction delay which is much worse than Zerocoin. Zerocash (full node computation and block chain) resource requirements are centralizing but much improved over Zerocoin.

5. Zerocash hides everything so it is not necessary to obscure your IP address.



Thus on balance I prefer CN, but I like to see it altered to use a quantum computer resistant algorithm. And then we need to add IP address obfuscation as well that is superior to Tor and I2P.

Darkcoin (CoinJoin innovation) is really not at the level of the two above. You can review my comments in the Darkcoin thread to see why.

Zerocash

On further analysis, sending a transaction to Zerocash without reliable obfuscation of your IP address, means the NSA and other national security agencies know you are transacting even though they don't know the amount nor payee.

But we know the NSA is sharing data now with G20 tax authorities (I have a citation for this), thus the tax authorities can demand you provide the details of the transaction.

Thus Zerocash's anonymity is useless (or at least very risky) against the coming wave of confiscation and taxation, without something more reliable than Tor and I2P for obfuscating the IP address. Tor and I2P being low-latency Chaum mix-nets are subject to timing attacks by a global adversary such as the NSA, as well the Tor servers are likely honeypots (Q: who has a motivation to provide all that traffic for free? A: the NSA). I have citations for these statements.

CryptoNote / Monero et al

CryptoNote's one-time ring signature as a way of obfuscating who is the payer (the spender), is optional and can only be used when there are other payees who have matching input amounts. In other words, it can't do any obfuscation for you on spending unless there are other coins that have the same balance as yours.

That very infrequent opportunity for use is coupled with constant use of elliptical curve cryptography which is known to be broken under quantum computing, as well is suspect to broken by the NSA[1] or could be broken since it is number theoretic public key cryptography.

And the use of one-time ring signatures mucks up the pruning of the block chain of spent addresses. There is a tweak to improve this over the current CryptoNote (one of the tweaks I alluded to upthread).

Bottom line is most of your anonymity will come from obfuscating your IP address with something more reliable than Tor and I2P, not from the block chain mixing of CryptoNote or Zerocash/coin, i.e. if your IP is correlated to your identity, then the one-time ring signature doesn't obscure your identity when you spend.

The case where the one-time ring signature is really useful is a transaction with multiple inputs wherein the spender is merging his coins, thus enabling tracing of those coins to the same entity (the current spender). And it is very unfortunate the one-time ring signature is optional in this case, because it is the identity of the upchain spenders who suffer from this action by the current spender, thus the motivation is not there.

So we can see as it is currently structured, CryptoNote doesn't really support anonymity much.

Sorry to blow holes in your enthusiasm. Reality sucks if you haven't taken the time to do some serious work before launching.

Note that the use of a separate payee address for each transaction is a very useful strategy. This is a positive aspect of CryptoNote that adds anonymity, but again it is not so effective without reliable IP obfuscation, as the payee will reveal himself on spending.

[1] http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters
https://www.schneier.com/essay-446.html
https://www.schneier.com/blog/archives/2013/11/elliptic_curve.html#c2200076
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1676105
https://bitcointalk.org/index.php?topic=500994.msg5518821#msg5518821 (read entire thread)
https://bitcointalk.org/index.php?topic=548418.msg5975715#msg5975715
https://bitcointalk.org/index.php?topic=240410.msg3973597#msg3973597

[eizh]

CryptoNote / Monero et al

CryptoNote's one-time ring signature as a way of obfuscating who is the payer (the spender), is optional and can only be used when there are other payees who have the inputs amounts. In other words, it can't do any obfuscation for you on spending unless there are other coins that have the same balance as yours.

That very infrequent opportunity for use is coupled with constant use of elliptical curve cryptography which is known to be broken under quantum computing, as well is suspect to broken by the NSA or could be broken since it is number theoretic public key cryptography.

This is actually pretty easy to solve and CryptoNote already implements it: every transaction is broken up. There will always be outputs in the blockchain matching the broken-down components. Unlike CoinJoin, this is done without any participation from anyone else. The other matching amounts are not being spent at the same time; in fact they can be used as many times as needed as an ambiguity factor without actually being spent. This means the opportunity to use ring signatures isn't infrequent at all -- you can send any amount you want and it will be appropriately matched and mixed. (See section 4.5 in the white paper.)

No comment on the NSA/quantum resistance/etc.

[AnonyMint]

CryptoNote / Monero et al

CryptoNote's one-time ring signature as a way of obfuscating who is the payer (the spender), is optional and can only be used when there are other payees who have the inputs amounts. In other words, it can't do any obfuscation for you on spending unless there are other coins that have the same balance as yours.

That very infrequent opportunity for use is coupled with constant use of elliptical curve cryptography which is known to be broken under quantum computing, as well is suspect to broken by the NSA or could be broken since it is number theoretic public key cryptography.

This is actually pretty easy to solve and CryptoNote already implements it: every transaction is broken up. There will always be outputs in the blockchain matching the broken-down components. Unlike CoinJoin, this is done without any participation from anyone else. The other matching amounts are not being spent at the same time; in fact they can be used as many times as needed as an ambiguity factor without actually being spent. This means the opportunity to use ring signatures isn't infrequent at all -- you can send any amount you want and it will be appropriately matched and mixed. (See section 4.5 in the white paper.)

You haven't addressed my point that eliminates the ability to prune the block chain, because you will never know which outputs have been spent.

Automatically (is this enforced or optional per wallet?) breaking the transaction outputs into constant units, e.g. 1 coin, 0.5 coin, 0.25 coin etc, will radically bloat the block chain. The ring signatures are going to be huge if you need to obfuscate among say for example 256 payers (1/256 probability of being non-anonymous) each for several inputs, e.g. for 1.76 MRO spend 1 MRO, 0.5 MRO, 0.25 MRO, 0.01 MRO, as well as payee addresses for each of those fractional amounts.

And it won't solve the problem unless the smallest of those enforced fractional amounts match up with the fractional remainder of your transaction, which implies radical block chain bloat.

All of that waste, and still if your IP is not obfuscated you lose anonymity.

Whereas, if your IP address is obfuscated, then you don't need all that waste above (and don't incur the risk of relying on elliptical signatures being compromised ANY TIME IN THE FUTURE DECADES breaking your historic anonymity on the block chain).

And with IP address obfuscation your anonymity is assured regardless what happens on the block chain tracing.

However it might still be an improvement to enforce one-time ring signatures only when merging balances, i.e. multiple inputs to a transaction. But the issue of partitioning transactions to fixed fractional amounts and block chain bloat has to be weighed.

If you think that bloating the block chain is irrelevant then I remind you that two Bitcoin pools control more than 50% of the network, so if the government takes over these pools (even insidiously), they can defeat you (in numerous ways, e.g. they can help correlate your IP address by controlling the destination and source of your transaction sends and mining awards respectively).

It already takes hours to days to download the Bitcoin block chain, and you are proposing to increase that by orders-of-magnitude.

[Keyboard-Mash]

TY for the intense discussion, the lengths that you go to in order to explain yourself are what keeps me interested.

I don't think anyone here necessarily has had their enthusiasm blown out though, it seems to me more of something that can be taken on/integrated in the future - a challenge perhaps. I'm probably just at a very low technical level with what you're discussing though, but who knows?

From what little I'm familiar with though, wouldn't something like ip-obfuscation be more exclusive of the currency protocol itself and have more to do with data is transferred through an IP? At least, if it were to surface in the world, I would imagine it to be aimed at something much more main-stream than a cryptocurrency. Like an email system or some other sort of messaging system would seem a much more valid proof of concept, rather than having it surface in a cryptocurrency for the first time.


edit:

Automatically (is this enforced or optional per wallet?) breaking the transaction outputs into constant units, e.g. 1 coin, 0.5 coin, 0.25 coin etc, will radically bloat the block chain. The ring signatures are going to be huge if you need to obfuscate among say for example 256 payers (1/256 probability of being non-anonymous) each for several inputs, as well as payee addresses for each of those fractional amounts.

For a transaction of 1234.567800000000, the transaction is broken down into parts 1000,200,30,4,.5,.06,.07,.008 . I have asked about the bloat on the chain before, and the consensus was that with the visible competition enforcing a 10% tax on mining to afford some privacy, then the storage space used to hold the blockchain would be a much less cost. I would like to know much more about this though, because the blockchain is noticeably larger in this protocol by a lot.

[AnonyMint]

From what little I'm familiar with though, wouldn't something like ip-obfuscation be more exclusive of the currency protocol itself and have more to do with data is transferred through an IP? At least, if it were to surface in the world, I would imagine it to be aimed at something much more main-stream than a cryptocurrency. Like an email system or some other sort of messaging system would seem a much more valid proof of concept, rather than having it surface in a cryptocurrency for the first time.

Yeah IP obfuscation could be more generally applicable to internet activities. That is why Tor and I2P exist. Unfortunately they may not be that perfect. Let's pull a guesstimate out of our arse that they are anonymous 80% of the time to a global adversary and thus to tax authorities and governments. That means every 5th of your transactions is not.

edit:

Automatically (is this enforced or optional per wallet?) breaking the transaction outputs into constant units, e.g. 1 coin, 0.5 coin, 0.25 coin etc, will radically bloat the block chain. The ring signatures are going to be huge if you need to obfuscate among say for example 256 payers (1/256 probability of being non-anonymous) each for several inputs, as well as payee addresses for each of those fractional amounts.

For a transaction of 1234.567800000000, the transaction is broken down into parts 1000,200,30,4,.5,.06,.07,.008 .

Everyone has to agree on the fractional amounts, so they can't be arbitrarily chosen as you have shown.

Rather with a power-of-2 standard (I'm a programmer so I can write the first 20 entries in following list without a calculator):

0.0001
0.0002
0.0004
0.0008
0.0016
0.0032
0.0064
0.0128
0.0256
0.0512
0.1024
0.2048
0.4096
0.8192
1.6384
3.2768
6.5536
13.1072
26.2144
52.4288
104.8576
209.7152
419.4304
838.8608

The break down would be 1234.5678 = 838.8608 + 209.7152 + 104.8576 + 52.4288 + 26.2144 + 1.6384 + 0.8192 + 0.0256 + 0.0064 + 0.0008 + 0.0004 + 0.0002.

I have asked about the bloat on the chain before, and the consensus was that with the visible competition enforcing a 10% tax on mining to afford some privacy, then the storage space used to hold the blockchain would be a much less cost. I would like to know much more about this though, because the blockchain is noticeably larger in this protocol by a lot.

The issue is not only the cost of the storage. There is the download speed also. And other complex factors. A tax is probably also going to have Tragedy of the Commons effects, as I explained in my numerous discussions of why transaction fees will never work for Bitcoin in the long-run. There are other articles out now about these by others. Such discussion will take us off on tangents I don't feel like having right now.

[archit]

Everything works in pool code except payment processing now. 

[blaaaaacksuit]

Everything works in pool code except payment processing now. 

[equipoise]

Awesome, GUI and an exchange!  

I was able to compile Monero with Intel C++ Compiler for linux, but got no improvement for 2nd generation optimizations. I'm going to test compiling with different settings soon.

Did you tried with SSE3 (/QxSSE3)? Did you turn on all Optimization and Optimization[intell C++ 14.0] options (screenshots here: https://www.dropbox.com/s/5l3t5gysk4uhu7n/screenshots_intel_options.rar). Did you used at least value 8 for "loop unrolling"? Did you removed the unneeded divisions in the slow_hash function:
add:
uint8_t temp_i_max = MEMORY / INIT_SIZE_BYTE;
at the beginning of the function,
and then replace in TWO places:
for (i = 0; i < MEMORY / INIT_SIZE_BYTE; i++)
with:
for (i = 0; i < temp_i_max; i++)
Did you also compiled boost with the Intel compiler for Pentium M processor (SSE3) (see here: https://bitcointalk.org/index.php?topic=583449.msg6622637#msg6622637) (you could add -j4 or -j8 for this compilation, because otherwise it takes forever)?

[smooth]

add:
uint8_t temp_i_max = MEMORY / INIT_SIZE_BYTE;
at the beginning of the function,
and then replace in TWO places:
for (i = 0; i < MEMORY / INIT_SIZE_BYTE; i++)
with:
for (i = 0; i < temp_i_max; i++)

That won't matter because because this is a constant expression.

Your other suggestions seemed good.

[archit]

https://github.com/archit120/Monero-Pool

Up, messed up almost ready code. Just the payment system and a front end remains

[skybot13x]

Will be to late once these manipulators dump and you all waste your time.


Seriously I was a main supporter til I saw the truth.

 

[equipoise]

add:
uint8_t temp_i_max = MEMORY / INIT_SIZE_BYTE;
at the beginning of the function,
and then replace in TWO places:
for (i = 0; i < MEMORY / INIT_SIZE_BYTE; i++)
with:
for (i = 0; i < temp_i_max; i++)

That won't matter because because this is a constant expression.

Your other suggestions seemed good.

An optimizing compiler should do it by itself, but that's not always the case (sometimes the compiler is just not doing what it should do - it prefers another optimization instead and don't spot this optimization). Someone reported on this thread, that he had better performance in linux compile when removed the divisions. I've had many examples when doing this manually gave a speed boost. I've also had examples with C, where using:

if (a != b)
  do something
else
  do other

Is 30% faster (yes, 30%!) than

if (a == b)
  do other
else
  do something

[smooth]

add:
uint8_t temp_i_max = MEMORY / INIT_SIZE_BYTE;
at the beginning of the function,
and then replace in TWO places:
for (i = 0; i < MEMORY / INIT_SIZE_BYTE; i++)
with:
for (i = 0; i < temp_i_max; i++)

That won't matter because because this is a constant expression.

Your other suggestions seemed good.

An optimizing compiler should do it by itself, but that's not always the case (sometimes the compiler is just not doing what it should do - it prefers another optimization instead and don't spot this optimization). Someone reported on this thread, that he had better performance in linux compile when removed the divisions. I've had many examples when doing this manually gave a speed boost. I've also had examples with C, where using:

if (a != b)
  do something
else
  do other

Is 30% faster (yes, 30%!) than

if (a == b)
  do other
else
  do something

This is true but constant expressions (where every part of the expression is a compile-time constant) are part of the language, so it is less likely the compiler won't get them right (and if it doesn't it is likely a bug). This is subtly different from cases where the expression is logically a constant and can get pulled out of the loop but not syntactically at compile time. In those cases sometimes the compiler may miss it or there may be something subtle like aliasing that make the optimization impossible for the compiler as the code is written (in which case as you say modifying it may help). But that's not the case here.

[equipoise]

^Yes, it'll be very strange if the compiler don't optimize it, but someone reported here, that this made about 4-5 percent of a difference (23+ instead of 22) on a linux compile with GCC.
EDIT: Not tested.

[smooth]

Awesome, GUI and an exchange!  

I was able to compile Monero with Intel C++ Compiler for linux, but got no improvement for 2nd generation optimizations. I'm going to test compiling with different settings soon.

Did you tried with SSE3 (/QxSSE3)? Did you turn on all Optimization and Optimization[intell C++ 14.0] options (screenshots here: https://www.dropbox.com/s/5l3t5gysk4uhu7n/screenshots_intel_options.rar). Did you used at least value 8 for "loop unrolling"? Did you removed the unneeded divisions in the slow_hash function:
add:
uint8_t temp_i_max = MEMORY / INIT_SIZE_BYTE;
at the beginning of the function,
and then replace in TWO places:
for (i = 0; i < MEMORY / INIT_SIZE_BYTE; i++)
with:
for (i = 0; i < temp_i_max; i++)
Did you also compiled boost with the Intel compiler for Pentium M processor (SSE3) (see here: https://bitcointalk.org/index.php?topic=583449.msg6622637#msg6622637) (you could add -j4 or -j8 for this compilation, because otherwise it takes forever)?

Actually this code looks wrong. unit8_t is only 8 bits.  MEMORY / INIT_SIZE_BYTE is 8192. Assuming this actually compiles, which I think it does (I don't remember the rules on these truncations but it should at least give a warning I think) temp_i_max would be 0. So this may be faster because it has changed (broken) the algorithm. Won't work.

[JavenJay]

GOOD  GIRL!

[equipoise]

2^Good spot.
Edit: That's why my build was 3 times faster and that's why it was not working - I broke the hash function as someone spotted earlier It's working now, but no improvements on the hash speed. I'm sorry guys - all those uint8_t there made me think it's uint8_t.

[hccwin]

How many threads does this coin need?