binaryFate
Legendary
Offline
Activity: 1512
Merit: 1012
Still wild and free
|
|
July 23, 2014, 09:38:22 AM |
|
...
Genius
|
Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. This makes Monero a better candidate to deserve the term "digital cash".
|
|
|
fluffypony
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
July 23, 2014, 09:48:35 AM |
|
...
I got the whole way through, tearing my hair out, before I realised what was happening:)
|
|
|
|
dreamspark
|
|
July 23, 2014, 10:01:50 AM |
|
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
Legendary
Offline
Activity: 1904
Merit: 1003
|
|
July 23, 2014, 10:11:44 AM |
|
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
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
July 23, 2014, 10:20:09 AM |
|
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
|
|
July 23, 2014, 10:23:11 AM |
|
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
Legendary
Offline
Activity: 1904
Merit: 1003
|
|
July 23, 2014, 10:38:22 AM |
|
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
Legendary
Offline
Activity: 1078
Merit: 1059
FROSTING
|
|
July 23, 2014, 11:14:14 AM |
|
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
|
|
July 23, 2014, 11:30:59 AM |
|
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
|
|
July 23, 2014, 11:39:09 AM |
|
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.
|
|
|
|
|
dreamspark
|
|
July 23, 2014, 12:28:48 PM |
|
What is the survey for and what is being done with the information provided ?
|
|
|
|
HardwarePal
|
|
July 23, 2014, 12:34:54 PM |
|
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
Full Member
Offline
Activity: 193
Merit: 100
test cryptocoin please ignore
|
|
July 23, 2014, 12:59:42 PM |
|
Just done that for you now.
|
BTC: 18tS6E9FRnXuh4JitAJykm6YRtJRSkP6jq XMR: 46BzjaUU1fyfFJ2b9vvg9RXUsw3XQtkaoc7cRkzYxMre69GtCaX6jg3Luc4B6ABHAaBmZNpJ4zzmAiX deGsCiXJJMniDbWE
|
|
|
pooltobe
Member
Offline
Activity: 73
Merit: 10
|
|
July 23, 2014, 01:38:37 PM |
|
Searching a place to mine XMR?
Help us to brake some blocks & spread the hashes ! XMR MINING POOL >> http://xmr.poolto.beuse : 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
Legendary
Offline
Activity: 1106
Merit: 1000
|
|
July 23, 2014, 01:39:52 PM |
|
|
|
|
|
drawingthesun
Legendary
Offline
Activity: 1176
Merit: 1015
|
|
July 23, 2014, 02:20:47 PM |
|
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
Legendary
Offline
Activity: 2296
Merit: 1031
|
|
July 23, 2014, 02:22:20 PM |
|
What's the formula to calculate time in hours to find a block? like in btc/ltc this seems to work: time to block in hours = ((2^32*difficulty) / hashrate)) / 60 / 60 But that doesn't work for XMR.
|
|
|
|
Baitty
|
|
July 23, 2014, 02:23:00 PM |
|
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.
|
Currently held as collateral by monbux
|
|
|
Hexah
|
|
July 23, 2014, 03:06:32 PM |
|
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/d433a696e527a01c1cbef48495652335140f0bb2With "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.
|
|
|
|
|