You spend $3 on this cable and paypal gave you $25? Where do I sign up for this deal?  |
|
|
|
I think the miner chooses the timestamp. Most do not (if any). The pool just gives the miner 1024-bits + 256-bits of data, the miner chugs along changing 32-bits of it, until it runs out of possibilities for that 32-bit number (or it gets new work). Those 32-bits are called the nonce, by the way. In my post, the 60 BTC in 30 days was an approximation! Just to clear this up, you'd get 50 BTC in the same amount of time whether you mined at a pool or solo. On average. Of course, in reality, for pooled mining you're more likely to get less (compared to solo) due to stale shares, pool fees, and loss of generation fees. The pool can't dictate the reward because it would have to control more than 50% of the total compute power and run a botched client that gives the pool more than 50btc power block. However if a pool did control more than 50% then this would be possible. Controlling >50% of Bitcoin's hashing power does not let you changing the rules. Giving yourself more than 50BTC as part of the Generation Transaction would make that block invalid to all official clients. i.e. you've just made useless money that nobody will recognize as valid. The clients enforce a set of rules on the blocks, regardless of who "controls" the network. So controlling the network doesn't actually gain you very much. You can read more about it on the wiki, which I will quote here: An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
Reverse transactions that he sends while he's in control
Prevent some or all transactions from gaining any confirmations
Prevent some or all other generators from getting any generations
The attacker can't:
Reverse other people's transactions
Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
Change the number of coins generated per block
Create coins out of thin air
Send coins that never belonged to him What attack could there possibly be? My hash only works for the exact block and modifying details doesn't work. I would only have two options: report the block to be found or not. How would the latter possibly be an attack? What am I missing? If you're mining against a PPS pool, for example, you're getting paid immediately for every share you submit. Now, while doing that, withhold any shares you've found that would result in the pool getting a block. You're still getting paid the same amount of money (-1 share in a million), but the pool is getting less found blocks. |
|
|
|
|
phelix: Great information, thank you!
I'm wondering if I can take the plastic casing off, and set some regular ole computer cases fans on it. Not sure if that will pump enough air to keep it cool.
|
|
|
|
Works great for me. Yay! It's also possible to clone fpgaminer's poclbm-phatk git repo, then merge luke-jr's branch for better console output into it. Thank you for checking that! I was going to look into luke-jr's branch as well, so I could get a good figure on the # of stales I'm getting. Since you've confirmed the merge is simple, I'll try doing that soon. Sadly it causes a kernel trap after a few minutes of work, I'm using it onto a LinuxCoin pc with two 5850s which has been working ok with phoenix (apart from the hang problem) for more than three weeks. Woah, weird. Have you ever run poclbm on that machine before? This is interesting and yeah, how do we make this work? A simple guide maybe? Thanks! Linux or Windows? On Linux you just: git clone git://github.com/progranism/poclbm fpgaminer-poclbm And then use it like a regular version of poclbm. For Windows ... well ... I'd have to get PyOpenCL and stuff up and running and see if I can package something together. |
|
|
|
Anyways, my question is this: How fast am I hashing? 80 MHz at CONFIG_LOOP_LOG2 should be 10MH/s. If you're seeing 25MH/s at a pool then perhaps you've been lucky? Over what timespan is that average made? First off, I'd like to say that I totally love this project. I've been out of the loop in terms of hardware design for the last 3-4 years and this project is giving me the motivation to get back into it That's great! Makes me happy to spread the FPGA love |
|
|
|
|
Let me know if it works okay. I've been running it since I posted and so far none of the instances have failed. However I haven't measured stale share ratio yet; I was getting 0.1% with the old version of phoenix I had which was very nice.
|
|
|
|
"Work" in the case of mining is a 1024-bit string returned by the server. The miner must then adjusts a 32-bit value within there, called the nonce, from 0 to 4,294,967,296; hashing it every time to see if the resulting hash is "valid." Because of the way hashing works, the miner may find that no nonces result in a valid hash; or it may find that many nonces result in valid hashes. This is, as you've discovered, just the way luck works in the mining game. After the miner has checked all 0 to 4,294,967,296 possible values for nonce, it cannot do any more work on those 1024-bits it received. It must get new work from the server. Your miners are probably requesting work every 45-50 seconds because that's how long it takes to run through all the possible values for the nonce. Can this be prevented? As long as you are using mining software designed to achieve 100% efficiency (sounds like you are), then no, there is nothing more you can do. but what am i mining on when mining for a pool, exactly? You're also working on a whole block, but it's a block that belongs to the pool. The difference is that, for solo mining your miner must find a nonce that results in a hash that meets the current Difficulty. That's very tough to do! A mining pool, on the other hand, will accept hashes that meet Difficulty == 1. Easier work, but of course those results are worth less to the pool. |
|
|
|
I don't know if ThreadSafeMessageBox is safe to use inside of CSendDialog::OnButtonSend, inside the cs_sendlock critical block. A real Bitcoin dev will have to do the heavy lifting there  But for what it's worth, I wrote the following off-hand: bool ThreadSafeConfirmSendMoney(int64 nAmount, const string& strDestination, const string& strCaption, wxWindow* parent)
{
if (fDaemon)
return true;
string strMessage = strprintf(
_("About to Send %s to %s."
"Is this correct?"),
FormatMoney(nAmount).c_str(), strDestination.c_str());
return (ThreadSafeMessageBox(strMessage, strCaption, wxYES_NO, parent) == wxYES);
}
and can potentially be called after the nValue checks, before parsing the bitcoin address, like so: if (!ThreadSafeConfirmSendMoney(nValue, strAddress, _("Sending..."), this))
{
return;
}
|
|
|
|
Useful dev information: The bug is in src/util.cpp:ParseMoney. In particular, on line 375 the function explicitly checks for ',' and interprets it as the American/English (or other?) digit grouping symbol. It checks if there is a digit before the comma, and three digits after it (e.g. One Million Dollars can be written as $1,000,000). Because of this 0,005 is considered valid, even though it makes no sense even from an a digit grouping perspective. I'd say several patches are in order: 1) 0,005 should not be considered valid when interpreted as digit grouping 2) ParseMoney should be locale sensitive 3) OnButtonSend should display the valid it interpreted (after line 1925, nValue) and ask for confirmation. 3 is necessary because bugs like this are likely to crop up for a long time, and it's just all around a good idea to give the user a second chance to verify their input. |
|
|
|
I have had a lot of trouble with phoenix. The biggest issue being that it oftens gets stuck on "[0 Khash/sec] blah blah" and never reconnects to the server. This is especially bad when I have torrents running, even when I limit torrent traffic. The only reason I put up with it is because phoenix supports the phatk kernel, which gets me an extra 20MH/s per card. Well, I got tired of it, so I forked poclbm and hacked it to support phatk. Here's my fork: https://github.com/progranism/poclbmSo far so good, poclbm is happily running without any issues whereas my phoenix instances are freezing up  MH/s is about the same. 339 MH/s instead of the 340 MH/s I get on phoenix. Close enough. Lemme know if this helps anyone else.  |
|
|
|
|
Thanks for the advice guys.
I think I'll try to disassemble it and unstick the fan. RMA would take too bloody long. Worst case I can use it as-is but won't be able to overclock it anymore, which is fine.
|
|
|
|
dishwara, I think you've forgotten that all this mining software was provided for free out of the sheer kindness of the developers. Nobody has any right to complain, let alone accuse the developers of malicious intent. And the truth is likely as iamzill said, AMD is at fault, not the mining programs. As another example, you don't need dummy plugs in Linux, but you need them in Windows. It isn't the fault of the mining programs. It's Windows/AMD. That is killed by locking mining program not to mine more than 4 GPU's in Windows OS.  |
|
|
|
aren't then the hashes re-computed when checking for higher difficulties? Yes ... is there a problem with that? |
|
|
|
This is the only check, and it's still unclear to me how this is the equivalent of (hash <= target), considering it's only the top 32 bits and it's an equality check. There are two things going on here. The add before the check is simply part of SHA-256. (1) After that, within the kernel, they are only checking to make sure the hash matches at least a Difficulty 1 target. At difficulty 1 the Target is 0x00000000_FFFFFFFF_..._FFFFFFFF, so hash <= target can be optimized to hash[7] == 0x00000000. The reason for this, is that you want the kernel doing as little work as possible, and difficulty 1 is easy to check for (computationally). If it finds a hash that matches the difficulty 1 target, it reports it. The rest of the miner code (outside of the kernel) can do another check on the hash to see if it also meets the real target. Also note that, for pooled mining, the target is artificially lowered to 1 anyway. These are called "shares" and miners are rewarded based on the number of shares they submit. So, in this case, the kernel's results can be directly submitted to the pool. A second target check is only needed for solo mining (2), or the rare mining pools with a difficulty over 1. (1) Some miners may optimize this even further and combine the addition with the K constant for round 61(2) Actually, for solo mining, you can submit the hashes anyway without checking, because bitcoind will check the hash itself and reject if it didn't meet the actual target. |
|
|
|
edit: looks like 45k LUTs isnt nearly enough for a pipelined version. Might have to make my own board for this =/ The current version of the code can unroll as much or as little as you want, so you can make it fit into 45K. |
|
|
|
Secure hashing is believed to be secure from quantum mathmatics.... Merkle signature scheme is just that, a signature scheme. It's not a hashing method, and it isn't "the same hashing algorithm [...] used for the blockchain headers themselves." What you are referring to is specifically SHA-256, the hashing function at the heart of both the merkle root calculation, and the block header hash. Also, the merkle root is not the thing being attacked. The proof-of-work required to create a valid block header would be the target, which again uses SHA-256 at its heart. A more appropriate quote would be from http://en.wikipedia.org/wiki/Key_size#Effect_of_quantum_computing_attacks_on_key_strength: Mainstream symmetric ciphers (such as AES or Twofish) and collision resistant hash functions (such as SHA) are widely conjectured to offer greater security against known quantum computing attacks. They are widely conjectured to be most vulnerable to Grover's algorithm. Bennett, Bernstein, Brassard, and Vazirani proved in 1996 that a brute-force key search on a quantum computer cannot be faster than roughly 2n/2 invocations of the underlying cryptographic algorithm, compared with roughly 2n in the classical case.[8] Thus in the presence of large quantum computers an n-bit key can provide at most n/2 bits of security. Quantum brute force is easily defeated by doubling the key length, which has little extra computational cost in ordinary use. This implies that at least a 160-bit symmetric key is required to achieve 80-bit security rating against a quantum computer. Emphasis mine*. In summary: Quantum computers are thought to only be inherently twice as effective against SHA-256, compared to classical computers. Therefore any supposed attacks by quantum computers would really just mean a doubling of the difficulty; no different than all current computing technology becoming suddenly twice as powerful. |
|
|
|
I just got my order today in the mail, and I have to say, it was very exciting to open that package. Not because it had some random cables in it or anything like that. It was amazing just to have in my hand a physical product, something very real, that was purchased entirely with Bitcoins. What a profound message on the reality of Bitcoins. I almost want to frame the cable and hang it in my room Anyway, works great. Thank you. |
|
|
|
One of my Sapphire 5850s now has a stiff fan. It only gets about 500 RPM, where it should be getting 5000.  I took the card out, and manually turning the fan is stiff. It still turns, but not smooth and nice like the other cards. No idea what happened; it's a month old. Sapphire support will RMA it, but I have to pay shipping to their facility and I'm without a card for who knows how long. All tech support could suggest is to "air dust" it and put WD40 on the fan. I doubt dust is to blame for a stiff fan, but I'll dust it regardless. As for the WD40 suggestion ... I'm not even sure how I would get WD40 onto the fan's internals. I guess I have to some how get the plastic casing on the card off, and carefully drip oil to the base of the fan. God knows what will happen if I accidentally get WD40 on the heat sinks  Anyone have some ideas? |
|
|
|
|
Show Posts
