I'm running the current cgminer and it keeps switch to my failover pools. You are pool 3. [2011-12-18 19:46:39] Accepted 00000000.01a8751e.5cb4f155 GPU 0 thread 3 pool 3
[2011-12-18 19:46:42] Accepted 00000000.aae4c89c.0dc3c969 GPU 1 thread 4 pool 3
[2011-12-18 19:46:42] Accepted 00000000.bb18a125.e0b7ef97 GPU 0 thread 0 pool 3
[2011-12-18 19:46:44] Accepted 00000000.df13d15f.686c8a1b GPU 1 thread 4 pool 3
[2011-12-18 19:46:45] Accepted 00000000.809b11ff.d81102f1 GPU 1 thread 4 pool 3
[2011-12-18 19:46:55] Accepted 00000000.08bd31a8.05e6fbd8 GPU 2 thread 5 pool 3
[2011-12-18 19:46:55] Accepted 00000000.5895819b.fc612e16 GPU 0 thread 3 pool 3
[2011-12-18 19:46:55] Accepted 00000000.f5936cf3.0e877479 GPU 2 thread 2 pool 3
[2011-12-18 19:47:01] Rejected 00000000.7e271b12.93f820fd GPU 2 thread 2 pool 3
[2011-12-18 19:47:01] Rejected 00000000.8d674b44.e5a6a509 GPU 0 thread 3 pool 3
[2011-12-18 19:47:02] New block detected on network before longpoll, waiting on fresh work
[2011-12-18 19:47:02] Pool 3 not providing work fast enough
[2011-12-18 19:47:03] Accepted 00000000.dd0b117c.7b576fef GPU 0 thread 3 pool 2
[2011-12-18 19:47:03] Rejected 00000000.9ff76912.91047180 GPU 2 thread 5 pool 3
[2011-12-18 19:47:03] Accepted 00000000.e14dcf4b.b97c2ffd GPU 2 thread 5 pool 2
[2011-12-18 19:47:04] LONGPOLL requested work restart, waiting on fresh work
[2011-12-18 19:47:18] Accepted 00000000.5e8639ed.c66123ea GPU 0 thread 3 pool 1
[2011-12-18 19:47:18] Accepted 00000000.f6ba86cf.f00e4c2d GPU 0 thread 3 pool 1
[2011-12-18 19:47:20] Accepted 00000000.02d7bb32.3c662880 GPU 1 thread 4 pool 3
[2011-12-18 19:47:21] Accepted 00000000.0d43b4a9.9cae21c2 GPU 0 thread 3 pool 1
[2011-12-18 19:47:25] Accepted 00000000.2f0560f7.b0a8f144 GPU 0 thread 0 pool 3
EDIT: It looks like it has stabilized now. Everything is going to your pool. |
|
|
|
|
OT sounds interesting. I am not in love with centralization, but it looks like you have some plans for negating the usual problems.
Keep up the good work.
|
|
|
|
Any interest in having the addresses be more visible to the user? I know some people are for keeping all the "extra" addresses relatively hidden since they might confuse the user. With these patches the "extras" wouldn't be as confusing since they would all be automatically linked to their transactions. And importantly, users could also completely ignore these features and let the client pick everything automatically.
to be honest, it is not in my list of priorities at the moment (not that I am against it, but there are more urgent things). But I think that slush mentioned coin selection as a property of his future qt gui. I agree that there are more important parts of the client to work on. I just wanted to make sure this got put on a list. Knowing future features ahead of time can often help the current design. Also, I found out that it is a pull request so it is pretty easy to see exactly what coderrr is changing. https://github.com/bitcoin/bitcoin/pull/415 |
|
|
|
This attack is useful when, a victim is on an unsafe network such as an open wifi hotspot, and intentionally avoids doing anything important while on the network. The victim goes home, but the attackers modified 3rd party script is still cached, and continues to run arbitrary javascript on any site with the "infected" 3rd party script.
The victim might start to browse different websites that are more sensitive once they are no longer on an untrustworthy network that utilize the 3rd party script.
That's why you configure your browser to delete all cached data when you close it. While clearing your cache would fix this, hardly anyone actually has their browsers configured to do that. Most people don't even consider CDNs such as google analytics an attack vector. If we want non-technical users able to securely browse the internet, then these security problems (simple as many of them are) need to be brought to people's attention. |
|
|
|
Watching this.
This should really be made into a pull request
from my last reply on this thread Dunno how I missed that. Awesome. Any help needed with testing? From reading the comments, it looks like that is all the pull request needs. |
|
|
|
I can't find bitcoin.config file in windows xp: C:\Documents and Settings\USER\Application Data\Bitcoin I use 0.4.0 version because I don't like localization of 0.5 version. I am in DK and I don't speak DK. by the way, after longer waiting, now I have one connection and 11000 blocks:) so, it works:) I suppose Tor works with port 9050, although when I installed vidalia bundle, there is written Control port 9051: http://i42.tinypic.com/2s6jxqo.jpg I don't know what is different between port and control port, but I think all works fine:) I am pretty sure that you start out without a bitcoin.conf. Just make a text file and you are set. The control port (9051) is different than the port tor listens on (9050). It is for controlling tor (well named isn't it ;P). It makes it possible to do things like tell tor to get a new identity from the command line. |
|
|
|
|
I'm watching this. I've checkout out the source but haven't played with it yet.
EDIT: Oh yeah. Firstbits support will be awesome. I'm looking forward to giving someone 11235813 as my address
|
|
|
|
Thomas, that sounds exactly right. Not to add even more to do, but I've got some more feature requests. coderrr has some patches to the main client that add what I'm thinking about. https://bitcointalk.org/index.php?topic=24784.0TLDR: this patch allows you to:
- see all addresses, including change
- see which addresses are linked together (does recursive expansion of address linkages)
- select which address(es) to send from, rather than letting the client to chose for you
Any interest in having the addresses be more visible to the user? I know some people are for keeping all the "extra" addresses relatively hidden since they might confuse the user. With these patches the "extras" wouldn't be as confusing since they would all be automatically linked to their transactions. And importantly, users could also completely ignore these features and let the client pick everything automatically. |
|
|
|
It would be fine if this index were built on the beginning of the address (e.g. the first 32 bits) rather than the entire thing, in order to save on space, at the minor expense that a few blocks might occasionally be consulted that don't actually contain transactions for the bitcoin address being searched
If key import is the use case, you could also make the index smaller by pointing at only the first block that mentions an address. If I send coins today, such an index would immediately eliminate 152,000 blocks from the search. I'd guess that imported keys typically have a short time between initial funding and sweeping to a semi-permanent address. I would recommend the index point to all of the blocks that mention an address, otherwise I could DoS websites offering private key import simply by repeatedly trying to deposit private keys from transactions done a long time ago, even if those keys had no funds. But there is one place I would put a derivative of the idea you just mentioned: in the -rescan command. I frequently need to import large numbers of private keys. I have patched my own bitcoind so that importprivkey doesn't rescan the wallet immediately, so it returns instantly. After importing keys, I shutdown and do a rescan. I have it so that I can do bitcoind -rescan=150000, that it will only rescan from block 150000 if I know I'm only importing recent keys... saves me tons of time importing private keys in the absence of that index. (in a nutshell, I added an optional "nSkip" parameter to ScanForWalletTransactions()). Of course, having the index would be much sweeter. Do you have these rescan changes as another pull request? I'm also looking forward to this pull request. I want to merge some wallets and would like to use official code. |
|
|
|
|
NVIDIA's hardware is just not as good as ATI's when it comes to integer math. Even with optimized miners, NVIDIA hash rates will (sadly) never be close to ATI.
|
|
|
|
Cool. I was assuming the reason for being GPU hostile was not because they want to handicap themselves, but rather because of some inherent problem with their calculation. If you're referring to LTC, they don't view this as a handicap. It's on purpose because they think that it helps more casual people (who usually don't have big GPUs) become miners too. And probably also because a new GPU cryptocurrency would have to face the competition of BTC. No, I'm not referring to litecoin. I'm referring to some of the projects on BOINC or other similar systems. |
|
|
|
|
You guys have scared me away from ever updating my graphics drivers
|
|
|
|
I am playing around with Litecoin, but I still want to find something more useful to do with my miner's CPU. I don't think the few cents worth of an alt-chain is really worth the temps and electricity. Is there a GPU hostile folding@home-like project?
The point of Folding@Home and alikes is to compute as fast as possible, so I wouldn't say they can be "GPU-hostile" as in "sabotaged not to work in GPUs", but if you look in BOINC you'll find some projects like QMC@Home that work only on CPUs. Cool. I was assuming the reason for being GPU hostile was not because they want to handicap themselves, but rather because of some inherent problem with their calculation. |
|
|
|
That is a great link. I am playing around with Litecoin, but I still want to find something more useful to do with my miner's CPU. I don't think the few cents worth of an alt-chain is really worth the temps and electricity. Is there a GPU hostile folding@home-like project? |
|
|
|
|
I am looking forward to namecoin improving. I definitely think that SOPA will help spur its development as namecoin could definitely help bypass part of SOPA's bullshit.
Even if SOPA doesn't pass, removing the centralization of DNS will be good for groups like wikileaks and others that have had their DNS's shut down.
|
|
|
|
|
Watching this.
This should really be made into a pull request
|
|
|
|
add "proxy=localhost:9050" (assuming tor is listening on 9050) to bitcoin.conf
If you want to be more paranoid, also add "nolisten=1"
nolisten is absolutely irrelevant, if you connect over a proxy/tor then you got the IP of the proxy, therefore others may try to connect to the proxy and not to you! It may be irrelevant to you, but the peers that try and connect to you and have to wait for timeouts won't see it as irrelevant. Although it looks like there was a patch that makes nolisten turned on by default if bitcoin sees a proxy on tor's default port. https://github.com/bitcoin/bitcoin/issues/441 |
|
|
|
Just got the miner compiled. As soon as I get an RPC command sent, I'll send you the bounty.
Then I'll probably start working on a fork that uses JSON so that devs won't have to write their own parsers.
LOL - you didn't read my posts? Since you're a bounty payer and you seem to want JSON also, I'll just do that next. (I've already said that as an option before but no one bothered to reply ... ... ...) Of course it will be done the simplest way: If the string sent over the socket starts with '{' then I'll assume it's JSON and reply with a JSON string. If the string sent doesn't start with '{' then it's the same as it is now with the same simpler reply. As for doing your own fork ... you do realise what you are in for if you do that? Do you use windows or was your fork just going to ignore that? Edit: P.S. the basic parser is already written in 3 languages, so "devs" shouldn't have any issues ... ... Github makes forking really easy. I don't think that the JSON code would have anything platform specific, so don't know how being on windows would make a difference. Although if you want to do it, that would be even better since you already know this part of the code. The string that gets returned isn't consistent. "STATUS=S" starts the first section, but "SUMMARY" starts the second. EDIT: I just sent 10BTC to the address in your sig. |
|
|
|
|
Just got the miner compiled. As soon as I get an RPC command sent, I'll send you the bounty.
Then I'll probably start working on a fork that uses JSON so that devs won't have to write their own parsers.
|
|
|
|
|
Show Posts
