Author

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

legendary
Activity: 2968
Merit: 1198
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.
legendary
Activity: 2968
Merit: 1198
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.

hero member
Activity: 833
Merit: 1001
what kind of hopes did you have? get rich overnight? Roll Eyes 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. Sad
I hope everybody can gain their losses again.
newbie
Activity: 1
Merit: 0
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.
legendary
Activity: 2282
Merit: 1050
Monero Core Team
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.
legendary
Activity: 2268
Merit: 1141
.
.
.
Additional graphs here: https://bitcointalksearch.org/topic/m.7202538
.
.
.

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.
hero member
Activity: 896
Merit: 1000
I lost all my hopes about XMR sadly. Sad
I hope everybody can gain their losses again.

Are you related to Pandacoin? or Do you have lots of pandacoin?
legendary
Activity: 1554
Merit: 1000
I lost all my hopes about XMR sadly. Sad
I hope everybody can gain their losses again.
legendary
Activity: 1092
Merit: 1000
I'm a Firestarter!
Looks like B is more safe.
Any new projects in last few days?
legendary
Activity: 1260
Merit: 1008
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.
legendary
Activity: 1512
Merit: 1012
Still wild and free
.
.
.
Additional graphs here: https://bitcointalksearch.org/topic/m.7202538
.
.
.

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.
legendary
Activity: 1372
Merit: 1003
.
.
.
Additional graphs here: https://bitcointalksearch.org/topic/m.7202538
.
.
.

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.
member
Activity: 70
Merit: 10
https://monerohash.com
Wallet working very well. Thank you very much, jwinterm, good work! Smiley 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  Wink 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  Smiley

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 :
Quote
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.
legendary
Activity: 1512
Merit: 1012
Still wild and free
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.


 
legendary
Activity: 3136
Merit: 1116
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).
full member
Activity: 211
Merit: 100
does the new wallet still require 64-bit system?
hero member
Activity: 798
Merit: 1000
21 million. I want them all.
Price talk might be better in the Speculation thread
legendary
Activity: 1596
Merit: 1030
Sine secretum non libertas
increasing in value 100X.  It isn't going to happen anytime soon so don't get your hopes up.  People need to be realistic and realize that things could get much worse than they are now. 

For those with a long-term plan, things could hardly get better than they are now.
sr. member
Activity: 266
Merit: 250
increasing in value 100X.  It isn't going to happen anytime soon so don't get your hopes up.  People need to be realistic and realize that things could get much worse than they are now. 
donator
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
I'm sure this info is somewhere but I couldn't easily find it.  When is the first block reward reduction for Monero and how much will it reduce by.  I'm guessing at the end of Q2 next year but I'm not sure how big the reduction will be.  I know that ~84% of all XMR will be hashed within four years or probably within three and half years from now.

The first block reward reduction happened on block 2.

Genesis block reward: 17.592169267200
Block 2 block reward: 17.592152490000

It decreases every block (with an additional penalty that could affect it on a per-block basis if that block is > 20% from the block size median at that time).
Jump to: