Bitcoin Forum
October 20, 2021, 08:30:48 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Two instances one computer on: July 19, 2010, 03:26:04 PM
I may be way wrong, but if you recompiled the client to use port 8339, and you're telling the modified client to connect only to localhost:8339... wouldn't that gain you very little? In other words, I'd think it would be redundant... You may want to try connecting to localhost:8333 instead...? I'm not sure, but it can't hurt! :-)
2  Bitcoin / Development & Technical Discussion / Re: Guide to how Bitcoin works on: July 16, 2010, 04:06:26 PM
Is it possible that your confirmations are rising so quickly because multiple people are generating the same blocks at the same time? I know one of the devs mentioned that this does happen, and it makes things act weird until the blocks are verified by multiple other clients, at which point one of them wins out. It may be that the confirmations are tracking all of the blocks, not just the ones that ultimately win out...?

Or, is it possible that each subsequent block is also getting confirmed? In other words, block 66,000 was the block in which your transaction took place... so then when block 66,001 is created, you get 1 confirmation. Then when block 66,002 is created, it in turn confirmed block 66,001, so you get 2 more confirmations - bringing the total to 3...?

Still wrapping my head around parts of it, so I may be way off.
3  Bitcoin / Bitcoin Discussion / Re: Bitcoin subscriptions on: July 16, 2010, 02:10:53 PM
I haven't had much luck finding all the options that can be passed to bitcoin/bitcoind when it's run... -connect, -addnode, and -server are the ones I've seen so far. Are there others?
What exactly does -server do? Also, it seems that -connect and -addnode have pretty similar functionality... My best guess is that -connect is to force only one explicit connection to be made, whereas -addnode just says "make all the connections you want, but by golly you better connect to <IP>, if nothing else." Is that at least close to right? Smiley
4  Bitcoin / Bitcoin Discussion / Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel on: July 16, 2010, 12:57:23 PM
Yea, that's what weirded me out. I expected to see an IRC connection, but the domain had me concerned! My linux boxes are strapped down pretty tight, so I was a little surprised at that. A quick Google search turned up some info that tied it to bitcoin, so I'm less worried now. Smiley
5  Bitcoin / Bitcoin Discussion / Re: usefulness of the work performed? on: July 15, 2010, 09:09:05 PM
In my view, you are sort of assigning value to the "work" being done by desiring the bitcoins in the first place... I see it as saying "I want to use these bitcoins to purchase a good or service (or contribute to person or cause) because they are of value to me, by virtue of the fact that I expended a considerable amount of time and electricity to generate them."

I do see your point about the computations themselves not contributing to the greater good in an obvious way, but you could always consider it as a contribution to society in the form of a scarce, secure, anonymous currency.

Or, if it still bothers you, you can always find a good (honest) method by which to gain large quantities of bitcoins, and use them to pay others for running Folding@home, SETI@home, etc. instead of generating coins / transaction fees! Smiley In face, if you wanted to pay me a set amount of BTC per F@H point, I'll switch all my cores over right away... Wink
6  Bitcoin / Bitcoin Discussion / Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel on: July 15, 2010, 08:45:53 PM
Heh... had me a little confusion for a few minutes, as I was monitoring my PC's connections and noticed that I was connecting to ""... needless to say, that wasn't a pleasant thing to see, as I couldn't figure out what would connect to a server name like THAT. I tracked down the process that was using the port associated with that url and it was bitcoind, so I figure it's alright... but yea, the name alone was enough for me to start tossing up new firewall rules there for a few minutes!
7  Bitcoin / Bitcoin Discussion / Re: Hashing slowdown on: July 15, 2010, 07:10:20 PM
You can check your other running processes too, and see if something else is registering a noticeable amout of CPU usage. Either Task Manager for Windows or top / nmon for *nix should work just fine for the task. Any %CPU used that isn't attributed to bitcoin/bitcoind is going to slow your hashes, even if it's only taking 5% of a core's processing muscle away from bitcoin. Smiley
8  Bitcoin / Bitcoin Discussion / Re: Hashing slowdown on: July 15, 2010, 04:29:17 PM
I think an increased difficulty just means more hashes are (typically) required to create a block successfully. I don't think it should slow the actual hashing rate though... my guess would be that it's something on the client's host that is consuming extra cycles and depriving bitcoin of CPU time.
9  Bitcoin / Development & Technical Discussion / Re: Hash/sec Throttling for Democracy on: July 14, 2010, 07:50:02 PM
Take this lightly until confirmed, but here's my understanding...

There is no variation in the problem itself - every node is intended to work on the same block at the same time (accounting for latencies and such). The luck factor is really the random number generated at the beginning of each node's attempt to solve a new block. When a new block needs to be solved, each node generates a random value (nonce), which is used to hash the block. If that hash isn't the right one, the nonce is incremented, and the new incremented value is used to hash the block again.

Say my clunker manages 1,000 khash/s (which it really does...  Sad), and you have a cluster that cranks out 100,000 khash/s, there's still a reasonable chance that my clunker will randomly (and very luckily) land on the value that solves the block within a very small number of hashes... say my nonce is a winner after only 10 hashes. I'm working out 1,000,000 hashes per second, so it only took me 1/100,000 of a second to solve the block. You cluster would have to (again, luckily) generate the right nonce in less than 0.00001 seconds to beat my lucky guess... which means your cluster would have guess correctly in less than 100,000,000 (hash/s) / 100,000 (s) = 1,000 hashes. Given the huge number of hashes possible, the likelihood of you hitting it in under 1,000 is remarkably low...

Granted, my chances of hitting it in under 10 hashes was even more insanely low, but you get the idea I think. So yes, the cluster will, overall, solve more blocks than my clunker, but it won't win out every single time.

Now that I've gone through all that... I'm sure someone will point out a flaw in my reasoning! Smiley I'm fine with that though, I want to make sure I understand it all correctly!

Edit - Laszlo said it much more conscisely, but I think we made the same point...? Hopefully!
10  Bitcoin / Development & Technical Discussion / Re: Hash/sec Throttling for Democracy on: July 14, 2010, 04:02:05 PM
Now imagine this with thousands of PCs out there playing the lotto every second. Just because you have a quad-core system churning 2,400 khash/s doesn't mean you are going to win every time. It makes your odds better of course, but by no means is it a sure thing just because of the raw CPU power you have. Ask the people at this forum who are running this on a server farm (like myself) and you'll see. I'm churning 10,000 khash/s on one of my systems (6 cpu) and it hasn't won a single block yet  Wink  I'm not bitter though, it proves to me that the system is being fair in the block generation, so I'm happy actually.

This is a good point. My weaker PC is barely squeaking out 1,000 khash/s on two cores, and has netted me 100 coins in less than 48 hours. My server, on the other, hitting closer to 1,200 khash/s on two cores (not a huge bump, but still more), and has been running for about 12 hours longer than the other and has netted me 0 coins. So, like knightmb said... there's hope still. Smiley
11  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 13, 2010, 09:14:35 PM
I don't know that it's valid to say there is a fixed supply of bitcoins, because as has been discussed elsewhere in the forums, lost coins (lost/stolen wallets, hoarded coins on never-to-connect-again machines, etc) will not be recoverable in any way. So there's a cap on the number of coins that can be created over the lifetime of the currency, but the amount of bitcoins in circulation will not be fixed, as there will inevitably be lost coins as time goes on.

Now the divisibility of the coins is, as I understand it, what helps to insulate the currency against crazy deflation... but the economic discussions usually elude me, so I'm not 100% positive on that.
12  Bitcoin / Bitcoin Technical Support / Re: No blocks downloaded... why? on: July 13, 2010, 06:42:25 PM
Yea, possibly a full disk, or a failing disk... It's odd that even with a dedicated connection within your LAN it took that long to get that number of blocks. My 100 Mbps router funneled them from one of my PCs to another in less than 15 minutes, at the 65K+ blocks it needed.

Maybe a flakey router or internet connection? Might be worthwhile to do a speed test, or research Microsoft Security Essentials to make sure it's not toying with Bitcoin's ability to build the block list in some other way... not too familiar with Microsoft products I'm afraid.  Undecided
13  Bitcoin / Bitcoin Discussion / Re: Standards and Protocols on: July 13, 2010, 05:59:29 PM
Sounds like a good start to me. I'm anxious to see what you come up with!
14  Bitcoin / Bitcoin Technical Support / Re: No blocks downloaded... why? on: July 13, 2010, 05:58:08 PM
I think I read somewhere that if he has any connections, he is connecting to the IRC channel just fine... I think you're correct on the 8 connection limit without having port 8333 forwarded.

My thinking was that the static IP -addnode would help by providing a dedicated download source. If that still doesn't work well then I'd guess that laszlo has hit the nail on the head, and the constant full-rewrite of the file is to blame.
15  Bitcoin / Bitcoin Technical Support / Re: No blocks downloaded... why? on: July 13, 2010, 05:08:13 PM
Might need to have him start it with -addnode=x.x.x.x, where x.x.x.x is someone's static IP. Hopefully someone should be able to share theirs for that purpose... if that's the issue, of course. :-) I don't know for sure though.
16  Bitcoin / Bitcoin Discussion / Re: Multiple BitCoin clients on same public IP (same household) questions on: July 13, 2010, 12:26:37 PM
You can easily automate that task. I made a Python script to do just that. I'll upload the updated version to my site and post back here later tonight.

That's actually exactly what I was planning to do, after I read thufir's explanation. I'd definitely like to see your script. It seemed like an easy enough task to take care of, but hey... reuse over reinvention. Smiley
17  Bitcoin / Bitcoin Discussion / Re: Block vs Transaction vs Coin on: July 13, 2010, 12:23:21 PM
For my own understanding... is there only a single chain of blocks for the entire network? Or is a block chain contained within a coin?

As far as I can tell so far, it seems like a block is a transaction history, involving one or more coins... yes?
18  Bitcoin / Bitcoin Discussion / Re: I use WIFI that resets every hour (Have to log in every hour) on: July 12, 2010, 08:25:50 PM
From what I've been reading on the forums and the FAQ, it appears that BitCoin will simply pick up where it left off if the client is shutdown or can't communicate with the network.

In fact, it may even be that it will continue to calculate, but just won't be able to retrieve the most up-to-date information from other nodes, nor communicate out to those nodes. So if you forget to log in and stay offline for a while, then yea... you'd probably be hosed. Smiley
19  Bitcoin / Bitcoin Discussion / Re: Multiple BitCoin clients on same public IP (same household) questions on: July 12, 2010, 06:12:24 PM
Gotcha! Thanks knightmb and thufir for the info. I was mostly curious because of the exact situation knightmb mentioned - one can only forward a port at the router level to a single NAT'd host, so I wanted to see the best way to use all of my PCs and still manage to accumulate funds under a single "account". Based on thufir's confirmation, it looks like the best way to do so will be to routinely transfer funds from my "workhorse" PCs to my central PC that will house my "primary wallet," for lack of a better description. Smiley

Thanks again!
20  Bitcoin / Bitcoin Discussion / Re: Multiple BitCoin clients on same public IP (same household) questions on: July 12, 2010, 05:12:14 PM
I have a quick question about the connect=x.x.x.x option - what exactly does it do? I understand that it "points" a certain bitcoin client to another PC on the LAN, but what does this mean for the bitcoin application itself? Does all coin generation funnel to the wallet that is held on the target PC? Or does a client that is pointed to another local PC just funnel its connections through port 8333 on that PC, and still manage its own wallet?

Just curious.  Smiley
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!