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

[equipoise]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter.

[xa4]

I do not find the how-to but the github instructions are OK.
briefly on ubuntu 15.04, to make a "db" bitmonerod

Thx for the how to Arux.

Not sure Dockerizing Monero is usefull, but I'm gonna look into it once I've a better understanding of Docker.

Not using docker atm, but if there's some interest, I could publish Ansible roles for installing the daemon and simplewallet.

I'm not familiar with Ansible, how does it compare to Docker ?

[smooth]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter.

Is this on Windows? I remember seeing something about setting the block size smaller being a work around for that.

[GingerAle]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

Blockchain convert is a carryover from earlier stages of LMDB-branch development I think. Left it in their because if you have massive resources, its still useful. The converter is resource-intensive because it loads the entire blockchain in memory (like old-style monero did) and then it starts creating the LMDB database (so all thats going on). So if you've got very little RAM, its using virtual memory (scratch space) to store the memory blockchain and work on the new database file, so things crawl.

thats how I understand it. This was in a missive.

[smooth]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

If you are doing -verify 0 it means none of the data is being checked at all as it is added to the database. If the raw file is in any way invalid, you can end up with a bad blockchain in a corrupt database and never know it until later when "something" goes wrong.

This is probably okay if you are importing a raw file you exported yourself from a working node (other than bugs), but probably not a good idea to use if you are downloading a raw file (other than maybe an official one, after verifying the checksum), and also probably not the greatest idea at this point when the code is still experimental (unless you are doing it for the purpose of an experiment).

[medusa13]

on windows, blockchain converter crashes for me. i dont know if its because i seem to run out of disc space.
also if i exyport and try to import, it allocates 16 gig of space just right in the beginning for the data.mdb

i had to move blockchain from %appData% to programData% for it to run

import runs now but very slow, lets see if it crashes.

edit: i clearly do this for fun so no need to worry bout me waitin 5 days

[mmortal03]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter.

Is this on Windows? I remember seeing something about setting the block size smaller being a work around for that.

Yeah, the same thing just happened to me. I'm going to give --batch-size 10000 a try.

Edit: Nope, that crashes, too. What's a reasonable value here?

[kazuki49]

QFTT

Its always good to remember.

[smooth]

Yowsers. Look at this ridiculous transaction. http://moneroblocks.eu/tx/a292f8068a525a403700e8d4c76dc6496136790e01b442e55047e46a167a8784

Is it possible to have wallets do more intelligent transaction crafting in-order to avoid accumulating a billion random small denomination inputs?

Yes it's possible. The current algorithm is approximately keep choosing random outputs until it has enough (or maybe a little extra). That has some advantages in being unpredictable and disadvantages in being inefficient (and possibly others).

I suggest writing up a proposal and/or implementing it.

That said we don't know what that wallet might have looked like. If there's nothing but small outputs left in there and you try to spend a lot, you are going to get a lot of small outputs regardless of algorithm.

[GingerAle]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter.

Is this on Windows? I remember seeing something about setting the block size smaller being a work around for that.

Yeah, the same thing just happened to me. I'm going to give --batch-size 10000 a try.

Edit: Nope, that crashes, too. What's a reasonable value here?

i saw someone suggest 100 on IRC.

[mmortal03]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter.

Is this on Windows? I remember seeing something about setting the block size smaller being a work around for that.

Yeah, the same thing just happened to me. I'm going to give --batch-size 10000 a try.

Edit: Nope, that crashes, too. What's a reasonable value here?

To answer my own question, I finally got it to complete successfully with --batch-size 5000. I tried 8000 before that, but that crashed just like 10000 and 20000.

Now that I have the lmdb folder in the right place and the binaries replaced, it does seem to be be working with MoneroX. It's now downloading the blocks that I was behind on. This looks promising.

[fluffypony]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter.

Is this on Windows? I remember seeing something about setting the block size smaller being a work around for that.

Yeah, the same thing just happened to me. I'm going to give --batch-size 10000 a try.

Edit: Nope, that crashes, too. What's a reasonable value here?

We've been most successful with 1000 on Windows, which is probably what we'll set the default as.

[fluffypony]

is there a way so i can seed the blockchain even better? i have bandwidth to give.


oh someone deleted my post from yesterday, why?  
i thought it was funny, sorry english is not my native language

You are not alone.

Whoever is acting as the Thread Nazi doesn't seem to appreciate it when someone that is a non-Dev acknowledges another person's attempt at humor or makes an attempt at humor themselves.

I had a post deleted that consisted solely of "lawlz" in response to a Dev's humorous post.

I took it as a hint and now refrain from posting lalwz.

It's not non-dev posts, my trollbeads post got removed too. I sent a message to the moderator of this section to find out why, and he pointed to this thread: https://bitcointalk.org/index.php?topic=703657.0

We're continuing to add functionality to the Monero forum (recently we added @username highlighting) so the conversation will evolve there.

[5w00p]

Interesting, fluffypony. I stand corrected.

I look forward to the conversation moving to the Monero forum. I wonder if we can have an Esperanto-only thread there.

[equipoise]

^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.

Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert?

It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter.

Is this on Windows? I remember seeing something about setting the block size smaller being a work around for that.

Yeah, the same thing just happened to me. I'm going to give --batch-size 10000 a try.

Edit: Nope, that crashes, too. What's a reasonable value here?

To answer my own question, I finally got it to complete successfully with --batch-size 5000. I tried 8000 before that, but that crashed just like 10000 and 20000.

Now that I have the lmdb folder in the right place and the binaries replaced, it does seem to be be working with MoneroX. It's now downloading the blocks that I was behind on. This looks promising.

Yes, it's Windows. I've tried the compile process for the first time since it was changed from visual studio to msys. Back then in the Monero second-third weeks it took me more then a week to compile it for the first time with VS/Intel compiler. The new msys compile process is very easy and straightforward and anyone could compile it from scratch in an hour. The import is now working with batch of 3000 on my PC and it's on block ~336000. It starts very fast and then each new 3000 batch is slower and slower. Adding all the blocks/transactions is O(n*log(n)) and it shouldn't be that slow. The import process is already faster then sync from the genesis block, but it could be optimized to finish in minutes instead of hours.

[farfiman]

...
It's not non-dev posts, my trollbeads post got removed too. I sent a message to the moderator of this section to find out why, and he pointed to this thread: https://bitcointalk.org/index.php?topic=703657.0
....

good one
Just the the first 3 on the list will kill 90% of the messages   (including this one)

1. No zero or low value, pointless or uninteresting posts or threads.
2. No off-topic posts.
3. No trolling.

[acha]

Hi!
Monero pool monero.crypto-pool.fr a day does not give xmr. What happened?

[smooth]

Hi!
Monero pool monero.crypto-pool.fr a day does not give xmr. What happened?

Ask here: https://bitcointalk.org/index.php?topic=658990.0

[medusa13]

ok i managed to convert on windows 7 x64 with batch size 1000 using blockchain_converter. was really fast(maybe 30min), but:

- data.mdb uses now more than 16gb, this is not normal no? this looks like some crazy pre allocation. same happens when exporting / importing.
- i want to highlight again, on windows monero uses now %programData% as default location instead of %appData% like in 0.8.8.6.

i am fully synced right now and bitmonerod uses 31 Megabyte of ram  
good job devs !!!

[GingerAle]

ok i managed to convert on windows 7 x64 with batch size 1000 using blockchain_converter. was really fast(maybe 30min), but:

- data.mdb uses now more than 16gb, this is not normal no? this looks like some crazy pre allocation. same happens when exporting / importing.
- i want to highlight again, on windows monero uses now %programData% as default location instead of %appData% like in 0.8.8.6.

i am fully synced right now and bitmonerod uses 31 Megabyte of ram  
good job devs !!!

yeah, thats the size of my data.mdb. Fluffypony said it something with windows not liking sparse files. Whatever that means.

weird - I think my data.mdb was in %appData%/bitmonerod/LMDB , not %programData%, but I'll double check when I get home.