|
Investigating a little further: it's only the second core on the 5970 which gives me problems (Invalid block found on Cypress (#2), possible driver or hardware issue) it does however produce correct blocks too, so I'm getting nowhere with that one. The 5850 isn't detected by Diablo, although it does show up in aticonfig.
Any ideas?
|
|
|
|
|
Solo mining has the advantage of strengthening the network itself. Pooled mining creates single points of failure, which could be attacked or compromised, which could result in large portions of the computational power being used to revoke transactions at will or be lost (slowing down transaction confirmation). It would take several weeks to recover from the loss of slush's pool for example.
So solo mining does not directly provide you with any benefits, but it strengthens the network, resulting in a more stable currency.
|
|
|
|
|
I have a protocol implementation ready to be open sourced, but it does not have the crypto stuff ready yet, which doesn't really have much to do with the protocol itself.
Still looking for motivated developers to help me create a stable and peer reviewed implementation of the protocol :-)
|
|
|
|
Sounds like a reasonable enhancement, especially since the miners will be notified of a new block and will be able to start on the new one right away  |
|
|
|
Does this call Bitcoind or are you handling all of the back end stuff?
It's another frontend to bitcoind. |
|
|
|
But if you aren't verifying signatures then that means I can send transactions into the network that aren't valid (the signature is random garbage) but reference old coins I don't own, thus artificially boosting my priority. Other nodes will happily relay my high priority but invalid transactions through the network leading to huge amounts of spam travelling around. It just replaces CPU exhaustion with RAM and network exhaustion. Good point, verifying transactions close to the originating node means stopping spam earlier, but adding to the load of those nodes. I think we have to distinguish between spam (invalid transactions) or valid transactions increasing in size. Actually this reminds me my idea of using a hypercube, transactions are always forwarded to the nodes that check the inputs, should the network ever run out of computation power we just add a new degree locally and have successfully halved the computation power needed (by adding an additional bit to the prefix matched), reduced the network load to 1/4th (half the nodes fully connected 1/2n => 1/4n^2), all that for adding an additional hop to the final destination |
|
|
|
|
I'm trying to build my own small pool which I'd use to gather statistics about the miners I'm deploying. Would that script work for that purpose? I guess that validation is not necessary if I trust my miners, right?
|
|
|
|
The pool has been shut down. Thanks to all who helped test! Only one block was found during this test, from beginning to end.
I assume it didn't go all that well, I'm sorry to hear it. It's always been my opinion that if we really must have pools (instead of running hundreds of independent miners) we should have many of them to chose from, as to avoid central points of failure. Should slush turn out to be taken down or replaced by a malicious entity we'd have a problem at hand. Meanwhile, thank you for publishing part of your code, I'll use it in my own mining rig if that's ok, and if someone can confirm that it actually works |
|
|
|
Hum... I think I shouldn't have talked about the generationn process, but instead I should have talked about the "election" process.
My point is that CPU power has to be used in order to determ which node in the network will be in charge of validating transactions. The reward for this task is not really relevant for my point. Sounds better, thanks ^^ Anyway, I agree that right now the "work" done by the client to elect a tie-breaker is quite useless. It would be nice if we could leverage other, more useful, computation tasks to let the time tick in the Bitcoin universe. Right from the start I can think of the entire Boinc stack which is (kinda) useful, but we have to consider certain problems: - Blocks have to be generate at regular intervals
- Difficulty has therefor to be adjustible
- Proof-of-work dictates that once a result if found it has to be easily verified
So SETI does not really qualify (too unpredictable, ...), maybe the prime number sieve might be a good candidate (find a prime number of a certain length), but it destroys the chainability (I can start calculating any length number without knowing the predecessor). |
|
|
|
Challenge accepted.
Shall we open another thread? I don't want to stray too much from the subject. [OT]Light needs 20 minutes to travel from Mars to Earth, even assuming we could get a client up there it'd be much more practical to establish a MarsCoin and let it build up resources locally, rather than trying to tie it to EarthCoin ^^ The better option is to set up an exchange that allows to buy MarsCoin for EarthCoin should we need them[/OT] |
|
|
|
|
Since Bitcoin will only work on earth (speed of light and everything) we only have to consider the earths population: 7 billion people currently.
That's ~2^33 (don't you love working in binary?)
Given 2^64 minimal fragments of a bitcoin we still have 2^64/2^33 ~= 2^31 = 2147483648 fragments per person, or expressed in other terms: every living person on earth can have an average of 21.47 Bitcoins.
Anyway since making the change would break all signatures, we'd have to run both protocols in parallel, making it as hard now as it'll be in a few years.
|
|
|
|
It is below _average_ pool capacity. When new block arrive, there are many seconds with significant lower (effective) hashrate. There is also significant variance in share submitting rate. Sometimes there are almost 20 shares per second, sometimes there is almost nothing. And I don't see any trouble with stale block algorithm itself.
That's random for you I'm having some connection problems, quite regularly a connection is lost every 7-10 minutes, is it just me? |
|
|
|
|
As discussed in many other places Bitcoin does not have intrinsic value, it just has the value people are willing to pay for it, for an easier faster, cleaner way to transfer money.
Mining has to be seen as the act of securing the future value of the Bitcoins in your wallet. Getting additional Coins in exchange for computation power is a nice extra, but it's just that, an extra. Additionally the gain from mining will decrease, since the mining reward is set to half at certain stages in the network development.
|
|
|
|
Nope, android.com even tells me that it isn't available for my phone  |
|
|
|
|
Great work :-)
Sadly it's not available for my HTC Wildfire (Android 2.2). Would love to port it, is it open source?
|
|
|
|
My best bet is that he's still active here, but was annoyed about all the requests and questions from new Bitcoin users, so he changed his username and is participating ignotito |
|
|
|
|
It was great finally meeting some of you guys, I'm definitely looking forward to the next meeting ^^
|
|
|
|
Looping doesn't cause the 3% performance boost if thats what you're asking. I see it on my 4xxx, and looping isn't enabled on 4xxx. Looping is probably another, eh, half a percent or so. My bad, the meter is fluctuating a bit more, I'll check if it stabilizes. |
|
|
|
Update: Fix bug on Radeon 5xxx looping
Does this justify a 3% performance increase? I'm not sure how precise the hash meter is. |
|
|
|
|
Show Posts
