when monero will rise in price
Tomorrow 12pm EST Tomorrow we pump m8! |
|
|
|
|
We have bounced off 122k sat thrice now, hopefully it will hold.
|
|
|
|
4 more pull requests merged today. I can taste it  In addition: If I recall correctly, fluffypony stated a while ago that they were waiting for i2p to have a stable release before it would be integrated into Monero. That, and 0.9 is well past a feature freeze state. It is being prepared for release. |
|
|
|
If I recall correctly, fluffypony stated a while ago that they were waiting for i2p to have a stable release before it would be integrated into Monero. |
|
|
|
The new binaries will really help with adoption. Some merchants would prefer not to use releases still in beta testing.
I haven't really heard any more news about the release of the new binaries coming out... Mind you, I haven't had time to frequent this board very much due to work getting insanely rediculous. It's still projected to be Summer 2016 correct? No, I expect well before that. There are already some beta binaries and there are tests going on this week to try to finalize a release candidate. Wow, that's extremely exciting! So, one could say that the release may end up hitting the shelves possibly by the end of 2015 in that case?Yes basically. That is if nothing odd happens during the test hardfork though. Who is invited to participate in the test hardfork? I think everyone is able to participate. However, I am not entirely sure, so you should check with the devs at #monero or #monero-dev |
|
|
|
The new binaries will really help with adoption. Some merchants would prefer not to use releases still in beta testing.
I haven't really heard any more news about the release of the new binaries coming out... Mind you, I haven't had time to frequent this board very much due to work getting insanely rediculous. It's still projected to be Summer 2016 correct? No, I expect well before that. There are already some beta binaries and there are tests going on this week to try to finalize a release candidate. Wow, that's extremely exciting! So, one could say that the release may end up hitting the shelves possibly by the end of 2015 in that case?Yes basically. That is if nothing odd happens during the test hardfork though. |
|
|
|
It is a major release because it includes the completed development goals, including databases and 32bit / ARM support. It also includes the blocktime fork from 1 min to 2 min and the tail emission at 0.3 XMR (1 min blocks) 0.6 XMR (two min blocks). It will also be the first official release in over 11 months.
This is a question more for Smooth, but are there any specific new developments tested by the development of Aeon that are going into the 0.9 release coming up soon? 1. The block time change that was previously done for AEON has informed the work to change Monero. 2. There was a bug fix to align the depth requirements between spending outputs and mixins (avoiding a potential privacy leak) that was done in AEON and then merged into Monero for 0.9. I don't remember any others at this moment, but it's possible I forgot something. So 0.9 will have 2 min blocks, or not yet? As I understand it, 0.9 will have the code for the 2 minute blocks, and then at some point after its released it will fork, and the new fork will have 2 minute blocks and min mixins. Regarding min mixins, read this -> https://www.reddit.com/r/Monero/comments/3n06qw/there_seems_to_be_some_confusion_around_the/. TL;DR: It will already be set to minimum when 0.9 is released, only enforced after April. In other words, everyone that uses 0.9 will already have a minimum mixin of 3. Wrt the 2 minute blocks, I think they will go "live" after that April fork. Code will be included in 0.9 though. |
|
|
|
I think there is an issue with the built in windows unzipper utility for files over 4 GB or so. I had an issue with downloading/unzipping a bootstrap for huntercoin, and it was due to trying to use windows unzipper. If the file is bigger than 4 GB, try using 7zip or something else to extract.
Are you using 0.9 beta build? There is no blockchain for it to download. You should sync from scratch (~3.5 hours for me).
Hmm... I think its in RAM the problem. Its on 100% of usage when wants to read/loading blockchain(reaching in some time) and then when starts to update I get that error for "height", file is 4.2GB. My RAM size is 3x2GB. No, I've 886. Thanks! If you are on 0.8.8.6 you probably have insufficient RAM, the current binaries are quite old and slow. Basically everyone is waiting for the new binaries, which only use around 100 MB of RAM after syncing. Which OS are you on? And are you able to compile yourself? |
|
|
|
Why do people get all hot and bothered about the possibility of Zerocoin but are lukewarm (it seems) to the reality of Monero? ELI5 please.
I think this can be attributed to the hype Zerocoin created in 2013 (if I recall correctly), many people heard about it via various news outlets. Thus, the name ZeroCoin/ZeroCash is quite familiar for most people involved in the cryptocurrency atmosphere. In contrast, Monero is relatively new and has not been "advertised" much to the extent that there are basically no articles about it on major cryptocurrency outlets (e.g. Coindesk). |
|
|
|
i am not familiar with the coin production of Monero. How many coins will be created/mined over the next years. is there a graphic of coin creation over the complete horizon like for Bitcoin?
This should help you: https://docs.google.com/spreadsheets/d/1qXi7zUSIh7F6UuSuhOryyFbHEy_LJuym3I3neAga_2s/edit?usp=sharinghttps://upload.wikimedia.org/wikipedia/en/d/db/Monero_coin_supply_and_inflation_over_time.pngFurthermore, Monero has a perpetual inflation. That is, after all the initial coins are emitted, Monero has an inflation of ~1% a year. It's actually 0.3 XMR per block (blocktime is 1 minute (will be changed to 2 soon, but rewards will stay the same, so still 0.3 per minute)). Due to this formula, percentage wise the inflation gets lower every year. Also, from the wikipedia: Slowly decreasing block reward reaching approx 18.4 million XMR in 8 years,[1] and then a "tail emission" creates a constant increase in money supply amounting to 157,788 XMR per year (mining incentive). This corresponds to an inflation rate of 0.87% around the year 2022, monotonically decreasing towards 0% asymptotically. [2]/quote] https://en.wikipedia.org/wiki/Monero_(cryptocurrency) |
|
|
|
On that site, the link to the "Monero offline wallet generator" tool is broken. That's odd, it works here. Try this one -> https://moneroaddress.org/ |
|
|
|
Wow!! How long has this been open?! Funded for more than 90% already! 8 hours approximately. Besides, I guess we should thank ArticMine for that, he donated ~12k. Big props! |
|
|
|
It took a little breather last night, but it seems like it's on again. Anyway, it's not selling that aggressively (approximately 5 XMR per minute) so I don't mind. Rather this than those large dumps. 5 XMR per minute if continuous is a pretty good clip. That's more than half of the mining rate. Agree, but it could very well be that he/she/it accumulated this earlier and is just selling off now. Furthermore, I've only seen it active twice now this week and haven't seen it active before that. |
|
|
|
It took a little breather last night, but it seems like it's on again. Anyway, it's not selling that aggressively (approximately 5 XMR per minute) so I don't mind. Rather this than those large dumps. |
|
|
|
@smooth & americanpegasus: Pruning FAQ
Q: What is pruning?
A: Pruning refers to removing unnecessary information from the blockchain once it is no longer needed.
Q: What are the advantages?
A: Pruning reduces the amount of storage needed for the blockchain. If the blockchain is loaded into RAM (which is the case in the current implementation), then it also reduces RAM usage. Finally, it also reduces the rate that these resources are consumed over time as the blockchain grows. In the current implementation, each time one new block is accepted, one old block is pruned, on average freeing up a large portion of the resources needed for the new block.
Q: How does pruning affect functionality?
A: The only inherent functional limitation of AEON's pruning is the inability to restore (also known as rescan) a wallet which was used for spending transactions. All other functionality including sending and receiving coins, mining, updating a wallet after any period of inactivity, cold storage, mining, etc. remain fully supported. There is a current limitation that after extended period of disconnection (>28 days) a node may have trouble resynchronizing with the network, and would need to be reset. This is not inherent and should be addressed later.
Q: Does pruning reduce the effectiveness of ring signatures for transaction privacy?
A: No, ring signatures and privacy are unaffected.
Q: How is pruning enabled and disabled?
A: Using the --pruning option on the daemon command line. With this option the daemon will prune the blockchain and will also switch from using the blockchain.bin file for storage to blockchain-pruned.bin. To switch an existing node into pruned mode, copy blockchain.bin to blockchain-pruned.bin before starting the daemon with --pruning. To switch pruning off, remove the --pruning option. Do not, however, copy blockchain-pruned.bin to blockchain.bin. This will not work. You will need to have an unpruned blockchain.bin file or resync unpruned from the network.
Q: How does AEON's pruning compare with Boolberry's pruning?
A: AEON prunes slightly more information from the blockchain, so the required storage is slightly smaller (given equivalent usage), though the difference is likely not particularly significant. BBR prunes the blockchain on the entire network while AEON prunes on each node individually (and only if pruning is enabled). This means that new nodes can come online faster with BBR, but those new nodes are unable to independently verify the entire blockchain. It is possible to download an unpruned BBR blockchain from a web site to independently verify it, but in that case the amount of data downloaded would be the same as AEON. It also means that every BBR node is able to serve the chain to new users but in AEON this function falls to nodes that are unpruned, also known as "archive nodes" (or alternately via a trusted bootstrap file).
Q: How does AEON's pruning compare with Bitcoin's pruning?
A: In Bitcoin 0.11, the same model of pruning is implemented as in AEON. That is, nodes prune blocks locally, after syncing from an unpruned chain and verifying the chain independently. Like AEON, Bitcoin pruned nodes can't rescan or reindex wallets. Bitcoin 0.11 does not support wallets on pruned nodes at all, so it currently has more limitations that AEON. Old Bitcoin blocks must be retrieved from unpruned archive nodes, as with AEON.
Q: What other coins implement pruning?
A: Other than Boolberry, Bitcoin, and possibly some coins which have inherited their implementation by being Bitcoin forks, no other coins implement pruning at this time.
Q: What's this about "archive nodes"? How can I run one?
A: When nodes connect to the network, they retrieve blocks from other nodes. If only blocks within the most recent 10 000 (approx. 28 days) are needed for syncing, even pruned nodes can provide them. However, in the case of nodes which are brand new (syncing from the genesis block) or which have been offline for >28 days, pruned nodes will be unable to supply the older blocks. Instead this task falls to unpruned nodes, also known as archive nodes. For the time being the project-run seed nodes will always run in unpruned mode, and others with sufficient RAM and storage space who wish to support the network are also encouraged to do so. To run an archive node, simply start the daemon in the normal manner, without the --pruning option.
Q: What are the numbers? How much does pruning reduce the amount of memory and storage needed?
A: The exact numbers will vary according to OS, compiler, etc. and also depend on the usage of the blockchain in the future. One early report from BoscoMurray stated, "RAM usage down from 4.8GB to 2.4GB and blockchain file size down from 3.2GB to 1.7GB"
Q: That doesn't seem like a big reduction. Why is the benefit not greater?
A: To explain why the reduction is not larger and understand what this means for the future, let's first review some basics of how a blockchain works.
Every time a coin is spent, a digital signature accompanies the transaction in order to show that the owner of that coin authorized spending it. Once this signature is checked, it is no longer needed. This is the largest portion of what is being pruned. In the cryptonote signature scheme (used by AEON), ring signatures used for anonymity, which means while a signature shows the coin owner authorized the transaction, unlike conventional signatures, it does not identify the specific coins being spent, and therefore does not allow tracing and analyzing the blockchain. As a side effect of this functionality, these signatures are much larger than ordinary digital signatures (a fact sometimes described as "cryptonote bloat"). Thus in AEON, pruning offers great benefit and eliminates the "cryptonote bloat".
So why is the savings not larger? Because in the early history of AEON, there was a very large number of very large transactions and many of those transactions did not using ring signatures. This happened for several reasons, including a major flaw in the early versions of cryptonote mining pool software. Thus, while the chain is relatively large, a relatively small amount of storage is saved by pruning the early transactions.
The newer transactions are a different story. The pool software flaw was fixed long ago, and most transactions now do use ring signatures. So the savings from pruning going forward should be much higher (perhaps 75-80%). Of course, since ring signatures are now being routinely used, it means that that actual anonymity of the coin in practice is greatly improved, and with pruning there is no long term storage cost (i.e. no "cryptonote bloat") for most nodes (other than archive nodes). We get the best of both worlds!
Q: What about a database or disk-based block storage? Doesn't that also reduce memory usage?
A: Storing the blockchain out-of-memory in a database or in cache files reduces memory usage but does not reduce storage usage nor reduce the rate of growth of storage usage over time. In AEON, the plan is to later support out-of-memory storage of the blockchain along with pruning, so memory usage will be further reduced, and storage usage will remain low and grow very slowly over time.
|
|
|
|
|
Show Posts
