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

[binaryFate]

...

Genius 

[fluffypony]

...

I got the whole way through, tearing my hair out, before I realised what was happening:)

[dreamspark]

The blockchain bloat was a hot topic on IRC at the end of last week so I decided to start keeping exact blockchain size figures as the charts on monerochain.info can be misleading. I have been recording these at aroun 10:00 GMT and are as follows.

1,516,605 KB    13/7/14
1,544,024 KB    14/7/14
1,606,429 KB    15/7/14
1,628,828 KB    16/7/14
1,646,808 KB    17/7/14


As you can see the blockchain is growing at ~30 mb average a day which is fantastic news if you look back to how much bloat the dust transactions were causing on the chain so kudos to the core devs and pool devs for implementing those solutions. This current rate of growth is much more acceptable for the privacy afforded than the 10x the size of BTC's chain we were heading towards a month or two ago.

As it was mentioned again in another thread and I therefore said I would update the list I was keeping here is the blockchain growth on disk rather than the one displayed on monerochain.info which is significantly smaller than the on disk size.

1,663,092 KB  18/7/14

1,711,573 KB  21/7/14
1,727,554 KB 22/7/14
1,742,269 KB 23/7/14

This gives an average growth rate of ~16MB over the period 18/7 to 23/7 and an average of ~22.5MB for the ten day period 13/7 to 23/7.

Im sure you will all agree again that this rate of growth is perfectly acceptable for the privacy and anonymity provided by the protocol and is again a significantly slower rate of growth than the rate when the pools were sending out dust. 

[sammy007]

The blockchain bloat was a hot topic on IRC at the end of last week so I decided to start keeping exact blockchain size figures as the charts on monerochain.info can be misleading. I have been recording these at aroun 10:00 GMT and are as follows.

1,516,605 KB    13/7/14
1,544,024 KB    14/7/14
1,606,429 KB    15/7/14
1,628,828 KB    16/7/14
1,646,808 KB    17/7/14


As you can see the blockchain is growing at ~30 mb average a day which is fantastic news if you look back to how much bloat the dust transactions were causing on the chain so kudos to the core devs and pool devs for implementing those solutions. This current rate of growth is much more acceptable for the privacy afforded than the 10x the size of BTC's chain we were heading towards a month or two ago.

As it was mentioned again in another thread and I therefore said I would update the list I was keeping here is the blockchain growth on disk rather than the one displayed on monerochain.info which is significantly smaller than the on disk size.

1,663,092 KB  18/7/14

1,711,573 KB  21/7/14
1,727,554 KB 22/7/14
1,742,269 KB 23/7/14

This gives an average growth rate of ~16MB over the period 18/7 to 23/7 and an average of ~22.5MB for the ten day period 13/7 to 23/7.

Im sure you will all agree again that this rate of growth is perfectly acceptable for the privacy and anonymity provided by the protocol and is again a significantly slower rate of growth than the rate when the pools were sending out dust. 

Much better than in early days when pools didn't implement minimal payout threshold.

[smooth]

Much better than in early days when pools didn't implement minimal payout threshold.

There is no official "promise" from the development team on this, but personally I expect the on disk storage to eventually end up a lot closer to what is reported by monerochain.info, which means less than half of these numbers. Currently a lot of data is being stored multiple times on disk. Being smarter about how to do that should help a lot.

But first we need to get the database interface completed and a reference database integrated (see latest Missives for status). Then people can optimize.

[dreamspark]

Much better than in early days when pools didn't implement minimal payout threshold.

There is no official "promise" from the development team on this, but personally I expect the on disk storage to eventually end up a closer to what is reported by monerochain.info, which means less than half of these numbers. Currently a lot of data is being stored multiple times on disk. Being smarter about how to do that should help a lot.

But first we need to get the database interface completed and a reference database integrated (see latest Missives for status). Then people can optimize.

Great, if all the dublicated data can be cut out thats good news. As said I dont see the current rate of growth as anything too troubling so with the database implemented and if anyone can optimize further it can only be positive.

[sammy007]

Much better than in early days when pools didn't implement minimal payout threshold.

There is no official "promise" from the development team on this, but personally I expect the on disk storage to eventually end up a closer to what is reported by monerochain.info, which means less than half of these numbers. Currently a lot of data is being stored multiple times on disk. Being smarter about how to do that should help a lot.

But first we need to get the database interface completed and a reference database integrated (see latest Missives for status). Then people can optimize.

Great, if all the dublicated data can be cut out thats good news. As said I dont see the current rate of growth as anything too troubling so with the database implemented and if anyone can optimize further it can only be positive.

At least, if there long timeframe, it's easier to implement google snappy configurable compression level. But imo it does not matter, cos it still all in RAM.

[nopedope89]

Fees became lower on Minergate.com!

Guys, now fees for cryptonote coins are 1.5% PPS and 1% PPLNS

2-step verification

I implemented 2 step verification, so you can protect your account with both your password and your phone. To enable it go to Dashboard - > Profile

Enjoy!

[dga]

What gives is very simple:  You're wrong;

I still believe you are wrong. See below...
...

...
The math I posted applies to any algorithm that uses randomized lookups from reading and writing to a table.

The first flaw in your analysis:  Your l3scrypt seems, from what you wrote below, to use 512b (bit?  likely, if scrypt) entries.  CryptoNight uses 128 bit entries, which means that the cost of a 24 bit counter to indicate the last-modified-in round information for a particular value is still fairly significant in comparison to the original storage.

Correct if you make your hash so slow that you can't deal with DDoS attacks (which is the case for CryptoNote), the size of the 'values' table needed to walk back each path of computation to trade computation for space, becomes larger than the space to store the values normally.

Whereas in L3crypt I have 512B entries in order to make the hash fast enough and still cover 1MB of cache to keep it in L3 cache in order to defeat economies-of-scale with Tilera cpus, GPUs, and ASICs.

So agreed CryptoNote in that case (1MB/16B table with 128-bit, i.e. 16B, elements with 1M writes) defeats the dynamic lookup gap strategy, but at the cost of making the hash too slow to defeat DDoS attacks.

Good, we're getting somewhere:  You admit that 2/3rds of your entire post doesn't apply prima facie to CryptoNote.  It might, but not with the very simple approach you claimed.  I believe you're wrong about AES as well, but I don't have time to tackle that until later today.  The 128 bit entries in CryptoNote are specifically part of what I called out earlier as a design advantage in achieving that balance.

Note carefully:  I never said CryptoNote was fast.  I never said it was a *good* choice if you are worried about DoS attacks.  I said it was a good design for balancing CPU, GPU, and ASIC computation speeds.

The reason you're wrong about GPU speeds is because the accesses saturate the memory controllers and are a poor match to the row buffer structure of DRAM, also in part due to that same 128 bit random access pattern.

So please:  Stop arguing your l3scrypt-whatever-the-fish-it-is strawman and talk about *CryptoNote as it actually exists*.

[dga]

Okay but I spent considerable time designing what the CryptoNote designers were attempting to design

Actually as far as I can tell, they delivered what you claim you were attempting to design. You have delivered no work product at all. No code. No white papers. Nothing. Except maybe delivered to yourself, which does not count. It is all hot air.

At this point I would ask that you take this discussion elsewhere. There may well be (theoretical, unidentified and undemonstrated) cryptographic or other issues with Cryptonight, but that is a tiny subset of topics of general interest to the user base and potential user base of Monero. Now we have the past several pages of this thread being taken over by the discussion, and the way the last few exchanges have gone, every appearance this back-and-forth will continue for several more pages. That is inappropriate. Please stop, or just go ahead and create your own thread focused on that particular subtopic.

Ah, sorry, smooth - hadn't seen this before I posted my followup.  Will stop feeding the troll on my part.

[HardwarePal]

I am personally doing a small survey about XMR for all the people interested in completing it :


https://docs.google.com/forms/d/1JqIXkjKpcEpv6lyH6SD22f_Ny0i-rhM9bV21WcOFstw/viewform


Thanks in advance

[dreamspark]

I am personally doing a small survey about XMR for all the people interested in completing it :


https://docs.google.com/forms/d/1JqIXkjKpcEpv6lyH6SD22f_Ny0i-rhM9bV21WcOFstw/viewform


Thanks in advance

What is the survey for and what is being done with the information provided ?

[HardwarePal]

I am personally doing a small survey about XMR for all the people interested in completing it :


https://docs.google.com/forms/d/1JqIXkjKpcEpv6lyH6SD22f_Ny0i-rhM9bV21WcOFstw/viewform


Thanks in advance

What is the survey for and what is being done with the information provided ?

The first 5 questions will be posted as graphs so we have a better understanding of what type of investors we have and creating an unofficial richlist.

The paragraph text boxes will be sent to the Core dev team for fixes and understanding us better.

[r05]

I am personally doing a small survey about XMR for all the people interested in completing it :


https://docs.google.com/forms/d/1JqIXkjKpcEpv6lyH6SD22f_Ny0i-rhM9bV21WcOFstw/viewform


Thanks in advance

Just done that for you now.

[pooltobe]

Searching a place to mine XMR? 

Help us to brake some blocks & spread the hashes ! 

XMR MINING POOL >> http://xmr.poolto.be

use : stratum+tcp://xmr.poolto.be:3001

Happy Mining ! 

pool fee: 0.20% (pool) + 0.1% (node-crypto dev/xmr core dev) to support XMR ! >> JOIN US!

[digicoin]

I am personally doing a small survey about XMR for all the people interested in completing it :


https://docs.google.com/forms/d/1JqIXkjKpcEpv6lyH6SD22f_Ny0i-rhM9bV21WcOFstw/viewform


Thanks in advance

Did it

[drawingthesun]

Can I just say that Ethereum isn't really our enemy.

Ethereum cannot offer anonymity, and if they implement something like ring signatures, they will be far less efficient than a native currency such as Monero.

Ethereum is going against a bit of Bitcoin but mostly it's generating it's own market.

Correct me if you think I am wrong, I'm really interested in hearing other peoples thoughts on the matter.

[grendel25]

What's the formula to calculate time in hours to find a block?  like in btc/ltc this seems to work:

Code:

time to block in hours = ((2^32*difficulty) / hashrate)) / 60 / 60

But that doesn't work for XMR. 

[Baitty]

Can I just say that Ethereum isn't really our enemy.

Ethereum cannot offer anonymity, and if they implement something like ring signatures, they will be far less efficient than a native currency such as Monero.

Ethereum is going against a bit of Bitcoin but mostly it's generating it's own market.

Correct me if you think I am wrong, I'm really interested in hearing other peoples thoughts on the matter.

I don't think there's any threat on monero from any alt coin this is a great coin which has been proven to work and has already been established.

[Hexah]

monero devs seems to be absolutely beginners - your accusations and anger touched us, here is a result of 10 min research of your kiddy coding, concerning Payments ID and games with your kiddy coin wallet:
Second chapter of any average "Beginners in C++ guide" says that arguments can be passed to parameters either by value or by reference.
Looks like monero devs did not noticed that, when they recently read that kind of books.

Lets look at this playground:
https://github.com/monero-project/bitmonero/commit/d433a696e527a01c1cbef48495652335140f0bb2

With "Monero golden ampersand bug" made by monero devs, monero devs missed some &, wuuups:

bool validate_transfer(const std::list<wallet_rpc::transfer_destination> destinations, const std::string payment_id, std::vector<cryptonote::tx_destination_entry>& dsts, std::vector<uint8_t>& extra, epee::json_rpc::error& er);

bool wallet_rpc_server::validate_transfer(const std::list<wallet_rpc::transfer_destination> destinations, const std::string payment_id, std::vector<cryptonote::tx_destination_entry>& dsts, std::vector<uint8_t>& extra, epee::json_rpc::error& er)


Affects: Monero simplewallet since at least June 18 just lose all Payment ID data, so people can lost their money if they use your so called monero RPC "features". Again - all transfers in monero network made with JSON-RPC Payment ID, EG from Poloniex exchange to Bittrex exchange was made wrong if they use monero latest main kiddy code, or may be just lost. Qua, qua, qua ...

Users, be careful with kiddy coders.

Well this is awkward. Allmighty monero devs are not so allmighty after all. 

And there was so much marketing about it... it's not even fun, it's just sad.