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

[Hueristic]

https://thehackernews.com/2015/12/north-korea-red-star-os.html

[1714677554]

1714677554

[1714677554]

1714677554

[1714677554]

1714677554

[smooth]

Congratulations on the new release!

Minor bug report:

When syncing from scratch the "days behind" is off by a factor of two.  I did not look at the relevant code yet but assume that the proper equation going forward (for 2 minute blocks) was improperly applied to the "days behind" notifications for historical (1 minute) blocks.

Noted here: https://github.com/monero-project/bitmonero/issues/591

[c789]

Congratulations and thanks to all who made v0.9 possible!

I downloaded the linux64 binaries today as well as blockchain.raw. I used this to create the blockchain (used my actual path to download.raw):
sudo blockchain_import --input-file /path/to/your/download.raw --verify 0

After that process completed, I ran this command:
sudo ./bitmonerod

...and got this error message:

Code:

Creating the logger system
2016-Jan-02 00:43:04.712691 Initializing cryptonote protocol...
2016-Jan-02 00:43:04.712868 Cryptonote protocol initialized OK
2016-Jan-02 00:43:04.713234 Initializing p2p server...
[1451713384] libunbound[4214:0] info: warning: unsupported algorithm for trust anchor . DS IN
[1451713384] libunbound[4214:0] warning: trust anchor . has no supported algorithms, the anchor is ignored (check if you need to upgrade unbound and openssl)
2016-Jan-02 00:43:04.743525 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.743885 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.744098 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.744425 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.745453 Binding on 0.0.0.0:18080
2016-Jan-02 00:43:04.745744 Net service bound to 0.0.0.0:18080
2016-Jan-02 00:43:04.745867 Attempting to add IGD port mapping.
2016-Jan-02 00:43:08.832162 Added IGD port mapping.
2016-Jan-02 00:43:08.832325 P2p server initialized OK
2016-Jan-02 00:43:08.832571 Initializing core rpc server...
2016-Jan-02 00:43:08.832728 Binding on 127.0.0.1:18081
2016-Jan-02 00:43:08.832939 Core rpc server initialized OK on port: 18081
2016-Jan-02 00:43:08.833045 Initializing core...
2016-Jan-02 00:43:08.833459 Loading blockchain from folder /home/mike/.bitmonero/lmdb ...
2016-Jan-02 00:43:08.833574 option: fastest
2016-Jan-02 00:43:08.833667 option: async
2016-Jan-02 00:43:08.833759 option: 1000
2016-Jan-02 00:43:08.834491 LMDB memory map needs resized, doing that now.
2016-Jan-02 00:43:08.834707 LMDB Mapsize increased.  Old: 10215MiB, New: 11239MiB
2016-Jan-02 00:43:08.908128 Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908449 ERROR /DISTRIBUTION-BUILD/src/daemon/daemon.cpp:146 Uncaught exception! Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908585 Deinitializing rpc server...
2016-Jan-02 00:43:08.908876 Deinitializing p2p...
2016-Jan-02 00:43:08.910596 Deinitializing core...
2016-Jan-02 00:43:08.911011 Closing IO Service.
2016-Jan-02 00:43:08.957527 Deinitializing cryptonote_protocol...

Any ideas?  EDIT: All files in the log directory were empty.

[Jason.W]

Is the daemon supposed to pass blocks synced during a session out of memory?

Congratulations on the release

[smooth]

Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

[smooth]

Congratulations and thanks to all who made v0.9 possible!

I downloaded the linux64 binaries today as well as blockchain.raw. I used this to create the blockchain (used my actual path to download.raw):
sudo blockchain_import --input-file /path/to/your/download.raw --verify 0

After that process completed, I ran this command:
sudo ./bitmonerod

...and got this error message:

Code:

Creating the logger system
2016-Jan-02 00:43:04.712691 Initializing cryptonote protocol...
2016-Jan-02 00:43:04.712868 Cryptonote protocol initialized OK
2016-Jan-02 00:43:04.713234 Initializing p2p server...
[1451713384] libunbound[4214:0] info: warning: unsupported algorithm for trust anchor . DS IN
[1451713384] libunbound[4214:0] warning: trust anchor . has no supported algorithms, the anchor is ignored (check if you need to upgrade unbound and openssl)
2016-Jan-02 00:43:04.743525 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.743885 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.744098 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.744425 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.745453 Binding on 0.0.0.0:18080
2016-Jan-02 00:43:04.745744 Net service bound to 0.0.0.0:18080
2016-Jan-02 00:43:04.745867 Attempting to add IGD port mapping.
2016-Jan-02 00:43:08.832162 Added IGD port mapping.
2016-Jan-02 00:43:08.832325 P2p server initialized OK
2016-Jan-02 00:43:08.832571 Initializing core rpc server...
2016-Jan-02 00:43:08.832728 Binding on 127.0.0.1:18081
2016-Jan-02 00:43:08.832939 Core rpc server initialized OK on port: 18081
2016-Jan-02 00:43:08.833045 Initializing core...
2016-Jan-02 00:43:08.833459 Loading blockchain from folder /home/mike/.bitmonero/lmdb ...
2016-Jan-02 00:43:08.833574 option: fastest
2016-Jan-02 00:43:08.833667 option: async
2016-Jan-02 00:43:08.833759 option: 1000
2016-Jan-02 00:43:08.834491 LMDB memory map needs resized, doing that now.
2016-Jan-02 00:43:08.834707 LMDB Mapsize increased.  Old: 10215MiB, New: 11239MiB
2016-Jan-02 00:43:08.908128 Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908449 ERROR /DISTRIBUTION-BUILD/src/daemon/daemon.cpp:146 Uncaught exception! Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908585 Deinitializing rpc server...
2016-Jan-02 00:43:08.908876 Deinitializing p2p...
2016-Jan-02 00:43:08.910596 Deinitializing core...
2016-Jan-02 00:43:08.911011 Closing IO Service.
2016-Jan-02 00:43:08.957527 Deinitializing cryptonote_protocol...

Any ideas?  EDIT: All files in the log directory were empty.

Looks like maybe a problem with the import tool. While it is being investigated I suggest you just sync from the network instead. Most people have found that to be fast and efficient.

Also, you shouldn't really need to sudo for the daemon, it should work fine without privileges, though now that you have done it once the permissions on your .bitmonero folder might be messed up. Try renaming it to something else.

[Jason.W]

Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

[ScammyScammer]

XMR is doing great today and seems to have found a bottom around .001

I wonder where it's going to go from here.

[smooth]

Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sound like you are using the current version. The usage, as I said, may increase if your OS decides to keep some of the blockchain in RAM as a cache. But that should not cause anything to hang. The memory usage should be freed up if needed.

But perhaps there is some other problem. It is hard to say on a forum. Maybe go freenode IRC, channel #monero, and see if someone can help you figure out what is going wrong.  https://webchat.freenode.net

[Jason.W]

Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sounds like you are using the current version.

I'll try resyncing from scratch again, as I'm almost caught up.

The version I am using is the HH release from github yesterday, windows.

It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it.

TY smooth.

[smooth]

Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sounds like you are using the current version.

I'll try resyncing from scratch again, as I'm almost caught up.

The version I am using is the HH release from github yesterday, windows.

It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it.

TY smooth.

As I said it will use what you have. If no other programs are using the memory, then your OS will give it more (especially during sync). If other programs need RAM, the memory usage for the node will shrink down to almost nothing (especially once synced).

However, you shouldn't see anything hang. That was what I thought pointed to a problem.

[Jason.W]

Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sounds like you are using the current version.

I'll try resyncing from scratch again, as I'm almost caught up.

The version I am using is the HH release from github yesterday, windows.

It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it.

TY smooth.

As I said it will use what you have. If no other programs are using the memory, then your OS will give it more (especially during sync). If other programs need RAM, the memory usage for the node will shrink down to almost nothing (especially once synced).

However, you shouldn't see anything hang. That was what I thought pointed to a problem.

I can't rule out that there is something else wrong with the OS currently.

Give me a few hours, I'll have a duplicate fresh OS installation on this HW and get back to you.

[boestin]

Hydrogen Helix runs fantastic on OSX. 
Any plans for implementing the terminal buttons? (Tab for filling in, and up arrow for last command)?

Thanks!

[smooth]

Hydrogen Helix runs fantastic on OSX.  
Any plans for implementing the terminal buttons? (Tab for filling in, and up arrow for last command)?

Thanks!

rlwrap works on Linux (mentioned at the end of the README file). I don't know if there is an equivalent utility on OSX.

[ibuyltc]

Cant wait to try the new version!

[digicoin]

So the new default directory to store block chain data in  is C:\ProgramData in Windows?

[dEBRUYNE]

Crosspost:

Interesting comment from Shen about multisig

yep - very likely will be implemented in conjunction with the ring ct stuff

Following the "written up" link in the Ring CT post, section 4.4 of the paper describes how to implement "Ring multisignature". Some of the other CryptoNote coins have multisig, but only with 0 mixin.

Very nice work being done on the crypto front.

[digicoin]

I have replaced Monero 0.9 beta files with the ones in the final release. Started bitmonerd.exe to sync block chain. After fully sync-ed for a while, Monero still occupied 1,300,000 - 1,600,000 K (1.2GB - 1.5GB RAM) for Working Set (shareable memory) and 56,000K (55 MB Privating Working Set)

[smooth]

I have replaced Monero 0.9 beta files with the ones in the final release. Started bitmonerd.exe to sync block chain. After fully sync-ed for a while, Monero still occupied 1,300,000 - 1,600,000 K (1.2GB - 1.5GB RAM) for Working Set (shareable memory) and 56,000K (55 MB Privating Working Set)

Yes the so-called shareable memory is caching of the database file, and will be freed up as needed by the OS. It is called shareable because theoretically there could be multiple applications accessing the database sharing that memory, although that isn't the case in this particular usage.

[dnaleor]

If you like the new release and have some spare XMR, I suggest supporting the devs by donating
https://bitcointalk.org/index.php?topic=700400.0

PS: It seems I can now add some quote below my name in the "Hall of Fame". This is this quote I'll choose:

Crypto may offer a way to do "key blinding".  I did some research and it was obscure, but there may be something there.  "group signatures" may be related.