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

[cashbitcoin]

Hey MRO community!

I bought some MRO a week ago. I saw thru posts here and there that it seems to be complicated to transfer larger amounts of MRO (more than 1) from wallet to wallet. I was thinking about sending most of my MRO from an exchange to the other. How shall I proceeed ?

[1714011868]

1714011868

[1714011868]

1714011868

[1714011868]

1714011868

[surfer43]

Pool operators: please restart bitmonerod with this command (remove your pool's IP)

Code:

./bitmonerod --add-priority-node 198.199.79.100:18080 5.9.25.103:18080 107.170.182.209:18080 62.210.78.186:18080 216.119.175.73:18080

This will keep open connections to all major (>2kh/s) pools so the pools mine less orphans.

[smooth]

Hey MRO community!

I bought some MRO a week ago. I saw thru posts here and there that it seems to be complicated to transfer larger amounts of MRO (more than 1) from wallet to wallet. I was thinking about sending most of my MRO from an exchange to the other. How shall I proceeed ?

It is not complicated to transfer large amounts -- unless the coins you sending were received as a whole bunch of smaller transactions. I have moved 10000 in one transaction. Maybe more than that, I don't remember.

[seek4dream]

The fate of Monero lyes with investors and the core community support behind the coin. If certain aspects of the anonymity of Monero are perceived as a step forward, then there is no doubt anonymous-based e-currencies is the future.
---------quoted from coinssource

[Keyboard-Mash]

Hey MRO community!

I bought some MRO a week ago. I saw thru posts here and there that it seems to be complicated to transfer larger amounts of MRO (more than 1) from wallet to wallet. I was thinking about sending most of my MRO from an exchange to the other. How shall I proceeed ?

It is not complicated to transfer large amounts -- unless the coins you sending were received as a whole bunch of smaller transactions. I have moved 10000 in one transaction. Maybe more than that, I don't remember.

What kind of mixin count were you using for that? I've been trying to put together an idea of some kind of responsible use of the mixin count, taking into consideration the fee that will be imposed and the size of the transaction to be carried out.

What would be really interesting to see is a graphical comparison of the amount transferred + the mixin count vs the resultant tx size that it yields. This would definitely be a great tool for people trying to send transactions but don't want to cause the tx to be unnecessarily large. I get that high mixin count gives a higher degree of anonymity, and that a lower one gives a lesser degree ... but can't really put together what happens between let's say <2 and >9. Of course, with speed at which things change maybe this would be premature?

[smooth]

Hey MRO community!

I bought some MRO a week ago. I saw thru posts here and there that it seems to be complicated to transfer larger amounts of MRO (more than 1) from wallet to wallet. I was thinking about sending most of my MRO from an exchange to the other. How shall I proceeed ?

It is not complicated to transfer large amounts -- unless the coins you sending were received as a whole bunch of smaller transactions. I have moved 10000 in one transaction. Maybe more than that, I don't remember.

What kind of mixin count were you using for that? I've been trying to put together an idea of some kind of responsible use of the mixin count, taking into consideration the fee that will be imposed and the size of the transaction to be carried out.

The mixin count causes a nearly-linear increase in transaction size (slightly less than linear because of fixed per-transaciton overhead). But the transaction size is a function of the number of inputs, not the number of coins. If you receive 10000 and then send 10000 that is going be the same size transaction for any given mixin count as it would be to receive 1 coin and then send 1 coin with the same mixin count.

I usually use a mixin count of 3-5, or perhaps 10 on transactions that I know are very small (in terms of transaction size, not coins). Even using 1 isn't too bad (i.e. much better than 0) because as the coins go through a series of mix=1 transactions they still eventually become mixed with everything and very hard to trace more than a few hops. I'll sometimes use 1 instead of 0 on large (again meaning large number of inputs) transactions.

[Keyboard-Mash]

The mixin count causes a nearly-linear increase in transaction size (slightly less than linear because of fixed per-transaciton overhead). But the transaction size is a function of the number of inputs, not the number of coins. If you receive 10000 and then send 10000 that is going be the same size transaction for any given mixin count as it would be to receive 1 coin and then send 1 coin with the same mixin count.

I usually use a mixin count of 3-5, or perhaps 10 on transactions that I know are very small (in terms of transaction size, not coins). Even using 1 isn't too bad (i.e. much better than 0) because as the coins go through a series of mix=1 transactions they still eventually become mixed with everything and very hard to trace more than a few hops. I'll sometimes use 1 instead of 0 on large (again meaning large number of inputs) transactions.

Thanks, this clears a lot up. So would it be a decent practice to periodically send all mined coins (multiple small tx's to one address) as one lump to another wallet I control with a low mixin count, rather than let them pile up and then use them continuously for future small scale transactions .. in order to decrease the size of the tx at that time? Or would this have no real effect on traceability/tx size? IE: Apart from the fixed tx overhead, is the size of the tx dependent on the just the origin, or more than just the previous origin?

[superresistant]

I completely changed the monero guide :

[ANN][MRO][HOW TO] Install GUI wallet & mine Monero on Windows

I explain how to install the GUI wallet (beta).

[nzminer]

Can someone help me with setting up this coin?
The link to the windows GUI seems to be broken and i cant download it, and im unsure how to configure the miner.
TIA

[drawingthesun]

Can someone help me with setting up this coin?
The link to the windows GUI seems to be broken and i cant download it, and im unsure how to configure the miner.
TIA

See:

https://github.com/zone117x/cryptonote-easy-miner

https://github.com/zone117x/cryptonote-easy-miner/releases

And use a pool with stratum.

I use:

http://moneropool.com/

[nzminer]

Can someone help me with setting up this coin?
The link to the windows GUI seems to be broken and i cant download it, and im unsure how to configure the miner.
TIA

See:

https://github.com/zone117x/cryptonote-easy-miner

https://github.com/zone117x/cryptonote-easy-miner/releases

And use a pool with stratum.

I use:

http://moneropool.com/

Can CPUminer be used to mine monero?
I read somewhere that it could, I think but its the wallet thats fustrating me the most

[smooth]

The mixin count causes a nearly-linear increase in transaction size (slightly less than linear because of fixed per-transaciton overhead). But the transaction size is a function of the number of inputs, not the number of coins. If you receive 10000 and then send 10000 that is going be the same size transaction for any given mixin count as it would be to receive 1 coin and then send 1 coin with the same mixin count.

I usually use a mixin count of 3-5, or perhaps 10 on transactions that I know are very small (in terms of transaction size, not coins). Even using 1 isn't too bad (i.e. much better than 0) because as the coins go through a series of mix=1 transactions they still eventually become mixed with everything and very hard to trace more than a few hops. I'll sometimes use 1 instead of 0 on large (again meaning large number of inputs) transactions.

Thanks, this clears a lot up. So would it be a decent practice to periodically send all mined coins (multiple small tx's to one address) as one lump to another wallet I control with a low mixin count, rather than let them pile up and then use them continuously for future small scale transactions .. in order to decrease the size of the tx at that time? Or would this have no real effect on traceability/tx size? IE: Apart from the fixed tx overhead, is the size of the tx dependent on the just the origin, or more than just the previous origin?

It is definitely a good idea to combine small outputs into larger ones, otherwise it is impossible to ever make payments in larger amounts (the transactions will be too big). Now if you only ever make small payments then I guess keeping the original small outputs is fine. But for larger payments they won't work at all, or will be too large to allow mixing. As far as mixin count to use when doing that, I can't give a good answer, as I haven't looked at the issues that carefully. The tradeoff is how many of these small outputs you can combine in one go. If you can't combine enough, you may need to do multiple steps.

The size of each transaction is dependent only on its immediate sources, not prior transactions that fed into those. So if you have a zillion tiny outputs and combine them into a few larger ones, subsequent transactions are not affected at all by the previous tiny outputs, and will be quite small.

[sdersdf2]

Any news about the GUI?

Work on  a _native_ QT wallet has been started.

Is there a rough ETA on this?

[qunity3d]

CPU overclocking on 15-20% gives a significant speed boost mining?
P.S.: CPU: FX6300.

[fedmahnkassad]

http://moneropool.org not paying the last 4+ hours. Is this normal? I am mining with around 240h/s and just switched to this pool today. The previous pool that I was at was paying a few times per hour.

[orinoco]

http://moneropool.org not paying the last 4+ hours. Is this normal? I am mining with around 240h/s and just switched to this pool today. The previous pool that I was at was paying a few times per hour.

Looking at the Pool Blocks page for both moneropool.com and moneropool.org both seem to have an issue - there's some blocks which haven't reached maturity but which should have paid out by now, going back a few hours.

Might be a problem with the new stratum protocol or new pool software?

[ROBERTO]

Hello, i have a problem today!

I mining at mine.moneropool.com and the connection are changed for stratum+tcp and when i run the minerd i have this msg : Protocol stratum+tcp not supported or disabled in libcurl

I'am on ubuntu 12.04

Need some help please!

Thanks

[horstman]

http://moneropool.org not paying the last 4+ hours. Is this normal? I am mining with around 240h/s and just switched to this pool today. The previous pool that I was at was paying a few times per hour.

Looking at the Pool Blocks page for both moneropool.com and moneropool.org both seem to have an issue - there's some blocks which haven't reached maturity but which should have paid out by now, going back a few hours.

Might be a problem with the new stratum protocol or new pool software?

Hey guys,

i like your coin. Nice concept etc.

I am mineing here: http://moneropool.com/stratum.html#

after entering my walletaddres (exported it out of the wallet.txt, also checked witht he "addres" command)
the pool is saying i have 0.042 MRO, but i didnt receive them yet.

Is there a payout treshhold are am i mineing in the wrong wallet?
Would be very kind if someone could help me, i never mined a CPU coin,yet.

[FrictionlessCoin]

Appears that QCN just passed MRO in price.

.0076 for QCN  and .0064 for MRO.

That's because there's less QCN 100K.

The difference between QCN and MRO is that the QCN mint rate is 1/4 that of MRO.   So I'm more short term bullish with QCN.

[Brewins]

cant seem to figure out how to transfer MRO,

I sent a transaction from my wallet but it hasnt shown up at Bittrex.. any ideas?