Author

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

sr. member
Activity: 302
Merit: 250
Imagine a world without hate and oppression
Why Cryptsy and Mintpal didn't add MRO to coin voting?

I don't know, MRO isn't even on Mintpal voting list. I thought at least one of us would have been sent an email to suggest this coin ?

I asked to have Monero on the voting list. They said that they have no plans to add Monero.

At this point I think we must ignore Mintpal, now the Monero community sounds desperate to be their exchange. I couldn't care less with their attitude.
It doesn't matter (MintPal) and Its ignore from our !nvestors, Also Cryptsy have problem to MRO?
hero member
Activity: 994
Merit: 500
Why Cryptsy and Mintpal didn't add MRO to coin voting?

Because they don't want to do the work to integrate a coin that isn't bitcoin clone.

They will come around, Its a matter of stability at this point. They dont want to jeopardize it if something bad were to happen.
legendary
Activity: 2968
Merit: 1198
Why Cryptsy and Mintpal didn't add MRO to coin voting?

Because they don't want to do the work to integrate a coin that isn't bitcoin clone.
legendary
Activity: 1176
Merit: 1015
Why Cryptsy and Mintpal didn't add MRO to coin voting?

I don't know, MRO isn't even on Mintpal voting list. I thought at least one of us would have been sent an email to suggest this coin ?

I asked to have Monero on the voting list. They said that they have no plans to add Monero.

At this point I think we must ignore Mintpal, now the Monero community sounds desperate to be their exchange. I couldn't care less with their attitude.
sr. member
Activity: 302
Merit: 250
Imagine a world without hate and oppression
Why Cryptsy and Mintpal didn't add MRO to coin voting?

I don't know, MRO isn't even on Mintpal voting list. I thought at least one of us would have been sent an email to suggest this coin ?
I has been send email to Mintpal and Cryptsy own, For more profitable, we need add to Cryptsy or Mintpal.  Wink
TTM
full member
Activity: 140
Merit: 100
Why Cryptsy and Mintpal didn't add MRO to coin voting?

I don't know, MRO isn't even on Mintpal voting list. I thought at least one of us would have been sent an email to suggest this coin ?
sr. member
Activity: 302
Merit: 250
Imagine a world without hate and oppression
Why Cryptsy and Mintpal didn't add MRO to coin voting?
legendary
Activity: 1428
Merit: 1001
getmonero.org

...
Thanks for your help. Unfortunately, even after having done this, I am still unable to compile. This is the error message that I get:

Code:
# ./autogen.sh 
configure.ac:3: error: Autoconf version 2.69 or higher is required

I have autogen 2.63 installed:

Code:
# autoconf --version
autoconf (GNU Autoconf) 2.63

so if you have autogen 2.63 installed, and 2.69 or higher is required, I would think maybe upgrade to 2.69 or higher would fix your issue.

Oh yes! That is rather obvious.

The version that I have currently installed is the one available in the official repository. I am reluctant to change versions since this machine is a public web server (with a very low load and much CPU available) giving a real service. Is there any way of updating this package without undesired side effects?

Thats the problem. I have stated about this in wolfs thread that after updating autoconf it worked for ubuntu. So it should work. But its up to you to decide.
newbie
Activity: 25
Merit: 0
For the next 10 blocks found at minemro.com the block finder will get a 1MRO bonus.
Come and join us now, you may get lucky!
full member
Activity: 224
Merit: 100
I am trying to compile wolf's miner On my linux box (64 bit CentOS 6.5) with no luck so far.

Any hints about how to compile this miner on CentOS?

I am also trying to compile Luca's one on CentOS but with no luck. When i try to run minerd it just stops saying illegal instruction. If you find a solution please tell me...

In case jap1968 havent solved the problem, or for anyone else, all i had to do was to upgrade my gcc. Thanks Wolf that told me Smiley

http://ask.xmodulo.com/upgrade-gcc-centos.html


Thanks for your help. Unfortunately, even after having done this, I am still unable to compile. This is the error message that I get:

Code:
# ./autogen.sh 
configure.ac:3: error: Autoconf version 2.69 or higher is required

I have autogen 2.63 installed:

Code:
# autoconf --version
autoconf (GNU Autoconf) 2.63

so if you have autogen 2.63 installed, and 2.69 or higher is required, I would think maybe upgrade to 2.69 or higher would fix your issue.
legendary
Activity: 2968
Merit: 1198
There are a number of factors which contribute to orphans but they all stem ultimately from the one minute block time, which just too fast for an ad-hoc p2p type network. If you were running a centrally managed financial backbone (or you want to turn a coin into one) then you can probably optimize everything such that one minute blocks mostly work. But for a decentralized peer-to-peer system, it doesn't work.  

If you look at these coins, Monero (1 min) generally has the most orphans and Duck (4 min) the least, though this of course varies according to network conditions. Probably closer to 4 minutes might be right, given the high cost of verification. 2 minutes is the bare minimum.

However, I would add that orphans really aren't as bad as they seem. The block target is determined by the rate of accepted blocks. If there weren't orphans the difficulty would be correspondingly higher. Everything comes out about the same, except more overhead and other secondary factors which aren't great and should be addressed by increasing the block time and optimizing the code in other ways. But it really isn't a "waste" of hashes or anything like that.

Hm, I know that there's a whole lot going on that causes this .. do you have any decent links that I can read up on to understand the situation better? You describe the situation very well, and I'd like to know more about specifically how multiple block solutions propagate through the network vs. which one is ultimately settled on (as well as the type of network infrastructure that it is propagated on) .. but I don't really know where to look.

Satishi's paper described how one block is settled on, with the assumption of a random walk (not always correct, but correct to a point). As far as the actual network, there was another paper that measured bitcoin's propagation delays but I can't find it right now. There have also been some threads looking at propagation on ultra-fast coins such as DOGE (60 seconds), but again I can't find the links right now.

Also interesting to play with is a node simulator I remember seeing. I think someone posted a link to one on this thread, but at 200+ pages, it will be hard to find.
newbie
Activity: 56
Merit: 0
There are a number of factors which contribute to orphans but they all stem ultimately from the one minute block time, which just too fast for an ad-hoc p2p type network. If you were running a centrally managed financial backbone (or you want to turn a coin into one) then you can probably optimize everything such that one minute blocks mostly work. But for a decentralized peer-to-peer system, it doesn't work. 

If you look at these coins, Monero (1 min) generally has the most orphans and Duck (4 min) the least, though this of course varies according to network conditions. Probably closer to 4 minutes might be right, given the high cost of verification. 2 minutes is the bare minimum.

However, I would add that orphans really aren't as bad as they seem. The block target is determined by the rate of accepted blocks. If there weren't orphans the difficulty would be correspondingly higher. Everything comes out about the same, except more overhead and other secondary factors which aren't great and should be addressed by increasing the block time and optimizing the code in other ways. But it really isn't a "waste" of hashes or anything like that.

Hm, I know that there's a whole lot going on that causes this .. do you have any decent links that I can read up on to understand the situation better? You describe the situation very well, and I'd like to know more about specifically how multiple block solutions propagate through the network vs. which one is ultimately settled on (as well as the type of network infrastructure that it is propagated on) .. but I don't really know where to look.
sr. member
Activity: 560
Merit: 250
"Trading Platform of The Future!"
Can't you find his IP and have the server block it completely?
Too many IPs to manually block. I guess I can add https://github.com/pkrumins/node-iptables to the pool software to automatically block the IPs if they send malformed messages.
legendary
Activity: 1176
Merit: 1015
Address 454HDLDtqCLS24EsDAYorf9QAVkNqQPdJTaEBrdi9pVELUH6ZSU37VqV8UAoTYV7kX34w1NvpPrrM7F RA9BwWS8nFCGtWEK: please stop trying to mine on MoneroPool.org with simpleminer! Use cpuminer-multi instead.

cant you just disconnect him?
I've added a rule to iptables to drop all connections with "simpleminer" in the HTTP request, but it just. won't. work.  Huh

Code:
DROP       tcp  --  anywhere             anywhere             tcp dpt:5555 STRING match  "simpleminer" ALGO name bm TO 65535

The server is being flooded with this stupid lazyminer.

Can't you find his IP and have the server block it completely?
sr. member
Activity: 560
Merit: 250
"Trading Platform of The Future!"
Address 454HDLDtqCLS24EsDAYorf9QAVkNqQPdJTaEBrdi9pVELUH6ZSU37VqV8UAoTYV7kX34w1NvpPrrM7F RA9BwWS8nFCGtWEK: please stop trying to mine on MoneroPool.org with simpleminer! Use cpuminer-multi instead.

cant you just disconnect him?
I've added a rule to iptables to drop all connections with "simpleminer" in the HTTP request, but it just. won't. work.  Huh

Code:
DROP       tcp  --  anywhere             anywhere             tcp dpt:5555 STRING match  "simpleminer" ALGO name bm TO 65535

The server is being flooded with this stupid lazyminer.
full member
Activity: 224
Merit: 100
Extreme Pool

Come visit us at http://www.extremepool.org, the #1 Pool for Cryptonote Coins!!
We are starting this weeks promotion early for the MRO Pool:

This Weeks Promotion:
http://mro.extremepool.org
0% Fee

legendary
Activity: 2968
Merit: 1198
Where are all these orphans coming from? It's becoming harder to believe that it's entirely due to the 1 minute block times .. maybe that combined with the incredible mining speed increases we have now changes a few things...?

There are a number of factors which contribute to orphans but they all stem ultimately from the one minute block time, which just too fast for an ad-hoc p2p type network. If you were running a centrally managed financial backbone (or you want to turn a coin into one) then you can probably optimize everything such that one minute blocks mostly work. But for a decentralized peer-to-peer system, it doesn't work. 

If you look at these coins, Monero (1 min) generally has the most orphans and Duck (4 min) the least, though this of course varies according to network conditions. Probably closer to 4 minutes might be right, given the high cost of verification. 2 minutes is the bare minimum.

However, I would add that orphans really aren't as bad as they seem. The block target is determined by the rate of accepted blocks. If there weren't orphans the difficulty would be correspondingly higher. Everything comes out about the same, except more overhead and other secondary factors which aren't great and should be addressed by increasing the block time and optimizing the code in other ways. But it really isn't a "waste" of hashes or anything like that.
newbie
Activity: 56
Merit: 0
The cost of running a pool does increase the more miners you have, as you need more server resource and bandwidth, but it gets more efficient the bigger you get so 2% fees is quite profitable I suspect. Its a free market so miners can direct their hash where they like, perhaps they figure they get a lower orphan rate which compensates for the fee. I moved my pool to its own server with a direct Internet connection when I made it public, hopefully reducing the orphan rate, but then the network hash rate has gone up so much since it hasnt found any blocks so I can't compare to see if there is a difference Sad

Where are all these orphans coming from? It's becoming harder to believe that it's entirely due to the 1 minute block times .. maybe that combined with the incredible mining speed increases we have now changes a few things...?

Edit:

Quote from: Tacotime

To address the orphan issue, it's recommended that you directly connect your daemons to the other major MRO pools, mro.extremepool.org and moneropool.com. You should correspond to those admins so that their nodes are directly connected to you with "--add-priority-node arg", and possibly remove unrelated nodes, so that you can sync faster with these other large pools.

P2P backend code seems poorly optimized and takes a long time to sync as well, coupled with the heavy hashing algo makes orphans inordinately high compared to other networks.

Looks like they're already on it! only a matter of time now.
newbie
Activity: 56
Merit: 0
It will be interesting to see how MRO does relative to fiat during a BTC moonshot.  I expect this to be a pretty tame bubble, if it is one, but LTC has largely lost cred, and MRO might take its place as moon to sun, with value lagging BTC during the early phase, getting whipped up rapidly, and overshooting the gains in BTC relative to fiat, before relaxing again.

Yeah, It will be interesting to watch this one. This low was called well, and now both are going up. Exciting times!

With little holding it in place compared to BTC, it will probably easily experience an overshoot. Where will the new floor be?
sr. member
Activity: 252
Merit: 250
So if they are taking 2% it's only $400-500/day...
Is the cost of running a large pool zero?
Looks like they make their monthly cost in 12 hours from fees (estimation).

The cost of running a pool does increase the more miners you have, as you need more server resource and bandwidth, but it gets more efficient the bigger you get so 2% fees is quite profitable I suspect. Its a free market so miners can direct their hash where they like, perhaps they figure they get a lower orphan rate which compensates for the fee. I moved my pool to its own server with a direct Internet connection when I made it public, hopefully reducing the orphan rate, but then the network hash rate has gone up so much since it hasnt found any blocks so I can't compare to see if there is a difference Sad
Jump to: