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

Reading the quote "While Monero isn't made to integrate with Tor, it can be used wrapped with torsocks, if you add --p2p-bind-ip 127.0.0.1 to the bitmonerod command line." in README.md at the repo, leads me to the following questions:

- Whats the status of this TOR-support via wrapper? Is this option: fully functioning and secure to use for people with basic TOR & crypto knowledge. Or this more like an draft/proof of concept/not supported dirty hack?

- Are more Monero I2P-nodes needed?

- Are more Monero TOR-nodes needed?

- In which clearnet geographical region are new nodes needed? Any suggestions?
(Without needs test, I randomly did setup 4 nodes in Asia yesterday: Hong Kong, Kuala Lumpur, Singapore and Kota Kinabalu[MY].)
So next time, I get pocket money from my grandmother and I decide to buy more nodes, I would deploy them, where they are needed. :-)

- Bonus question: Sorry I forgot, why again was I2P once preffered over TOR to be integrated/used with Monero?
Maybe someone can remind me or point to a link, where I can read it up myself.

I browsed it but did not study it carefully. However, in many respects having to do with mining, mempools, p2p, etc., Monero works mostly the same as Bitcoin so my first impression would be that the same technique could be used if it turns out to be a win. Of course our volume is low enough that optimizing these things isn't urgent right now, but can be added later.

thanks for the candid reply. I'm happy for you guys you didnt get left out of the pump parties on Polo these last few days. Bitcoin in turmoil much?

Is this technology compatible with Monero's protocol? https://bitco.in/forum/threads/buip010-xtreme-thinblocks.774/

Fixed now. Thanks for the heads up!

We did but that was weeks ago. I'm not sure what is driving the big rise.

couldnt help noticing the price rise on Polo. Have u guys just released and new wallet or something?

No one can know for sure what will be needed in 6-9 months because it depends on network activity.

However, as general guidelines based on current and moderately increased usage:

• 1 GB of RAM seems to be close to the minimum that works well, and this probably won't increase much regardless of usage. After syncing you can probably get by with quite a bit less.
• 1 CPU core is fine, this might become an issue at a much higher usage level, but we aren't near that yet.
• 15 GB is a reasonable minimum for storage, depending on usage in the future it could be higher.
• Make sure incoming connections are enabled.
• If you have spare bandwidth consider increasing the default bandwidth limits
• If you end up with extra CPU you can always enable solo mining as a support for the network (even though you don't expect to get much from it), but don't do this if your VPS provider has limits on CPU load.

On the first page of this ANN thread the following is listed.......

Latest release: 0.9.0.0 Hydrogen Helix   

However I checked the windows 64 bit link does download 0.9.1.0 

I did not check the other links.

Shouldn't it say somewhere that there is a mandatory upgrade to 0.9.1.0?

- What is the the recommended minimum size of RAM and Swap-Partition, for running an Monero node, that now improves & strengthens the network and won't be to small/slow in 6 or 9 months?
Other Node(s) specs would be:  
- be a typical Linux VPS, with 100 Mbit or 1 GB/s speed,
- hosted at trusted & professional hosters and DataCenters with verifiable good history (of network quality, service and ethics) and best possible carriers, peerings and strategic location
[in order to get the possible networking quality, in this geographical or political region, obv. to max out benefits for the XMR network and community]

----------------

Is any virtualization solution preferred? XEN vs. OpenVZ vs. KVM vs. other vs. doesn't matter?

------------

In order to be more objective, when judging Moneros development. I am interested in things, situations, directions, decisions and results, that in your opinion: weren't perfect/could have been done better/maybe some potential wasted/resources not efficient used or surrounding conditions that changed maybe to Moneros disadvantage, etc.

From my POV, nearly everything went close to perfect. Looking at other privacy related coin projects, other coin projects in general, Moneros status in the general crypto currency scene, general crypto currency adoption and ecosystem development, the end of Bitcoins dominance & claim for sole representation (that harmed the whole crypto currency scene and even Bitcoin itself), more and more demand for privacy, anti-surveillance etc. by endusers, the clear finding, that the in Q1/Q2 2014 predicted & hyped battle of the (competing) privacy coins to replace Bitcoin, as #1 Dark Market currency, that was supposed to happen in 2015 didn't occurred (the project benefited from this switch of focus & direction). + other positive developments

Looks kinda to perfect. I don't want to badmouth anything or want to search something negative. I am really interested in objective assessments and realistic observations.
(I know I wouldn't believe myself, if someone talks about a big project like this and being so successful and flawless. Sounds fanboyish.)


----------------


Is it correct, that we have a good chance, that around June 2016 Monero will be market-ready? Meaning the software is usable, functional and tested enough, so that first end-users and vendors (outside of the Monero community) can try Monero out?
A rough date, when Monero is available for interested parties and the general public, to test, evaluate and use, would be pretty cool to know.

Some updates on https://xmr.to

• Increased the limit for large orders, up to 2 BTC (previously 1). We are considering to possibly raise more in the future, depending on demand and volume.
• Updated various things in our backend, most important and visible effect for you is that we should now have a good liquidity, reliably.
• For the privacy-minded out there that are reaching us over TOR or I2P and prefer not to enable javascript: they can now enjoy a new front-end that works even with javascript completely disabled.

Thanks dEBRUYNE. You are spoiling us

Another one here -> https://www.reddit.com/r/Monero/comments/42bv46/small_update_on_ring_ct_crypto_implementation/

For the lazy ones:

That explains it.

Compare the numbers: https://en.wikipedia.org/wiki/IOPS#Examples

Some optimization work to reduce the amount of redundant data being written to the database may help, but the main thing is that HDs are just very slow for this type of workload. I don't remember if write batching during sync was ever implemented (it is used in the import utility) but if not that may also help.

You can't parallelize read/writes on an HD, due to the head physically moving to a location to read or write it. Trying to have parallel threads/processes reading/writing would have the opposite effect: HD don't like random access in general, and it would be a major slowdown.

I'd theorize its a combination. If the blockchain can be written in parallel (which I think is true), then the whole process can take advantage of the fact that the daemon is pulling down data from multiple blocks simultaneously (which I think is true). A spinny HDD can't really do that much parallel....  (I think).

Thats a huge difference in time.  Is that just how slow those old hard drives were are all around or is there something unique about the way the blockchain is written?

Over the past 2 months, I've resynced the blockchain on:

• Intel Core Duo, 4GB RAM, 80GB 7200rpm drive - 2-3 days
• Intel Core Duo, 4GB RAM, 60GB SSD - 3-4 hours
• AMD A8, 6GB RAM, 120GB 7200rpm drive - 2-3 days
• AMD A8, 6GB RAM, 60GB SSD 3-4 hours

...so I think the HD is the bottleneck. All were on Ubuntu 14.04 64-bit, and all of the rpm drives were older repurposed drives. Maybe a new rpm drive would be better but I haven't tried. Syncing is something any coin has to do at first and if the coin has been around, it will take some time no matter what. Once it's synced, RAM, HD, and CPU use are minimal.

The hard drive is the bottleneck especially if it was small for its day, say 100 - 300 GB. I get like 2 - 4 hours on a system from 2008 with a 2 year old 2 TB 7200 rpm hard drive.