Author

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

legendary
Activity: 1276
Merit: 1001
Trying to sync the newest bitmonerod on a new VPS, it keeps crashing after this point:

Code:
2015-Dec-01 00:26:43.936098 [P2P9]LMDB Mapsize increased.  Old: 1024MiB, New: 2048MiB

Is there anything I can do to get past this?

Join IRC please. I'd like to get to the bottom of this, as I've seen it reported before.
legendary
Activity: 1610
Merit: 1004
Trying to sync the newest bitmonerod on a new VPS, it keeps crashing after this point:

Code:
2015-Dec-01 00:26:43.936098 [P2P9]LMDB Mapsize increased.  Old: 1024MiB, New: 2048MiB

Is there anything I can do to get past this?

edit: any by crashing i mean the entire server crashes, I have to reboot the VPS and then delete the db and start syncing from scratch again.
legendary
Activity: 2968
Merit: 1198
magnatoj, please stick to your own thread or threads relevant to cryptonote coins in general, unless you care to discuss Monero specifically here.

Best of luck with your project but spamming isn't a good idea.
legendary
Activity: 1624
Merit: 1008
Only 8 pull requests merged today  Wink

Release those Mustangs into the wild   Cool



Much github activity recently. Good progress.

I spoke too soon, make that 10 pull requests merged.

Thank you monermooo and fluffypony Smiley
member
Activity: 88
Merit: 10
Only 8 pull requests merged today  Wink

Release those Mustangs into the wild   Cool



Much github activity recently. Good progress.
legendary
Activity: 1624
Merit: 1008
Only 8 pull requests merged today  Wink

Release those Mustangs into the wild   Cool

legendary
Activity: 2268
Merit: 1141
Funding required for XMR pool infrastructure overhaul (done by Wolf0):

https://forum.getmonero.org/8/funding-required/2412/xmr-pool-infrastructure-overhaul?sort=date_desc

PS: Even if you don't have an account you are able to contribute, just press the contribute button and it will explain how to donate.
legendary
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
Shen linked me to the latest version of RingCT paper: https://www.overleaf.com/read/qzgytbyyxvyf

I've created a thread to discuss RingCT in a more simplified (hopefully) context here: https://bitcointalksearch.org/topic/m.13091439

It's a work in progress.

Looks like shen added 10-11 pages of content from the last version which was 15 pages.
legendary
Activity: 2268
Merit: 1141
In case anyone missed it, a few updates from Shen Noether regarding Confidential Transactions (CT) for Monero:

Quote
Edit 11/21/2015: things are slowly coming together - MLSAG's have been coded in python (https://github.com/ShenNoether/MiniNero/blob/master/MLSAG.py) and then I need to get the RingCT code using these rather than the LWW sigs. After this I should be able to finish the size analysis in the paper and then hopefully get a really cleaned up copy available.

Quote
edit 11/27/2015: demo version of RingCT using the MLSAG's is coded - next up is implementing 1. Diffie helman passing of masks and 2. implement a short representation of amounts

Most recent version:

https://www.overleaf.com/read/qzgytbyyxvyf
legendary
Activity: 2282
Merit: 1050
Monero Core Team
It has a lot of interesting applications including for example (humour?) to bypass ISP incompetence or even censorship by using carrier pigeons. http://news.bbc.co.uk/2/hi/africa/8248056.stm One thing to note since this was published in 2009, USB keys with 64 GB are now easily available giving a 16X increase in the bandwidth of the carrier pigeon and more than enough to accommodate the Monero blockchain.

Edit 1: https://en.wikipedia.org/wiki/IP_over_Avian_Carriers Some more examples if IPoAC (IP over Avian Carriers).
Edit 2: Other forms of sneakernet https://en.wikipedia.org/wiki/Sneakernet
legendary
Activity: 2968
Merit: 1198
...]

If you are operating under capped or metered bandwidth the optimized method to do a sync is here: https://bitcointalksearch.org/topic/m.12285629

This is probably somewhat more bandwidth-efficient than even downloading an old Boost-style bootstrap.

When 0.9 is released, the bootstrap will switch to an export format that is more bandwidth efficient and will be a good alternative to the above, somewhat complex, procedure.

The bandwidth limits are mostly useful for controlling other users' ability to sync from your node, or for limiting current bandwidth usage below your physical speed for connection sharing purposes. If you slow down your own syncing, it will just take longer, and the same overall bandwidth will be used anyway. If you limit bandwidth below the rate of actual usage you will just drop off the network, though current usage level is low enough that isn't likely to be an issue yet.


This method can be very useful in the following situation. Let us say one has a fully synchronized node on a desktop and one wishes to also have a fully synchronized node on a mobile device. One connects the mobile device to the local LAN (for example a home or business network) and then uses the above method to force synchronization with the existing LAN node at the much higher LAN speed and bandwidth without using or paying for ISP (WAN) bandwidth.

Edit: Of course in this situation the user could easily trust the node if they also created it.

Yes I have some extra nodes on a LAN for testing purposes and use --add-exclusive-node to connect them to my public node with no added usage of external bandwidth. Since I control all the nodes there is no issue of trust. It does introduce a single point of failure since they would all drop off if the public node did (and indeed they do briefly drop off when I restart the public node). But since they are for testing that is not a concern for me.
legendary
Activity: 2282
Merit: 1050
Monero Core Team
...]

If you are operating under capped or metered bandwidth the optimized method to do a sync is here: https://bitcointalksearch.org/topic/m.12285629

This is probably somewhat more bandwidth-efficient than even downloading an old Boost-style bootstrap.

When 0.9 is released, the bootstrap will switch to an export format that is more bandwidth efficient and will be a good alternative to the above, somewhat complex, procedure.

The bandwidth limits are mostly useful for controlling other users' ability to sync from your node, or for limiting current bandwidth usage below your physical speed for connection sharing purposes. If you slow down your own syncing, it will just take longer, and the same overall bandwidth will be used anyway. If you limit bandwidth below the rate of actual usage you will just drop off the network, though current usage level is low enough that isn't likely to be an issue yet.


This method can be very useful in the following situation. Let us say one has a fully synchronized node on a desktop and one wishes to also have a fully synchronized node on a mobile device. One connects the mobile device to the local LAN (for example a home or business network) and then uses the above method to force synchronization with the existing LAN node at the much higher LAN speed and bandwidth without using or paying for ISP (WAN) bandwidth.

Edit: Of course in this situation the user could easily trust the node if they also created it.
legendary
Activity: 2968
Merit: 1198
Yes, I have a metered broadband connection at home and foolishly launched the daemon with over 150 days to catch up yesterday - promptly hitting my broadband cap two weeks early - oops. It must have used several GB (unsure exactly how much as my supplier is useless with available stats). I need to look into general utilities to limit total daily data usage.

If you are operating under capped or metered bandwidth the optimized method to do a sync is here: https://bitcointalksearch.org/topic/m.12285629

This is probably somewhat more bandwidth-efficient than even downloading an old Boost-style bootstrap.

When 0.9 is released, the bootstrap will switch to an export format that is more bandwidth efficient and will be a good alternative to the above, somewhat complex, procedure.

The bandwidth limits are mostly useful for controlling other users' ability to sync from your node, or for limiting current bandwidth usage below your physical speed for connection sharing purposes. If you slow down your own syncing, it will just take longer, and the same overall bandwidth will be used anyway. If you limit bandwidth below the rate of actual usage you will just drop off the network, though current usage level is low enough that isn't likely to be an issue yet.




legendary
Activity: 1624
Merit: 1008
While syncing I maxed out my connection at 30 Mbps down and 5 Mbps up about 20% of the time vs close to 100% (maybe? can't remember clearly) with 0.8.6.6

After syncing the max was 5 Mbps for short periods of time which again seems much less than with 0.8.6.6
sr. member
Activity: 280
Merit: 250
I remember discussion quite a while ago in which it was stated that bandwidth would be used up to whatever was available and that it wasn't necessary to do so.  I believe this is where the bandwidth rate limits came from.  Maybe this is where Quicken' question came from.

I haven't looked closely since the 0.9 beta but with 0.8.6.6 it used to max out my bandwidth.  I have a fast connection with no monthly limit.  I am now syncing 0.9 to compare.

Yes, I have a metered broadband connection at home and foolishly launched the daemon with over 150 days to catch up yesterday - promptly hitting my broadband cap two weeks early - oops. It must have used several GB (unsure exactly how much as my supplier is useless with available stats). I need to look into general utilities to limit total daily data usage.

Currently syncing up the 0.9 beta at work.. just finished actually while I was typing the reply (height 844220). Very smooth. Lightwallet syncing now...

EDIT - synced @844226. All very nice. Side note - how about a 1 million blocks celebration?
legendary
Activity: 1624
Merit: 1008
I remember discussion quite a while ago in which it was stated that bandwidth would be used up to whatever was available and that it wasn't necessary to do so.  I believe this is where the bandwidth rate limits came from.  Maybe this is where Quicken' question came from.

I haven't looked closely since the 0.9 beta but with 0.8.6.6 it used to max out my bandwidth.  I have a fast connection with no monthly limit.  I am now syncing 0.9 to compare.

legendary
Activity: 1260
Merit: 1008
Could anyone share some stats on what the bandwidth usage is like for running bitmonerod 0.9 vs 0.8.8.6?

Obviously the RAM requirement is a big plus; just wondering how it looks for metered connections (GB/month).

you can set download and upload rate limits with a startup flag on the daemon. The new release doesn't change the bandwidth usage per se.

but ultimately, the amount of data being dloaded and uplodaded is going to depend on how much traffic is on the network!! if there's enough traffic to force blocks up to a constant 50 kb, then there would be significantly more bandwidth usage.

Although that would be an interesting option / feature. I setting to make a data cap for capped people, so say you know you can only afford to give 1 gb of data transfer for monero, then once that amount is reached.... the daemon stops? Hrm, but then you just run into the same problem every month
sr. member
Activity: 280
Merit: 250
Could anyone share some stats on what the bandwidth usage is like for running bitmonerod 0.9 vs 0.8.8.6?

Obviously the RAM requirement is a big plus; just wondering how it looks for metered connections (GB/month).
legendary
Activity: 1834
Merit: 1019
I thank forever and Godspeed on you all for putting a fire under your thoughts

Wink
Jump to: