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

[eizh]

i think its moneropool.com

Oh, they seem to be two separate pools.

Yes, they are separate pools. Is anyone getting "400 Bad Request" when trying to access moneropool.org?

Yep, bad request.

This?: http://moneropool.org/

It works fine for me.

Pool
 Hash Rate: 2.27 KH/sec
 Block Found: Never
 Round Hashes: 81574063
 Connected Miners: 47
 Mining Fee: 0%

[1715379760]

1715379760

[1715379760]

1715379760

[1715379760]

1715379760

[surfer43]

I contacted support of the domain registrar and they said they fixed it. It was working for some people and for me it was going in and out.

[alphacenturion]

New Pool up...
http://extremepool.org

let me know what you think

Awesome mate - Im mining with my terrible i3 but its working! Great work!

[polecrab]

i'm also waitting for a optimized cpu minning tool, it seems that somebody has that version, now it's unfair for vs whice use the old tool~~

Why would you do that when mining with the existing miner is still very profitable? (And I would add does not risk wasting your time mining unspendable coins or other problems, as happened to people using another too-hastily-released mining tool.) Testing is good. Be patient.

I mined with 4x Core i7 3770 for four days straight and didn't find a block. doesn't seem profitable to me. was I just unlucky?

so do i , i didn't find any block these days, maybe more than 3 days,

What is your hashrate (show_hr)?  Just divide it into the current global hashrate to get an idea of your chance to find each block. Times the blocks per day (1440) to get the daily chance. My hashrate is 20 with 4 core i7 3820, that's about one chance per 20 days for me at current global hash of around 620 KH/s. So you need to be patient to solo mine now. The difficulty is increasing rapidly, it has quadrupled in the last week. That's why pools are becoming more important now.

[nakaone]

Error: mixin_count should be non-negative integer, got <1>

[gringenmarten]

I will close the Giveaway at 01:00 UST.

So get your free MRO today, before it's too late. Reddit thread

Very nice project, looking to the future ☺
Thank you ☺

41unF6HRS6Y1Yw51PCmuUFDW8YFXzhL85h3AVyzJmUQJC4JdVjAXH3RKcBkRs45kzY5ZqxXApa2DXUb efeYMt6VpNnFTswn

[eizh]

Error: mixin_count should be non-negative integer, got <1>

Did you put <1> or 1? It should just be 1 (or 0, 2, 3, ...).

[Keyboard-Mash]

Hey, so I was doing some thinking. If we just maximize the size of every block by moving a lot of money around .... would that fend off botnets by creating low subsidies?

Or would it be counterproductive because it would leave us w/ a high difficulty?

Thoughts?

[polecrab]

how much time to sync without the blockchain? I cant realize where to put the chain in order for the wallet to use it. srsly.

long time.

are you on windows 7 or 8? If so, it goes here: C:\Users\%username%\AppData\Roaming\Bitmonero\blockchain.bin

thank you very much, it synched alright, but now when I open my wallet.bin it says it couldnt connect to daemon host:8080 w/e ....

Can you provide more details of what you are doing, what platform, commands etc.  You error message refers to a different port from when I try to start wallet without daemon running:

F:\>simplewallet.exe --wallet-file wallet.bin
bitmonero wallet v0.8.6.295(0.1-g7620d55)
password: ********************
Opened wallet: $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
Error: wallet failed to connect to daemon (http://localhost:18081). Daemon either is not started or passed wrong port. P
lease, make sure that daemon is running or restart the wallet with correct daemon address.
**********************************************************************
Use "help" command to see the list of available commands.
**********************************************************************
[wallet xxxxxxx]:

[33zer0w0lf]

New Pool up...
http://extremepool.org

let me know what you think

Awesome mate - Im mining with my terrible i3 but its working! Great work!

thank you!

[smooth]

un-de-optimizations

I was skeptical of this conspiracy theory at first but after thinking about the numbers and looking back at the code again, I'm starting to believe it.

These are not deep optimizations, just cleaning up the code to work as intended.

At 100 H/s, with 500k iterations, 70 cycles per L3 memory access, we're now at 3.5 GHz which is reasonably close. So the algorithm is finally memory-bound, as it was originally intended to be. But as delivered by the bytecode developers not even close.

I know this is going to sound like tooting our own horn but this is another example of the kind of dirty tricks you can expect from the 80% premine crowd and the good work being done in the name of the community by the Monero developers.

Assuming they had the reasonable, and not deoptimized, implementation of the algorithm as designed all along (which is likely), the alleged "two year history" of bytecoin was mined on 4-8 PCs. It's really one of the shadiest and sleaziest premines scams yet, though this shouldn't be surprising because in every type of scam, the scams always get sneakier and more deceptive over time (the simple ones no longer work).

I always suspected, strongly, but now the evidence is coming together.

[Keyboard-Mash]

Hey, so I was doing some thinking. If we just maximize the size of every block by moving a lot of money around .... would that fend off botnets by creating low subsidies?

Or would it be counterproductive because it would leave us w/ a high difficulty?

Thoughts?

More on this:

Large size blocks incur a penalty on mining subsidy. Take a look at http://monerochain.info/

The largest block sizes yield very few MRO. If all blocks were full, the incentive to continue mining via botnet is reduced to the point where there is no point to mine with massive farms and you'd just be burning electricity for 1 MRO instead of 16. Granted this falls back on all miners, but provided the cost to single people per computer is much less than the cost of one person incurring a heavy loss of predicted income ... then I would imagine they would conclude that there's no reason to mine.

IE we've been given a weapon to combat heavy mining that has a larger impact to one person controlling 10% of the net hash than one person with .001% of the net hash.

Following through on this, it would give a rational reason to keep the velocity of money extremely high otherwise it ends up in the hands of very few people.

[smooth]

Hey, so I was doing some thinking. If we just maximize the size of every block by moving a lot of money around .... would that fend off botnets by creating low subsidies?

Or would it be counterproductive because it would leave us w/ a high difficulty?

Thoughts?

More on this:

Large size blocks incur a penalty on mining subsidy. Take a look at http://monerochain.info/

The largest block sizes yield very few MRO. If all blocks were full, the incentive to continue mining via botnet is reduced to the point where there is no point to mine with massive farms and you'd just be burning electricity for 1 MRO instead of 16. Granted this falls back on all miners, but provided the cost to single people per computer is much less than the cost of one person incurring a heavy loss of predicted income ... then I would imagine they would conclude that there's no reason to mine.

IE we've been given a weapon to combat heavy mining that has a larger impact to one person controlling 10% of the net hash than one person with .001% of the net hash.

Following through on this, it would give a rational reason to keep the velocity of money extremely high otherwise it ends up in the hands of very few people.

Won't really work because the block size limit increases adaptively. If you keep getting full blocks, the maximum size goes up. See "adaptive parameters" in the cryptonote documents.

[dga]

un-de-optimizations

I was skeptical of this conspiracy theory at first but after thinking about the numbers and looking back at the code again, I'm starting to believe it.

These are not deep optimizations, just cleaning up the code to work as intended.

At 100 H/s, with 500k iterations, 70 cycles per L3 memory access, we're now at 3.5 GHz which is reasonably close. So the algorithm is finally memory-bound, as it was originally intended to be. But as delivered by the bytecode developers not even close.

I know this is going to sound like tooting our own horn but this is another example of the kind of dirty tricks you can expect from the 80% premine crowd and the good work being done in the name of the community by the Monero developers.

Assuming they had the reasonable, and not deoptimized, implementation of the algorithm as designed all along (which is likely), the alleged "two year history" of bytecoin was mined on 4-8 PCs. It's really one of the shadiest and sleaziest premines scams yet, though this shouldn't be surprising because in every type of scam, the scams always get sneakier and more deceptive over time (the simple ones no longer work).

I always suspected, strongly, but now the evidence is coming together.

I can't comment on the motivations of the developers, but I concur with Noodle.  The algorithm is actually very straightforward, and the code involved a _lot_ of unnecessary data movement, function call overhead, and uint8_t * manipulation that prevented the compiler for doing a reasonable job of optimizing it.

It could be that someone was trying to write the code to express the way they were thinking about it and that it had the effect of slowing it down, but there's certainly something odd about it.

Particularly given the elegance of the algorithm itself -- it's basically scrypt using AES as a mixing function, alternating with a 64 bit multiplication.  The core difference is that it writes back to the scratchpad, making verification more costly, but preventing some of the LOOKUP_GAP optimizations used for scrypt coins.  It's nicely designed and done, as far as my non-cryptographer eyes can tell.

[surfer43]

Windows users of simpleminer with moneropool.org should update to the latest simpleminer: https://drive.google.com/folderview?id=0B7RQILpPGrQbR1R4WDF6SVhwdW8&tid=0B7RQILpPGrQbYnF2OTA4NklrWmc

Mac users of simpleminer with moneropool.org should also update to the latest simpleminer: https://drive.google.com/folderview?id=0B7RQILpPGrQbVXlCaHFiNEdDdG8&tid=0B7RQILpPGrQbYnF2OTA4NklrWmc

Linux users of simpleminer with moneropool.org should ensure their simpleminer was built from source after May 12th: https://github.com/monero-project/bitmonero/

The downloads in the first post are too outdated to work with the long polling I've just enabled for moneropool.org. The reason I enabled long polling is because of the high amount of orphaned blocks the pool is submitting.

[smooth]

I can't comment on the motivations of the developers, but I concur with Noodle.

I likely concur with Noodle too, except that Noodle didn't write the message to which you replied. I actually haven't discussed this with Noodle at all, but as I'm pretty sure anyone competent looking at the code would agree, I'm sure he does to.

BTW, a lot of the straightforward data movement gets optimized away by a decent compiler (possibly all of it, once the other problems are fixed, or at least enough of it to get close to memory bound) and there is nothing wrong with writing the (HLL source) code in a more algorithmically-descriptive way. There are other problems there too, though, with no such excuse.

[perl]

My pool monero is online now .
I have make the test 1 day for test payout after many bugfix.

For information results of my test.
Balance Wallet Pool : 237.317623027057
Balance all Miner:  11391.923505695693
Tunning fee is : 2%
237.317623027057 / 11391.923505695693 = 0,020832094

http://monero.crypto-pool.fr/

[surfer43]

The payment bug for moneropool.org has been fixed, except it still can't pay out because someone has mined with an invalid address. Once this is resolved through address validation, everyone will be paid. 

Payments for the first 9 blocks will be honored, even though 7 of those blocks were orphaned.

[eizh]

My pool monero is online now .
I have make the test 1 day for test payout after many bugfix.

For information results of my test.
Balance Wallet Pool : 237.317623027057
Balance all Miner:  11391.923505695693
Tunning fee is : 2%
237.317623027057 / 11391.923505695693 = 0,020832094

http://monero.crypto-pool.fr/

Only about 24000 coins are produced by the network each day so 11400 coins already mined by one pool doesn't make sense to me. Can you elaborate? What is this pool's true hashrate? (The pool website only says 60 H/s right now.)

[mmx888]

The payment bug for moneropool.org has been fixed, except it still can't pay out because someone has mined with an invalid address. Once this is resolved through address validation, everyone will be paid. 

Payments for the first 9 blocks will be honored, even though 7 of those blocks were orphaned.

How to check my address?