 Show Posts
|
|
Pages: « 1 [2] 3 4 5 »
|
[2011-12-26 20:35:56] thread 0: 28662 hashes, 5.71144 khash/s
[2011-12-26 20:35:56] thread 5: 28420 hashes, 5.71091 khash/s
[2011-12-26 20:35:57] thread 1: 28132 hashes, 5.72506 khash/s
[2011-12-26 20:35:57] thread 6: 28644 hashes, 5.63936 khash/s
[2011-12-26 20:35:58] thread 2: 28580 hashes, 5.71380 khash/s
[2011-12-26 20:35:58] thread 7: 27310 hashes, 5.67194 khash/s
[2011-12-26 20:35:59] thread 3: 28146 hashes, 5.72380 khash/s
[2011-12-26 20:36:00] thread 4: 28300 hashes, 5.64322 khash/s
(@ ubuntu server 64-bit with xeon) that's amazing. |
|
|
|
Test results: Linux x86-64, Intel Xeon, before (artforz, modified speed output): [2011-12-20 13:02:41] thread 6: 15074 hashes, 3.01210 khash/sec
[2011-12-20 13:02:42] thread 7: 14079 hashes, 2.96454 khash/sec
[2011-12-20 13:02:42] thread 0: 14959 hashes, 2.99386 khash/sec
[2011-12-20 13:02:44] thread 1: 14920 hashes, 2.97748 khash/sec
[2011-12-20 13:02:44] thread 3: 14619 hashes, 2.87325 khash/sec
[2011-12-20 13:02:45] thread 2: 14765 hashes, 2.93248 khash/sec
[2011-12-20 13:02:45] thread 4: 15090 hashes, 3.01685 khash/sec
[2011-12-20 13:02:45] thread 5: 15079 hashes, 2.89249 khash/sec
[2011-12-20 13:02:46] thread 6: 15061 hashes, 3.01753 khash/sec
after (modified speed output): [2011-12-20 13:06:44] thread 5: 20551 hashes, 4.28743 khash/s
[2011-12-20 13:06:45] thread 0: 21568 hashes, 4.31442 khash/s
[2011-12-20 13:06:45] thread 1: 20840 hashes, 4.18909 khash/s
[2011-12-20 13:06:46] thread 6: 21690 hashes, 4.33446 khash/s
[2011-12-20 13:06:48] thread 2: 21572 hashes, 4.30622 khash/s
[2011-12-20 13:06:49] thread 3: 21128 hashes, 4.27796 khash/s
[2011-12-20 13:06:49] thread 7: 21588 hashes, 4.25990 khash/s
[2011-12-20 13:06:49] thread 5: 21438 hashes, 4.32439 khash/s
[2011-12-20 13:06:50] thread 4: 21709 hashes, 3.77865 khash/s
Windows 32-bit, Intel Core 2 Duo, before(amdfam10-sse4a): [2011-12-20 13:15:10] thread 1: 6553 hashes, 1.40 khash/sec
[2011-12-20 13:15:10] thread 0: 6553 hashes, 1.38 khash/sec after: [2011-12-20 13:17:05] thread 0: 16422 hashes, 3.49 khash/s
[2011-12-20 13:17:06] thread 1: 16346 hashes, 3.46 khash/s Windows 32-bit, AMD Phenom II X4, before(amdfam10-sse4a): [2011-12-20 13:22:01] thread 1: 9101 hashes, 1.70 khash/sec
[2011-12-20 13:22:04] thread 0: 6965 hashes, 1.76 khash/sec
[2011-12-20 13:22:04] thread 3: 9362 hashes, 1.87 khash/sec
[2011-12-20 13:22:05] thread 2: 8364 hashes, 1.62 khash/sec after: [2011-12-20 13:28:24] thread 1: 12141 hashes, 2.39 khash/s
[2011-12-20 13:28:24] thread 0: 11528 hashes, 2.31 khash/s
[2011-12-20 13:28:24] thread 2: 12009 hashes, 2.45 khash/s
[2011-12-20 13:28:24] thread 3: 11708 hashes, 2.35 khash/s Splendid! |
|
|
|
|
EDIT:
ahh nvm i'm soooooo stupid....
forgot the $ sign.... and my friend and I didn't noticed that...
|
|
|
|
A question about the API: Currently the API is like this (in php print_r() format): Array
(
[user] => Array
(
[total_rewards] => 0.0
[paid_rewards] => 0.0
[unpaid_rewards] => 0.0
[past_24h_rewards] => 0.0
)
[workers] => Array
(
[user.worker] => Array
(
[hash_rate] => 0.0
[valid_shares] => 0
[stale_shares] => 0
)
)
[pool] => Array
(
[hash_rate] => 697
[pps_rate] => 0.00096512
)
[network] => Array
(
[hash_rate] => 22763
[difficulty] => 0.76679615
)
) All the workers' names include a dot, and it's 500 if I use the data like this: echo $lp["workers"]["user.worker"]["hash_rate"];
How to use it correctly? |
|
|
|
I don't know if this has already been brought up or not, but.. Pyramid scheme
Since the aforementioned reasons mean Litecoin has no future potential, it effectively functions as a pyramid scheme, rewarding those who get in sooner at the expense of those who adopt it just before it finally fails (and are left with nothing). This is not the case for Bitcoin, since it has significant potential to become a long-term currency and continually be beneficial to adopters no matter when they begin using it. https://en.bitcoin.it/wiki/Litecoin  and it's protected now because of a latest violation of RR3 (I know they don't have that rule, so edit war?). however litecoin and solidcoin are the only cc`s on bitcoin wiki  |
|
|
|
Can someone explain me how to remove keypairs from wallet.dat?
I need to remove one address . . .
seems like pywallet will do that. (You might need the private key to delete the address( (haven't tried). You can also use pywallet to get the private keys from your wallet.) Is your wallet spammed? |
|
|
|
|
Since I'm not running a bitcoin daemon now, I'll pay by withdrawing from exchange to your address (or I'll pay from my wallet if you request that).
I'll do that before 1515 GMT if all things are working smoothly.
|
|
|
|
Anyway, is the TX spam now completely over officially or is there some other drips of dust left ? How do I scrub my wallet ?
According to block explorer, the dust spam is still there. Use 0.5.0.8 (50008) client to move your coins; by default txes below 0.0001 is ignored now when creating a new tx. (Haven't tried though, just saw the line in getinfo) |
|
|
|
Maybe the ppl here just don't care about it. However I'm interested AND i'll pay in the original price. only one question: any time limit on activating? I may need this in the near future but not now. |
|
|
|
The point is spending those coins will slow down the client right now b/c it takes forever to collect enough 0.00000001 LTC to make up a large enough value to send. So I changed the create transaction code to ignore these tiny values by default to speed things up. If you really want to spend them and wait forever for the client to create the transaction, you can by passing in a tiny min input. You could also ignore these transactions (under the min amount) when checking blocks for wallet transactions. It will help improve the general performance of the wallet going forward too. it now takes about half a minute to load the blockchain on my server. If it can improve the loading process it would be great. |
|
|
|
|
How to dump all private keys from a wallet without the mess of txes?
I need to dump some private keys from my spammed wallet but pywallet's dump also "take care" of those txes. Then my server nearly dead because pywallet ate up almost all ram and swap.
the reason I wanted the private keys is my vanity address (below). I didn't save the private keys to another place but i still want to keep the address (took 12hr to generate that.)
|
|
|
|
|
Hmmm I'm receiving lots of micro transactions today. Mostly to my public address in my signature.
Was wondering where are they come from...
|
|
|
|
Hi, On your site you said this: (In case you are wondering, 65536 is the average number of hashes to be computed in order to find a share. This is not the same... IMO You should change it to "65536 is the average number of shares to be computed in order to solve a block on difficulty 1". As you set the pool's small target to 16 bit, it takes 65536 shares to find a block on average. So, the way the earning are calculated should based on shares. The figures are just happened to be the same, as 65536(hashes/share) * 65536(shares/block) = 4294967296 = 2^32(hashes/block). Just think, if you change the small target to 15 bit, the effective difficulty for miners are actually decreased, thus more shares are required to solve a block(131072), and to find a share you only need 32768 hashes. In that case the PPS should be 47.5 LTC / (131072 × Current Difficulty), not multiplied by 32768 on the denominator. |
|
|
|
Sorry, misread, meant effective indeed.
Looks like it's moving average? (look at the first pool block) i got to that yesterday aswell currently it's 24963. Sounds reasonable well lets have a look ... i got that far yesterday aswell first of i use bcpow(2, 16) = 65536 so yea bcpow(2,16)*0.38087351 = 24963 reason i think was something wrong is if start to change the 16 nothing makes sense -.- lowering the 16 lowers the result wich shuld higher since it would make the shares easier = more of them, but it lowers the result maybe just me thinking to much over it but hey  id wanted to be sure before put on page rather have a none working there then an inacurate i cant defend hmm why does 16 change? it's set by you on the pushpoold 24693 means at current network difficulty and your set easy target, it tooks 24693 proof of works(shares) to solve a block. So when network diff. changes it changes as well. |
|
|
|
localhost the estimated diff ? no suchh thing theres effective, the red line: = effective diff theres actual, the blue: the actual diff for each block reason green isnt working is the pool uses rpc.retarget.bits=16, and i havent gotten head around how to make the formula to calc avg shares for a block on certain diff with retarget on feel free to drop some working math lol i was sick yesterday i looked at before heading to bed with no luck.... gonna make my coffee and have a look during the day Then it should be 65536*diff 65536 comes from 1/1.525878906e-05 currently it's 24963. Sounds reasonable |
|
|
|
Now that you mention it, what's supposed to be the difference between actual and estimated diff on the graph there? http://pool-x.eu/blocksAuthThe actual diff is not working, and what's est. diff? |
|
|
|
|
I mean the easy target the pool gives out to the miners. That target is much easier than current network target. I dunno how to call them...
|
|
|
|
Hi g2x3k, The `actual difficulty` graph on Block Stats page is not working now. Looks like it's currently calculated by diff*100, so I assume it's used for PoW diff 0.01. Your pool's PoW diff is not 0.01 right...? mrx@SERVER:~$ ./diffcalc 0000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
target = 0000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
nBits = 0x1f00ffff
difficulty = 1.525878906e-05
That target comes from direct curl and reversed... |
|
|
|
|
