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

and I can't understand why the difficulty is so high. in fact it's not an old currency

Very complex...I can't understand it...

I cannot mining. Hope after testing and troubleshooting it will work at last!

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

Theoretically completely working pool code. yet to be completely tested though.

A request to the coin developers, please change the http timeout in simple miner to 10 seconds and make a windows 64 bit build, I desperately need it to test this

How many threads does this coin need?

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.

GOOD  GIRL!

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.

^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.

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.

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

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.

 

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

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

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

Your other suggestions seemed good.

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)?

Everything works in pool code except payment processing now. 

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.


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.


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.

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:

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.

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.