Author

Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 2060. (Read 4670504 times)

hero member
Activity: 794
Merit: 1000
Monero (XMR) - secure, private, untraceable
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
sr. member
Activity: 616
Merit: 251
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.

 Cry
full member
Activity: 159
Merit: 100
https://github.com/archit120/Monero-Pool

Up, messed up almost ready code. Just the payment system and a front end remains
legendary
Activity: 2968
Merit: 1198
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.

hero member
Activity: 794
Merit: 1000
Monero (XMR) - secure, private, untraceable
Awesome, GUI and an exchange!  Smiley

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://bitcointalksearch.org/topic/m.6622637) (you could add -j4 or -j8 for this compilation, because otherwise it takes forever)?
sr. member
Activity: 280
Merit: 250
Who cares?
Everything works in pool code except payment processing now.  Cheesy

full member
Activity: 159
Merit: 100
Everything works in pool code except payment processing now.  Cheesy
hero member
Activity: 518
Merit: 521
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:
Quote from: Anonymint
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.
newbie
Activity: 56
Merit: 0
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:
Quote from: Anonymint
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.
hero member
Activity: 518
Merit: 521

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.
hero member
Activity: 560
Merit: 500

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.
hero member
Activity: 518
Merit: 521
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://bitcointalksearch.org/topic/m.5518821 (read entire thread)
https://bitcointalksearch.org/topic/m.5975715
https://bitcointalksearch.org/topic/m.3973597
legendary
Activity: 2968
Merit: 1198
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.
legendary
Activity: 882
Merit: 1000
Im willing to buy MRO for 1 btc, so ill take the bet offer, please PM me
legendary
Activity: 2968
Merit: 1198
Coming up on difficulty 10 million!

I have to say with pools and GUIs and exchanges this is all getting pretty exciting!

legendary
Activity: 2968
Merit: 1198
Is this only one dev who did all this?

No. The original code code is from bytecoin and/or cryptonote (relationship between them is murky) who are or were some unknown number of developers. No one really knows, as they operate in secret. This is a non-premined fork which is a decentralized community project with several developers working on various things including the new GUI, pools, and exchanges.

newbie
Activity: 56
Merit: 0
Awesome, GUI and an exchange!  Smiley

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.
gui?

I don't know if (part of) the bounty is open for everyone, but I have created a .NET based wallet. I started trying to use the RPC API of the daemon and simplewallet, but there are some large gaps in functionality covered by the API functions.

That is why I have create a wrapper around bitmonerod.exe and simplewallet.exe (filenames configurable in config file). It works by launching the simplewallet and daemon in the background and reading output and writing output to those processes. It should be relativly save, because it uses the widly used standard simplewallet and daemon.

It's targeted at windows, although it might be possible to port to Mono.NET (I have no experience with that). It should work with any of the bytecoin forks, but I have tested it with Monero.

https://bitcointalksearch.org/topic/m.6654252



It's up for testing, not full use from what I can see
sr. member
Activity: 476
Merit: 250
What do you call a fish with no eyes? A Fsh!
Is this only one dev who did all this?
full member
Activity: 224
Merit: 100
Awesome, GUI and an exchange!  Smiley

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.
gui?
hero member
Activity: 770
Merit: 504
(っ◔◡◔)っ🍪
Monero is up for voting on this site: https://www.swaphole.com/#!voting

It's a new exchange, so the level of reliability is unknown. But take a second and vote here or anywhere else you find MRO listed for more visibility.

Be careful guys, you can still vote for Dafuq coin there which is coin stealing trojan that forced one of the exchanges to cease trading, seems Swaphole doesn't care...
Jump to: