Thanks! CoinDL does not support Flac, but I have converted it with FFMPEG and can email it to you if you PM me your address.
dafuq? u converted a MP3 to a FLAC? are you mad? |
|
|
|
Steps to reproduce: 1. Go to profile and change your password to something like 12345678" 2. Now logout and try to login again. 3. Notice that your new password 12345678" and your old password don't work anymore. Am I the only one who uses quotes in passwords?  try 12345678\" as password  if not then 12346789\\", increase the number of \  |
|
|
|
|
here we go:
PGrGhMb8kr9g6suueWcanSvt53y7aVsyyA
ty
|
|
|
|
now we just have to get rid of v5 and v7 ppl |
|
|
|
Using latest win32 builds for bfgminer I start seeing virus warnings: Here is the warning for 2.8.6 build:  and here is the one for 2.9.3:  I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Thanks, Jake pls just stfu... we dont need AV spam here seriously! |
|
|
|
So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node. Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion) So it doesn't include all the 1-diff shares generated by the miner ... ? No... pool hash rate is only determined by actual shares, which is accurate enough. So back to my original statement then. The pool hash rate reported is below the actual hash rate of the miners (like all pools) However, since p2pool has 60x the number of LP's compared to other pools, the actual hash rate is quite a bit higher than reported - whereas with a normal pool it shouldn't be more than about 1% higher (I typically get <0.4% for GPU/BFL/ICA and ~0.7% for MMQ) Yet in those ignored shares, if there is a valid Block, it will of course get through, so rather than the number of blocks being representative of the number of valid shares, it is in fact representative of the number of all work generated by all p2pool miners which is of course higher than the reported hash rate. So when people are reporting that p2pool is getting 110% luck consistently (which of course isn't possible - the probability of getting 110% over even 1 month is excessively unlikely) they are in fact not comparing the correct numbers. Yes p2pool may well now be averaging 100% as expected, but those > 100% numbers are the result of not comparing the correct numbers you can find a block with an orphaned share too! think of it as: with a 1diff share being stale on a normal pool u still can get a block (in relation to p2pool) |
|
|
|
is anybody else haveing a problem with avast tagging cpuminers as a trojan? ufasoft is also being tagged
dosnt matter. |
|
|
|
base 2 (using 1024) log(2^10) / log(2) = 10 log(1024) / log(2) 6.9314718055994530941723212145818 / 0.69314718055994530941723212145818 ... = 10 ... which makes sense: you can define 1024 as a binary 1 followed by 10x zeroes alternatively, as 1 plus the binary value of the largest 10-bit number (all 1s) as such, a 10 "bit" number has the first value of "zero" and the highest value you can express is 1023 (the 1024th in the sequence starting with zero)
base 10 (using 1 million) log(10^6) / log(10) = 6 log(1000000) / log(10) 13.815510557964274104107948728106 / 2.3025850929940456840179914546844 ... = 6 ... which makes sense: you can define one million as a decimal 1 followed by 6x zeroes alternatively, as 1 plus the decimal value of the largest 6-digit number (all 9s) as such, a 6 "digit" number has the first value of "zero" and the highest value you can express is 999999 (the millionth in the sequence starting with zero, discounting negatives, fractions, etc.)
34 "digit" (base 58) bitcoin address: log(58 ^ 34) / log(58) = 34 log(58 ^ 34) / log(58) log(9.0479831084470077531332721514049e+59) / log(58) 138.05506235857825744441714122988 / 4.0604430105464193366005041538201 ... = 34 So how many bits (binary) are required to store that? bitcoin address can be defined as 34 "digits" of base 58, therefore: log(58 ^ 34) / log(2) < 200 Wait, really? log(58 ^ 34) / log(2) log(9.0479831084470077531332721514049e+59) / log(2) 138.05506235857825744441714122988 / 0.69314718055994530941723212145818 199.17135383433745210447229303735 (round up to 200 bits) Similar math is used to determine how many bits of entropy exist in a given passowrd pattern. Bitcoin addresses DO NOT go up to 256 bits. They are basically only 160 bits, plus additional checksum / error-detection padding: (citation) - Technical background of version 1 Bitcoin addresses... potentially, it is possible to have a collision for which two different private keys (actually 256 bits) match up to the same bitcoin address (34 base 58 "digits" / 160 bits / whatever)
Another fun math thing. Earlier, someone was trying to figure out if 2^256 was closer to the number of atoms in the universe (or the visible universe, or a fraction of these atoms, or the atoms in a person) 2^256 atoms? Well, every "mol" of hydrogen atoms weighs 1 gram: (cite) -- Avogadro constant so aprox: 6.02214 * 10^23 great! Now for some math & logic time: (6.02214 * 10^23) = number of hydrogen atoms in 1 liter of hydrogen gas at standard temperature / pressure (ideal gas law) A liter of water weighs approximately 1000 grams (1 kg) A single water molecule weighs aprox 18 times as much as a single hydrogen atom Therefore, 55.5 mols of water in a liter (kilogram) 7.806 * 10^26 atoms in 70 kilograms of water. The human body is mostly water. Assuming we're mostly water, the human body has aprox 2^70 atoms 2^256 hydrogen atoms ... actually I'm just going to stop right now, converting to decimal and bypassing mass calculations: log(2^256) / log(10) ... you're already much closer to the number of atoms in the visible universe. ... Not to worry though, since there is no point in attempting to exhaust the 256 keyspace: Only 160 bits worth of hash used to generate bitcoin's 34 "digit" base 58 public key addresses, so you'll VERY likely have many many collisions well before you try a number of keypairs equal to the number of atoms on planet earth. well done, was too lazy for this |
|
|
|
OK, show me 5 or 6 blocks in a day when we are over 350 GH for the entire day and I will believe you. I know what variance is, but variance to the good when we are over 350 GH for 24 hours and I'm sold. It doesn't even need to be 5 or 6 blocks, just positive luck for that day.
The odds of having a 6-block day, when the hashrate is high, is quite low and simply due to variance. Not finding one isn't going to prove anything. Our 90-day moving average is over 110% of expected payout. That's impressive. Yes our 90 day moving average is impressive and it is being used to sugar coat or slick over the issue we are trying to bring up. Just because our overall luck is good does not mean we don't have a scalability problem. When we get those bumps in hash speed, the person/s that jumped on board usually see that their payouts are low because of the bad luck during the period they hopped on and they leave. That drops us back down in hash rate back to where the supposed scalability issue is no longer in play. So until we have a run of good luck in the 350+ GH range I and probably some others will still have doubts. i dont mind the variance, u still get more than all other pools, just not in a steady way  |
|
|
|
In mean time V9 is passing 40% of pool.
Trouble is, that V5+V7 is about 10%, so if those ppl will not switch to v9 95% hardfork will not happen soon...
Upgrade mates! Upgrade!
v8 update rush has worked after some time, then no fork. ppl disappointed -> longer time to do it now. |
|
|
|
use "patch < nameofpatchfile"
I'm on Win7. Is there a way for me to still do this? i dont support Winblow$ unless u pay me |
|
|
|
P2Pool release 9.0 tag: 9.0 hash: 2cb4d8381e179f71ea2075cdce948ea83cf0dc55 HARDFORK: Upgrade is required! Hardfork will happen after 95% of the pool's hash rate has upgraded. Everybody having not upgraded will be split off into a tiny P2Pool. Windows binary: http://u.forre.st/u/urxoztyg/p2pool_win32_9.0.zipSource zipball: https://github.com/forrestv/p2pool/zipball/9.0Source tarball: https://github.com/forrestv/p2pool/tarball/9.0Changes: * Transaction preforwarding Transactions that you're mining are sent to peers before you get a share, so any block solution you find can be broadcast virtually instantaneously. This could theoretically get our invalid block rate below any other pool's thanks to our large network of nodes. This was implemented in v8, but was prevented from taking effect due to a bug being discovered.* Stratum support in the P2Pool protocol. Stratum mining will be enabled in a future patch to v9. here u go |
|
|
|
I'm hoping a bunch of people have the gumption to point their ASICs to p2pool so we can get the hash rate up to lower the variance. (I know I intend to point at least one here...)
M
count me in |
|
|
|
So I saw a comment a while back about checking the compressed versions of the keys generated as well as the uncompressed versions and I've been playing with it a bit. It gives me a roughly 80-90% speed increase in both vanitygen and oclvanitygen and so far I haven't found any problems with the addresses generated, the only difference is needing to import them as compressed (not that I've done a lot of testing with them outside of plugging them into bitaddress.org). I did update vanitypool.thruhere.net to accept them as valid solutions (and promptly solved all the remaining work there) so unless someone submits more it isn't particularly useful for pool mining ATM (still getting half my work rejected by vanitypool.appspot.com but all the ones I have checked are correct, just compressed solutions it doesn't like). It does however seem to be quite useful if you are searching for your own vanity addresses. So what I have now is a very much hacked together version that works but is not particularly user-friendly (as in I commented out most of the error-checking code to get it to return all the results from the GPU and you then have to take the private key and convert to the compressed address manually) but for anyone capable of working with that here is the changes I made to calc_addrs.cl to make it work (notice I only changed the CL prefix checker, not the return for regex) 1209c1209
< hash_ec_point(uint *hash_out, __global bn_word *xy, __global bn_word *zip)
---
> hash_ec_point(uint *hash_out, uint *chash_out, __global bn_word *xy, __global bn_word *zip)
1211c1211
< uint hash1[16], hash2[16];
---
> uint hash1[16], hash2[16], hash3[16], hash4[16];
1262a1263,1283
>
> hash4[0] = hash1[0] ^ 0x06000000;
> if(wh & 0x01){ hash4[0] ^= 0x01000000; }
> hash4[1] = hash1[1];
> hash4[2] = hash1[2];
> hash4[3] = hash1[3];
> hash4[4] = hash1[4];
> hash4[5] = hash1[5];
> hash4[6] = hash1[6];
> hash4[7] = hash1[7];
> hash4[8] = (hash1[8] & 0xff000000) | 0x800000;
> hash4[9] = 0;
> hash4[10] = 0;
> hash4[11] = 0;
> hash4[12] = 0;
> hash4[13] = 0;
> hash4[14] = 0;
> hash4[15] = 33 * 8;
> sha2_256_init(hash3);
> sha2_256_block(hash3, hash4);
>
1300a1322,1326
> #define chash_ec_point_inner_6(i) \
> hash3[i] = bswap32(hash3[i]);
>
> hash256_unroll(chash_ec_point_inner_6);
>
1310a1337,1347
>
> hash3[8] = bswap32(0x80000000);
> hash3[9] = 0;
> hash3[10] = 0;
> hash3[11] = 0;
> hash3[12] = 0;
> hash3[13] = 0;
> hash3[14] = 32 * 8;
> hash3[15] = 0;
> ripemd160_init(chash_out);
> ripemd160_block(chash_out, hash3);
1318c1355
< uint hash[5];
---
> uint hash[5], chash[5];
1331c1368
< hash_ec_point(hash, points_in, z_heap);
---
> hash_ec_point(hash, chash, points_in, z_heap);
1376c1413
< uint hash[5];
---
> uint hash[5], chash[5];
1389c1426
< hash_ec_point(hash, points_in, z_heap);
---
> hash_ec_point(hash, chash, points_in, z_heap);
1417a1455,1480
> high = -1;
> }
> }
>
> #define chash_ec_point_search_prefix_inner_1(i) \
> chash[i] = bswap32(chash[i]);
>
> hash160_unroll(chash_ec_point_search_prefix_inner_1);
>
> /* Binary-search the target table for the hash we just computed */
> for (high = ntargets - 1, low = 0, i = high >> 1;
> high >= low;
> i = low + ((high - low) >> 1)) {
> p = hash160_ucmp_g(chash, &target_table[10*i]);
> low = (p > 0) ? (i + 1) : low;
> high = (p < 0) ? (i - 1) : high;
> if (p == 0) {
> /* For debugging purposes, write the hash value */
> found[0] = ((get_global_id(1) * get_global_size(0)) +
> get_global_id(0));
> found[1] = i;
>
> #define chash_ec_point_search_prefix_inner_2(i) \
> found[i+2] = load_be32(chash[i]);
>
> hash160_unroll(chash_ec_point_search_prefix_inner_2);
Noob question: how do I make these changes to calc_addrs.cl? use "patch < nameofpatchfile" |
|
|
|
No I just write all my own php to talk to bitcoind But to identify ~50% of blocks you just look in the coinbase transaction: The strings I used to look for were: 'slush' => 'Slush',
'BTC Guild' => 'BTC Guild',
'ozco.in' => 'OzCoin',
'EclipseMC' => 'EclipseMC',
'Eligius' => 'Eligius',
'simplecoin.us' => 'SimpleCoin', // 171650
'BitLC' => 'BitCL', // 171638
'BitMinter' => 'BitMinter', // 171617
'nmcbit.com' => 'NMCBit', // 172774
'bitclockers' => 'BitClockers', // 174478
'mkalinin.ru' => 'Mkalinin', // 174585
'Triplemining.com' => 'Triplemining', // 175144
'MaxBTC' => 'MaxBTC', // 175144
'CoinLab' => 'CoinLab' // 197765
You can see how old the info is As for the other 50% - the problem there is you have to go to the pools (like deepbit) to get the info. care to share? |
|
|
|
Ya know what.. dude... since you seem to imply that there are tons of options for cuda miners.... Link me to some windows CUDA miners that don't require me to switch to linux or switch pools. Otherwise, kindly f-off. I'm not Kano, but... Cgminer does mine on Nvidia hardware and has a Windows version supplied on each release. You can also compile your own binary by following the included "windows-build.txt" file as a guide. You can download it from one of the links in the OP at this forum thread https://bitcointalk.org/index.php?topic=28402.0 . As far as Cgminer using too much CPU, that seems odd to me as Cgminer is designed to use very little CPU. Maybe you have a driver issue? Kano is Australian, and in my opinion/experience they tend to come off a bit brash. Once you realize that and account for it, communicating with them will go much smoother. I used to play an online game with several Australians and that is how they were as well. Remember, the Bitcoin community is made up of many nationalities/cultures. I dont think its about Australians, i do understand him. Im from switzerland and would react the same way. Its like "dont tell me how it works, i know how it works and your talking just bullshit. dont try to teach a geek if ur a newbie". |
|
|
|
wait u tell someone not do to a stupid thing, afterwards you tell him if you do the stupid thing a bit different its no longer stupid? sry but hiding first 11 characters dosnt help at all too... |
|
|
|
seems like a winblows user with mspaint |
|
|
|
(may i ask why we need stratum support when you are acutally using some kind of stratum when mining on P2Pool)
More efficient communication between your P2Pool node and your miner. One Stratum work unit could supply an ASIC miner with a virtually infinite amount of work, as opposed to a getwork work unit, which gives 4 GH of work. less load for the overall system |
|
|
|
i0coin, is there still a need for devcoind build for ARM6? https://bitcointalk.org/index.php?topic=101559.msg1308335#msg1308335No but you can compile/run it on your rpi and grab the fup bounty: The next person who puts devcoin on the Raspberry Pi will get the remaining 2 share award. BTW. I heisse icoin, i0coin isch glaubi e chain wo nümm ghandled wird grins. Aber wenn du us basel bisch denn suug mol bi de Asian Food Express http://www.asianfood.ch a bitte und frog ob sie au Bitcoin als bezahlig akzeptiere Dä chönti das easy i siis oscommerce ibaue, aber meint es gäbi zwenig nochfrog noch bitcoin zahlig PM'd |
|
|
|
|
Show Posts
