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

[thelibertycap]

does the new wallet still require 64-bit system?

[1714105444]

1714105444

[1714105444]

1714105444

[1714105444]

1714105444

[jwinterm]

does the new wallet still require 64-bit system?

Yea, because it still uses simplewallet, it's really just a wrapper. If someone could compile a 32 bit version of simplewallet for windows though, then it would work (I'm not sure if the daemon is the limiting factor keeping things 64-bit at the moment, but I think it is).

[binaryFate]

does the new wallet still require 64-bit system?

Yea, because it still uses simplewallet, it's really just a wrapper. If someone could compile a 32 bit version of simplewallet for windows though, then it would work (I'm not sure if the daemon is the limiting factor keeping things 64-bit at the moment, but I think it is).

Last week I was trying to compile a 32-bits linux version of the daemon and the wallet. I had to tweak the code a little bit for the compilation to go through and complete without complains.
But after that I got a seg fault at execution. I checked for bitmonerod, gdb tells me it fails on an AES instruction (called from slowhash() if I remember well). Pretty sure it's an issue with a memory alignement that is not as assumed on 32-bits systems. Didn't check further after that, and didn't check where was the simplewallet error (it fails on wallet creation, after asking for the language) but I presume it is the same origin.


 

[osensei]

Wallet working very well. Thank you very much, jwinterm, good work! Syncing very fast, change existing wallets, import it in lightWallet very easy! Very important - use only 1.3 Gb of RAM, none 4 Gb!
But   what's the red rounds when right click on the wallet))

yes, me too finally have an usable gui for monero on my laptop, and my 4gb ram is more than enough  

Please, be aware that using a remote daemon compromises your privacy, as it leaks your transactions data. Someone in the middle sniffing your connection would be able to take a look at it, as well as the people operating the remote daemon. So basically you are trusting the person running the daemon and that no one is snooping your connection .

Quoting smooth from https://forum.monero.cc/4/academic-and-technical/10/remote-monero-deamon :

It will leak literally everything you do except receiving transactions (since that does not involve sending any information to the network) and your actual private keys. All of the transactions you submit will be visible and the wallet uses the daemon to choose mixins, so those will be visible as well, revealing (by elimination) your actual outputs spent. This will in turn reveal transactions you have previously received (since otherwise you wouldn't be spending those outputs).

The RPC was clearly designed to be used between multiple processes on the same system and this is really can't be recommended as a general solution for remote wallets.

There will eventually be sound designs for lightweight wallets, but this is not one of them.

The only situation where this would be safe to use would be on a secured network to support wallets on multiple computers within that local network.

A good scenario would be you running your own remote daemon and using a secure channel to connect to it. Mapping a local port to the daemon over SSH is an easy option. A VPN is another.

You can run your own monero daemon for $5/month at either DigitalOcean or Vultr. I've tested it myself on their minimal plans and it works. You'll need enough space for a swapfile and the blockchain (+ the temporary blockchain file that is created when saving). It takes a few minutes to load and a few minutes to save the blockchain, but I would say it's a pretty acceptable option if you don't want to put your privacy at risk and don't mind spending $5/month. Vultr even accepts BTC.

[matthewh3]

.
.
.
Additional graphs here: https://bitcointalk.org/index.php?topic=597878.msg7202538#msg7202538
.
.
.

Thanks for the links, was the infaltion idea of charts B in the graphs in the above link chosen.  Or has it yet to still be decided.

[binaryFate]

.
.
.
Additional graphs here: https://bitcointalk.org/index.php?topic=597878.msg7202538#msg7202538
.
.
.

Thanks for the links, was the infaltion idea of charts B in the graphs in the above link chosen.  Or has it yet to still be decided.

Nothing was decided yet for the "tail emission". Should be in the next few months.

[GingerAle]

granted, my noob status probably doesn't give my opinion much weight, but I'd vote for the permanent, but low, inflation model. This would solve the mining reward and deflation problem, both of which some consider not to be problems, and maybe they aren't, but I would vote for B.

If anything, a permanent but low inflation could simply offset lost coins.

[liteon]

Looks like B is more safe.
Any new projects in last few days?

[pandacoin]

I lost all my hopes about XMR sadly.
I hope everybody can gain their losses again.

[Eastwind]

I lost all my hopes about XMR sadly.
I hope everybody can gain their losses again.

Are you related to Pandacoin? or Do you have lots of pandacoin?

[dEBRUYNE]

.
.
.
Additional graphs here: https://bitcointalk.org/index.php?topic=597878.msg7202538#msg7202538
.
.
.

Thanks for the links, was the infaltion idea of charts B in the graphs in the above link chosen.  Or has it yet to still be decided.

Nothing was decided yet for the "tail emission". Should be in the next few months.

I would like to add that the current emission isn't changed. So charts of A are still valid.

[ArticMine]

does the new wallet still require 64-bit system?

Yea, because it still uses simplewallet, it's really just a wrapper. If someone could compile a 32 bit version of simplewallet for windows though, then it would work (I'm not sure if the daemon is the limiting factor keeping things 64-bit at the moment, but I think it is).

Last week I was trying to compile a 32-bits linux version of the daemon and the wallet. I had to tweak the code a little bit for the compilation to go through and complete without complains.
But after that I got a seg fault at execution. I checked for bitmonerod, gdb tells me it fails on an AES instruction (called from slowhash() if I remember well). Pretty sure it's an issue with a memory alignement that is not as assumed on 32-bits systems. Didn't check further after that, and didn't check where was the simplewallet error (it fails on wallet creation, after asking for the language) but I presume it is the same origin.


 

Right now one needs PAE  https://en.wikipedia.org/wiki/Physical_Address_Extension to run Monero on 32 bit systems making them effectively 36 bit. This is because Monero needs to address more than 4GB of memory (bitmonerod takes approximately 4.8GB on 64bit Kubuntu). This can work on GNU/Linux. On 32 bit Windows however, Microsoft cripples the desktop versions to 4GB RAM (that is the nature of a propriety OS) so even though they support PAE it still will not work. It is possible to enable PAE on certain 32 bit versions of Windows Server (The advance datacenter versions of Windows server 2000 or 2003 for example) and theoretically make this work. Here are the memory limits on various versions of Windows. msdn.microsoft.com/en-ca/library/windows/desktop/aa366778(v=vs.85).aspx One should keep in mind that anything under 64GB for 32 bit version is a deliberate crippling in order to sell more expensive licenses and not a real technical limitation.

Once the database is complete and tested then it should be possible to run Monero on 32bit windows with its much lower memory availability.

[kenns]

hello. I'm going to work on a client in c# for monero in the next week with spare time.
my plans for it to look basic and be dependent on the the daemon and the wallet
just a heads up
going to see how far with features i can get if you have any in mind of what the other client do not have lemme know i can try to implement em.

[bclcjunkie]

what kind of hopes did you have? get rich overnight? if you're in this for speculative trading then this sort of outcome is expected of any volatile cryptocurrency, including bitcoin but if you have long term plans for xmr and know its potential then you shouldn't be seeing it as a loss...

I lost all my hopes about XMR sadly.
I hope everybody can gain their losses again.

[smooth]

does the new wallet still require 64-bit system?

Yea, because it still uses simplewallet, it's really just a wrapper. If someone could compile a 32 bit version of simplewallet for windows though, then it would work (I'm not sure if the daemon is the limiting factor keeping things 64-bit at the moment, but I think it is).

Last week I was trying to compile a 32-bits linux version of the daemon and the wallet. I had to tweak the code a little bit for the compilation to go through and complete without complains.
But after that I got a seg fault at execution. I checked for bitmonerod, gdb tells me it fails on an AES instruction (called from slowhash() if I remember well). Pretty sure it's an issue with a memory alignement that is not as assumed on 32-bits systems. Didn't check further after that, and didn't check where was the simplewallet error (it fails on wallet creation, after asking for the language) but I presume it is the same origin.

If you aren't mining just tweak the useAes variable so it never uses AES instructions.

[smooth]

Please, be aware that using a remote daemon compromises your privacy, as it leaks your transactions data. Someone in the middle sniffing your connection would be able to take a look at it, as well as the people operating the remote daemon. So basically you are trusting the person running the daemon and that no one is snooping your connection .

Quoting smooth from https://forum.monero.cc/4/academic-and-technical/10/remote-monero-deamon :

I think it is possible to mostly fix this model of light wallet by connecting to multiple nodes getting mixins from all of them. Then randomly choose some of the mixins from each. None of them individually will be able to tell which is your coin source; they would have to collude.

Snooping of transactions doesn't really matter -- they are public anyway --although snooping of the mixins could matter, and snooping of your IP could matter. Both issue can be largely fixed (granted not NSA-proof) by connecting to the nodes over Tor. A simple proxy setup should work.

EDIT: clarify that any number of nodes (>1) can be used, not just two.

[binaryFate]

does the new wallet still require 64-bit system?

Yea, because it still uses simplewallet, it's really just a wrapper. If someone could compile a 32 bit version of simplewallet for windows though, then it would work (I'm not sure if the daemon is the limiting factor keeping things 64-bit at the moment, but I think it is).

Last week I was trying to compile a 32-bits linux version of the daemon and the wallet. I had to tweak the code a little bit for the compilation to go through and complete without complains.
But after that I got a seg fault at execution. I checked for bitmonerod, gdb tells me it fails on an AES instruction (called from slowhash() if I remember well). Pretty sure it's an issue with a memory alignement that is not as assumed on 32-bits systems. Didn't check further after that, and didn't check where was the simplewallet error (it fails on wallet creation, after asking for the language) but I presume it is the same origin.

If you aren't mining just tweak the useAes variable so it never uses AES instructions.

Now that you say this, I think I tried that already by force setting the support_aes (or whatever it is called) variable to -1 instead of actually testing for hardware AES support. Then it was failing shorlty afterwards on something else than AES, and I think I gave up at that point. Like always after fiddling, I should have taken some notes!

And I realize it was on pae-capable hardware but without pae kernel.  
Will try again after upgrading kernel then, and let you know.

[jwinterm]

Right now one needs PAE  https://en.wikipedia.org/wiki/Physical_Address_Extension to run Monero on 32 bit systems making them effectively 36 bit. This is because Monero needs to address more than 4GB of memory (bitmonerod takes approximately 4.8GB on 64bit Kubuntu). This can work on GNU/Linux. On 32 bit Windows however, Microsoft cripples the desktop versions to 4GB RAM (that is the nature of a propriety OS) so even though they support PAE it still will not work.

So in theory you should just be able to compile a 32 bit version of simplewallet, and then run simplewallet using a remote 64 bit version of bitmonerod? Or this is impossible because of some incompatibility between 32 bit simplewallet and 64 bit bitmonerod?

[osensei]

Please, be aware that using a remote daemon compromises your privacy, as it leaks your transactions data. Someone in the middle sniffing your connection would be able to take a look at it, as well as the people operating the remote daemon. So basically you are trusting the person running the daemon and that no one is snooping your connection .

Quoting smooth from https://forum.monero.cc/4/academic-and-technical/10/remote-monero-deamon :

I think it is possible to mostly fix this model of light wallet by connecting to two nodes getting mixins from both. Then randomly choose have the mixins from each. Neither will be able to tell which is your coin source.

Snooping of transactions doesn't really matter -- they are public anyway --although snooping of the mixins could matter, and snooping of your IP could matter. Both issue can be largely fixed (granted not NSA-proof) by connecting to the nodes over Tor. A simple proxy setup should work.

Even over Tor, wouldn't it leak destination addresses and transactions amounts?

EDIT: Oh, OK, if the node is running as an .onion service then the channel would be secure, but would the node be able to get addresses and amounts?

[jwinterm]

Please, be aware that using a remote daemon compromises your privacy, as it leaks your transactions data. Someone in the middle sniffing your connection would be able to take a look at it, as well as the people operating the remote daemon. So basically you are trusting the person running the daemon and that no one is snooping your connection .

Quoting smooth from https://forum.monero.cc/4/academic-and-technical/10/remote-monero-deamon :

I think it is possible to mostly fix this model of light wallet by connecting to two nodes getting mixins from both. Then randomly choose have the mixins from each. Neither will be able to tell which is your coin source.

Snooping of transactions doesn't really matter -- they are public anyway --although snooping of the mixins could matter, and snooping of your IP could matter. Both issue can be largely fixed (granted not NSA-proof) by connecting to the nodes over Tor. A simple proxy setup should work.

Even over Tor, wouldn't it leak destination addresses and transactions amounts?

If the remote node is trusted, in the light wallet user's opinion, would it be possible to eliminate snooping by using https?