When do we get a Linux .deb package for the version with CUDA support? I just got a Tesla card and I'm dying to try it out.
Yeah, when do we get anything out of the code puddinpop opensourced? Well, puddinpop? Now that you got the hefty donation, are you to do any support? Is anyone up to take this? |
|
|
|
no reason to change that, as other clients only try to connect to 8333, afaict. IRC only advertises IP, right? No, both IP and port are encoded in the #bitcoin IRC usernames (see the EncodeAddress/DecodeAddress routines in irc.cpp). (so mizerydearia: no need to do what you done did...) So I could use -inboundport=<port> and use that instead of DEFAULT_PORT, or if 0 disable inbound completely like I do now. Hmmm, I feel a patch to your patch coming. |
|
|
|
I am about interface languages. Yes, most reports should be in English.
But an interface in the native language - it is very nice. Do you agree?
Well, I don't know what your native language is, but most tech terms don't have real translations to Portuguese, and instead translators use some sound-alike replacement that is usually both lame and wrong. I'll take english for any multi-lingual computer related project, thank you  But I understand that often people's grasp of the English language is less than perfect, and makes their life easier to have native language interfaces, so yeah, I agree, but my interface will remain in English, regardless. |
|
|
|
I know my usecase (multiple bitcoin clients on the same server) is not the same thing that is being solved by this patch, it does fix most of it. The only thing remaining is to prevent binding to 8333 (no reason to change that, as other clients only try to connect to 8333, afaict. IRC only advertises IP, right?). I've patched my client with this simple change: --- a/net.cpp
+++ b/net.cpp
@@ -1236,6 +1236,9 @@ bool BindListenPort(string& strError)
memset(&sockaddr, 0, sizeof(sockaddr));
sockaddr.sin_family = AF_INET;
sockaddr.sin_addr.s_addr = INADDR_ANY; // bind to all IPs on this computer
+ if (mapArgs.count("-disableinbound")) {
+ return true;
+ }
sockaddr.sin_port = DEFAULT_PORT;
if (::bind(hListenSocket, (struct sockaddr*)&sockaddr, sizeof(sockaddr)) == SOCKET_ERROR)
{
so passing the -disableinbound switch makes it not try to bind the 8333 port. |
|
|
|
So basically I send a transaction to an address that I own, but no client has, not even mine. That transaction gets into the next block and will be confirmed, but never collected.
Time passes, I provide that key to someone (QR code, email, smoke signals, morse code, whatever) and they want to collect. Notice I didn't transfer to that person, neither did I use a 3rd party payment processor.
The reasons why I think this is useful are, for now, only mildly disclosed, but can we, technically, do it?
I'm guessing that you want to run a client upon a machine that you don't consider secure, and don't want any of your private keys exposed if said machine were compromised with/without your knowledge. If this is what you want, I don't think that it's possible. I'm pretty sure that the private key is neccessary for signing the special transaction at the top of a new block that creates those 50 new bitcoins, forever exposing the keypair used on your non-secure machine to potential theft. There are certainly ways to make that more difficult via software, such as an encrypted wallet, but there probably isn't any way to be absolute. That use case has never crossed my mind I really want to throw a transaction into the bitcoin ether, and then be able to provide the information to someone else so they can collect that transaction. Who that someone else is I don't know at the time of the transfer. |
|
|
|
As I know Trac is not so multilingual as MantisBT. So I prefer MantisBT, moreover, I already used it. But if Satoshi prefer forum - we will use forum. You mean multilingual as in programming languages or spoken languages? Because for the latter I think it's in everyone's benefit we stick to English, and as for the former, I don't see how that can be an issue. I never used MantisBT, but I'm always up for learning something new. Having said that, the one most people are comfortable with would be my first choice. |
|
|
|
Speak for yourself. I am buying bitcoins so I can participate in mostly ignored lotteries, buy broken ipods, play pixel darts, donate to the bitcoin faucet, offer bounties for letter-writing and bet on snooker. who wouldn't want to buy these things?
So you are the one person betting on my lotteries... besides me, that is :p |
|
|
|
Thanks theymos! That's exactly what I was wondering. How did you do that? Was it with the 'bitcointools' that gavinandresen mentioned?
I'm also surprised that there's so... few!!
I count a grand total of SIX auto-payments from the CUDA client.. that is, six payments to the mandatory address of 5.00 BTC.
Each block that the CUDA client found should have sent 5 to that specific address, so this would imply that in the entire closed-source life of the CUDA client, on all the machines it ran on, it found six blocks.
What am I missing? Puddinpop?
I guess there's no magic here. Although there's probably more to the story than what you found, the simple fact is that I have gotten my CUDA version to pump ~7700Kh/s on my system, and while Puddinpop's version is slightly more optimized the simple fact his kernel workers take multiple hashes on a single call makes the system very unresponsive and the amount of data he's moving in and out of the card makes the whole thing slower. But even at 7700 I haven't yet generated a single block (yes, it does work on a test network) and the last 3 blocks I got where instead found by another machine runnnig at under 3000Kh/s. Even doing half, randomness has it's way of giving an edge to that one  If 10 of you were using puddinpop's version for a couple of weeks doing 10M each, it's kind of expected to get no more than ~10 blocks, combined. But again, you could have generated a lot more, I'm just saying... |
|
|
|
please remove me from the list, I gave up on this and uninstalled, thanks!
'this' as in the pay it forward project or as in bitcoin? I suppose to give up on 'bitcoin' would be similar to giving up on other types of currencies as well, and in such cases giving them away or destroying them. Or perhaps it's similar to giving up or quitting smoking, in which bitcoin in some way is detrimental to one's health and is necessary to prevent further association with or consumption of. "Dear IRS, I write to ask you to remove me from your list. I regret this decision but your ability to provide me with any helpful service or in any way improve my quality of life has been null, and as such you leave me no choice but to terminate any relationship you may assume we have promptly. I will add you to the 'no call list' as soon as possible, and I must request that you do not try to contact me through phone, letter, email or any other medium. I am not interested in your services. Very best regards, nelisky " |
|
|
|
I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice.
We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.
I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.
There are many, many bug trackers out there, and I've worked with a good bunch of them. The good thing about any of these is organization, and preventing other users from posting duplicate bug reports (well, to the point where the user looks for them first ). But what I would really see improving things as we go on is git (or bazaar, or another decentralized source tracking system) and a door to give satoshi patches for consideration. This goes for both bugs and enhancements. In the end, as long as the sole keeper or the bitcoin key is satoshi, we just need whatever means of communication he feels better with. Forums, you say? Well, good enough, I guess. But something like trac ( http://trac.edgewall.org/) would really help keeping things organized, and I'm sure everyone would appreciate it. |
|
|
|
When I execute bitcoin daemon starts as expected. When I execute error: couldn't connect to server How come? Is this a bug? Satoshi: May we have a bug tracking system please?Workaround for my gentoo linux init script: which will then execute as `bitcoind "-min"` How is this a bug? I may be reading it completely wrong but: starts the daemon whereas calls the rpc method "" in the running daemon which is not there, so you get the can't connect. If it were there you'd get: error: {"code":-32601,"message":"Method not found"} |
|
|
|
More picks - great idea!
Bug(?) - The [pick details] link in the header seems to only link to the pick 6.
I'd expect it to take me to a page where I can choose which pick I want to see the details of.
Not really a bug, but a left over... that used to take you to the active pick, when there was only one, now takes you to the first one It'll do the right thing when inside the pick betting page, but all that is going away in a future version. |
|
|
|
bad link: clicking on 'Pick 4' in the bet management page brings up all picks for the pick 6.
looks good.
Fixed. Nice catch I've been meaning to get rid of the bet page and drive bets out of the details page instead... been a little busy though |
|
|
|
the format is to pick 6 hexadecimal numbers exactly correct? that's, what, 16 million possibilities? Am I missing something, or is it very likely that this lottery will run for a very long time until we find a winner?
I would bet you this one will be over before the working week is... Ha, friendly wager? 10BTC? :-) And you can buy all the tickets you have coins for, no problem. Working week ends Friday? You're on! Yep, Friday. I'm on GMT+1 so so that's Saturday 5am for you EST people :p Damn, that's 11am Sat here, I'll still take it though. :-P Ok, I lost. PM me the address for settling the wager |
|
|
|
Ok, the server code went through a major refactoring, so if you find any glitches please share asap. Not much changed visually, except now I can run multiple picks concurrently! A Pick4 will be appearing soon, and these tend to end very fast so take your chances, people! If all goes well I may add a Pick5 too. Thanks, everyone, for supporting this idea! Fun, fun, fun |
|
|
|
Hmm, thats only for MacOS clients right? or how do i patch my windows client with a txt file...? You don't, and you don't do that to MacOS clients either It's a patch for the source of bitcoin, only of any use if you can compile it yourself. This is not a ready product, read the appropriate thread for more information. |
|
|
|
This patch is done against the latest SVN, r157, where satoshi made it so much easier to hook up a custom miner in a clean way, including a no nonsense hash per sec calculation. Great work there, satoshi! I have tested it on a test network and at difficulty 1, doing ~6MHs I was generating a block every couple of minutes, with a standard client accepting it. This patch does a much better job than the previous one because the hashes are no longer taken out of the GPU, only the number of 0's in them. That makes parsing a few thousand hashes that were calculated in parallel by the GPU a breeze. And then the nonce is passed to the Crypto++ hasher if one is found, which makes it double sure the hash is valid. Also I cleaned up the makefile (still only for OSX 64bit) to make it easier for people to port to whatever system they have. Now, if any of you has a CUDA or ATI Stream enabled card, PCI-e that is gathering dust, consider donating it to me and I'll make it work on linux. It can be oldy, slowish, don't care. I just need it to be compatible so I can test. Have fun, and keep the code open! PS: the first miner generating is always the GPU, and I don't check if you have a compatible card, I just assume. When I have the time, I'll change that. I'm pretty much giving up on hoping for someone else to pick up where I left it Everyone developing this GPU thing seems to have an agenda. |
|
|
|
I've now removed jgarzik's patch from my client in favor of using Satoshi's -rpcallowip setting (since it's in the vanilla svn).
But that doesn't allow separate ports to run multiple clients on the same machine, does it? |
|
|
|
|
Show Posts
