 Show Posts
|
|
Pages: « 1 2 [3] 4 »
|
its that time again... time for what? MoneroWorld Weekly Digest 20150325 crazy digest ranking system proposed. Check it out! Thanks GingerAle! |
|
|
|
or you wait till the DB implentation is done which uses way less RAM  The DB implementation has been working on Linux for a long time now, and I can assure you it's been pretty stable for me. Those running Windows could set up a VM with as low as 256MB of RAM (I'm almost confident that's enough) , install Ubuntu 14.04 Server 64-bit on it (or your preferred distro) and compile the code from https://github.com/tewinget/bitmonero/tree/blockchain |
|
|
|
Hi there! Today I came across blocks 457254 up to 457258 which seem pretty odd to me. They all contain many transactions with fees of 0.1 XMR for small size transactions, this one http://chainradar.com/xmr/block/457255 , for example, has 23 transactions with a fee of 0.1 XMR plus a couple of normal transactions, totaling ~2.34 XMR in fees for the block. Any thoughts about it? I can explain the 0.1 XMR fee easily enough. That is what happens if you haven't upgraded your wallet to the version with per-KB fees. As you saw, on small transactions, you will significantly overpay. I can't explain why someone would generate so many transactions like that. Thanks smooth. I thought that after the per-kb fees update those transactions wouldn't be accepted by miners, but it makes sense to still accept them as long as they are not underpaid. |
|
|
|
Hi there! Today I came across blocks 457254 up to 457258 which seem pretty odd to me. They all contain many transactions with fees of 0.1 XMR for small size transactions, this one http://chainradar.com/xmr/block/457255 , for example, has 23 transactions with a fee of 0.1 XMR plus a couple of normal transactions, totaling ~2.34 XMR in fees for the block. Any thoughts about it? |
|
|
|
I can also confirm that the DB version is working  I've been running it for the past days, I've synced the blockchain from scratch and have made a few transfers, and so far it has worked great! In my case it's using around 300 Mb of RAM right now. I encourage all Linux users to try it out. If anyone is interested in downloading the blockchain in DB format let me know and I'll upload it somewhere. For those who don't have an SSD, I recommend applying these changes for better performance: https://bitcointalk.org/index.php?topic=583449.msg9610064#msg9610064 (the line number may have changed, but the code to replace it's still the same) |
|
|
|
I would like usage of Monero privacy...
Is there any index where can we see all what we can buy or pay online with Monero?
Not much there yet, but here is the "Merchants and Marketplace" section from the official Monero forum: https://forum.monero.cc/3/merchants-and-marketplace |
|
|
|
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? |
|
|
|
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 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. |
|
|
|
And now 4 giga fucking byte is considered short...
Valid point, but I'd just say that at 4 GB you are pretty close to a critical point where even a small increase would have a disproportionately large benefit. The blockchain on disk is currently 3.2 GB. I don't know how that translates directly to in-RAM usage but I guess it might be slightly higher (or at least higher including other code, other applications, etc.). So you are right on the cusp of it being able to fit in RAM with a bit left over for I/O buffers and not being able to fit (i.e. swapping). 6 GB would probably be much faster than 4 GB and 2 GB is definitely much slower (I've tested it). Summary: I recommend 6+ GB for best performance currently, 2+ GB for a bare minimum (with questionable at best performance). 4 GB is in between. On my end, I'm running the daemon in a VirtualBox VM with Ubuntu 14.04 server, 1 GB of RAM assigned to it, and a 6GB swap file. I have commented out the parts of the code that force the blockchain to be saved every 12 hours. It takes a LOT of time to load the first time, but that's the only one time that I need to wait for the blockchain to load into RAM, as I don't ever stop the daemon unless I update it. When I want to "close" the daemon I just close the VM saving the current state (not powering it off, but saving the current state so I can resume it later). Next time I want to run it, I just resume the VM and it continues as if nothing had happened, and starts syncing the blockchain right away. I don't have to wait for the blockchain to be loaded into RAM/swap and it only uses 1GB of my physical RAM. I run simplewallet on my host machine (meaning not in the VM) and forward local port 18081 to the VM running the daemon through VirtualBox NAT Networks settings. I do this on my laptop, which has 4GB of RAM and HDD (hybrid drive really, but for writing operations is the same as plain HDD). |
|
|
|
Its doing the same for me. Something seems to be wrong with MyMonero.com at the moment - if I try to start a new account, copy & paste the seed words it says "account does not exist!"  My few XMR coins are still there so it is fixed I think. Already existent accounts can log in, but creating a new one does not work. |
|
|
|
I'll be there! |
|
|
|
I'll quote the first comment (sorted by "best") which explains it all and which just happens to be from fluffypony: Unfortunately it'll only last till Nov 1 2015, and has to be revoked by October 2016, as the requirements from the CA / Browser Forum don't allow for certificates for "internal names" like .onion (under the auspices that ICANN may in future approve an actual .onion TLD, for instance).
There was some talk of making an except for .onion domains, except there's one snag: the Tor Project don't want to ask for it, because SSL certificates for .onion addresses are redundant and unnecessary. Why? Because the Tor protocol / software already encrypts the traffic between the browser and the hidden service, and since the .onion address is a hash of the host's key the whole communication loop is authenticated. Thus, SSL certs for Tor are only handy when you leave via an exit node, which you wouldn't do for .onion addresses.
In short, the SSL cert is a cute marketing gimmick, but it's going to be revoked anyway and on the whole is unnecessary.
|
|
|
|
Thanks for that info. I have one more question:
The pool found a few blocks but weren't distributing the coins (obviously since I had the settings incorrect). I manually dispersed the coins. Now when the correct settings are in place I get an error that it's trying to send the original amount pending balance, however that amount is no longer there. Any insight? I've tried restarting the server but it doesn't help.
Well... in that case you will need to fiddle with the data in the redis DB and set those pending balances as already paid, otherwise the pool will pay them as soon as it has some coins. |
|
|
|
BEWARE!! I'm using chrome and I get a warning from that link and it doesn't want to connect me to that site.
Yes, that's because the SSL certificate for that domain is invalid, it expired on October 9th. |
|
|
|
And monerochain is displaying what exactly? Old BTC blocks and recent transactions?  Hmm... that's kind of messed up. The original site was monerochain.info, but it's been down for quite a while now. |
|
|
|
Is there a working block explorer somewhere still? The one with the highest block height I found is http://chainradar.com/xmr/blocks but 325679 is still a lot lower than the 327845 my client is telling me. There's also https://minergate.com/blockchain/mro/blocks , but strangely enough they both are stuck at the exact same block, which to my eyes would indicate that the same people are behind both of them, or at least are related. |
|
|
|
Hi Guys! So I have setup my Monero Pool. I'm the only one mining it with around 4KH/s right now. Everything seems to working fine except for the automatic payout. Anyone know what values I need to put in the config file to make it payout at .50 Monero's ? I've tried different option but it's not working out.
Can anyone help?
Can you be more specific? What is your current config? It's in the config.json file. I have 3 options which i'm unsure what they are exactly: transferfee: 50000000 minPayment: 100000000 denomination: 100000000 Those above are default values. What should they be? Ideally you should be running a version of the daemon which includes per-kb fees (this was merged into master on Nov. 7). I'm not sure whether the transferFee value is ignored or not, but in any case, a safe bet would be to set it to 10000000000 (0.01 XMR). For a payout at 0.5 XMR you should use these settings: "transferFee": 10000000000, "minPayment": 500000000000, "denomination": 100000000000 If you are still having troubles, look into logs/payments_error.log for relevant info. If you still need some help, please post your config.json to http://pastebin.com/ or a similar site (obfuscating any sensible data) , so we can help you better. |
|
|
|
I erroneously stated before that there was no source code, so I deleted that post. Nevertheless, beware that this GUI was posted with a new account, so common sense says you shouldn't trust the binaries provided. If you really want to try it out, I recommend inspecting the source code and compiling it yourself. |
|
|
|
If any of you is located in the US or the rest of the Americas, for lower latency please give it a try to my pool at https://monerohash.com . Thanks! |
|
|
|
|
