Bitcoin Forum
October 08, 2024, 09:44:12 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 [99] 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 ... 2126 »
  Print  
Author Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency  (Read 4670681 times)
eizh
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



View Profile
May 16, 2014, 10:37:35 PM
 #1961

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%
surfer43
Sr. Member
****
Offline Offline

Activity: 560
Merit: 250


"Trading Platform of The Future!"


View Profile
May 16, 2014, 10:39:37 PM
 #1962

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
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
May 16, 2014, 10:53:27 PM
 #1963

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
Member
**
Offline Offline

Activity: 68
Merit: 10


View Profile
May 16, 2014, 11:39:46 PM
 #1964

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
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500


View Profile
May 17, 2014, 12:35:26 AM
 #1965

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

Huh
gringenmarten
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile
May 17, 2014, 12:39:14 AM
 #1966

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
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



View Profile
May 17, 2014, 12:50:00 AM
 #1967

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

Huh

Did you put <1> or 1? It should just be 1 (or 0, 2, 3, ...).
Keyboard-Mash
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
May 17, 2014, 12:50:56 AM
 #1968

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
Member
**
Offline Offline

Activity: 68
Merit: 10


View Profile
May 17, 2014, 12:52:28 AM
 #1969

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:

Quote
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
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile WWW
May 17, 2014, 01:16:10 AM
 #1970

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!

http://www.extremepool.org (BCN) (MRO) (QCN) (XDN) (BBR) (AEON) (ORION) (DSH) (CRR) (INF8)
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 17, 2014, 01:18:19 AM
 #1971

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
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
May 17, 2014, 01:28:15 AM
 #1972

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
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 17, 2014, 01:35:42 AM
 #1973

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
Hero Member
*****
Offline Offline

Activity: 737
Merit: 511


View Profile WWW
May 17, 2014, 01:42:10 AM
 #1974

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
Sr. Member
****
Offline Offline

Activity: 560
Merit: 250


"Trading Platform of The Future!"


View Profile
May 17, 2014, 01:45:21 AM
 #1975

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
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 17, 2014, 01:47:07 AM
 #1976

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
Legendary
*
Offline Offline

Activity: 1918
Merit: 1190


View Profile
May 17, 2014, 01:53:38 AM
 #1977

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
Sr. Member
****
Offline Offline

Activity: 560
Merit: 250


"Trading Platform of The Future!"


View Profile
May 17, 2014, 02:07:00 AM
 #1978

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.  Smiley

Payments for the first 9 blocks will be honored, even though 7 of those blocks were orphaned.
eizh
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



View Profile
May 17, 2014, 02:12:01 AM
 #1979

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
Member
**
Offline Offline

Activity: 90
Merit: 10


View Profile
May 17, 2014, 02:22:24 AM
 #1980

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.  Smiley

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

How to check my address? Huh Huh
Pages: « 1 ... 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 [99] 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 ... 2126 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!