|
Having more computers will increase your chances of generating blocks regardless of your internet address. As long as they're all able to connect to at least one node and stay connected you're all good - it doesn't matter if they all share the same internet address through a proxy/router.
|
|
|
|
http://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdfIf you follow these instructions and build 'bitcoind' it's all linked statically to wxWidgets, boost, openssl and libdb.. for me it looks like this: $ ldd bitcoind
linux-vdso.so.1 => (0x00007fff31dff000)
libdl.so.2 => /lib/libdl.so.2 (0x00007ff1a0a78000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff1a0768000)
libm.so.6 => /lib/libm.so.6 (0x00007ff1a04e4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ff1a02cd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff1a00b1000)
libc.so.6 => /lib/libc.so.6 (0x00007ff19fd41000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1a0c7c000)
|
|
|
|
|
What's wrong with IRC? It's just another method that's used to exchange the peer list. You can just prevent it from connecting and use -addnode=1.2.3.4 to connect to a known node for bootstrapping if you want..
If nodes disconnect from IRC after they get their list then it makes it less useful for bootstrapping since it will be empty except for the node that's trying to bootstrap at the time.
IRC has been around forever and it's well documented (and easy to understand for newcomers) - why create something more complicated?
|
|
|
|
|
Can you post it on a web server or something? It sounds pretty large. I could take a look but it's probably hard to find anything among all the spam.
|
|
|
|
|
The debug.log is truncated when you restart the app, not sure if it does it periodically too.. are you perhaps getting disconnected/reconnected frequently or having really high latency? A poor connection could prevent you from generating, though I wouldn't think you would be having that issue at the VPS.
|
|
|
|
|
Athlon FX-55 (socket 939) on linux
**Perf - thread 1 : 575k iter/sec
**Perf - total : 575k iter/sec (1 threads)
|
|
|
|
|
That seems odd.. are you seeing any instances of 'proof-of-work' if you grep debug.log?
|
|
|
|
|
So would it be smarter to only process transactions which profit you? That way if you want to send money you need to include a courier fee or nobody will confirm it. That seems reasonable to me, where you can add a fee yourself to each transaction, and people can configure a threshold of how much of a fee they expect before accepting a transaction.
|
|
|
|
|
-O2 is generally the preferred optimization for gcc, -O3 can produce larger code which is slower, but you should experiment around with it.. it also seems to depend on the time of day or the phases of the moon for me at least, some days I'm getting a lot more hashes per second.
|
|
|
|
|
Cool, I was just playing around with trying to make it adjust the rate without taking much of a performance hit.. that's why it tries to adjust that variable, to keep it to a few per second or so.. maybe you can figure out a better formula, I just kind of did that by experimenting around with it.
|
|
|
|
|
You should compile for 32 bit windows (mingw).. 64 bit would just make it use more memory but you'll have to build all the dependencies that way too, if it's even possible with wxWidgets and stuff..
|
|
|
|
|
You did the right thing.. none of it works on big endian anyway.
|
|
|
|
|
E2200 C2D 2Ghz CPU
**Perf - thread 1 : 495k iter/sec
**Perf - thread 2 : 495k iter/sec
**Perf - total : 990k iter/sec (2 threads)
|
|
|
|
|
Make sure you guys try compiling with -O2 instead of -O0 (check your makefiles). It improved performance a lot for me.
|
|
|
|
|
Be careful trying to value a VM in bitcoins..
You will generate less and less with the same hardware over time, by design. As the number of blocks grows the difficulty increases proportionally to the rate at which the generation is happening so it will always slow down. If you have a big chunk of the network's compute power you will be generating more than other people but even if you're generating 10 an hour today, in a few weeks you'll be down to a couple a day and everyone else with lesser capabilities will be down to a couple a month.
This is all just an artificial way to limit supply to direct the focus to trading rather than just generating, as I understand it. If everyone is mining gold in their back yard and hoarding it in their garage, it's kind of worthless. But once the supply of gold starts running out and most of it has been mined (or if you need to dig for 10 years to find an ounce of it), if you want gold you need to trade something for it.. so by design the supply will diminish.
|
|
|
|
|
Bank sites and such use end to end encryption which makes intercepting more difficult and there is usually two way authentication. The website authenticates itself to you by showing you your personally selected image/phrase, thus you recognize that this is the site you wanted to visit, and then you authenticate to the website so they recognize you as the customer you claim to be. It's not perfect but it's like putting a pad lock on a box full of money to keep honest people honest. Sometimes they use a bigger/thicker pad lock so the effort/gain ratio makes it not really worth trying to break it.
I agree with you in a way about security, if it's too inconvenient then it's not very useful... though encryption and authentication are generally good enough to deter trivial things and they provide some reassurance.
It is certainly convenient to be able to send to a paypal email address, but even there you get two way authentication. PayPal will display the name of the person you're sending to, before you commit to how much you're sending. PayPal is very popular and is riddled with fraud.. if Bitcoin was accepted on Ebay and the IP address based sending was used as it is today, it would never get there because people would just intercept it along the way, TOR or not.
If you've used ssh you know that uses two way authentication as well - you verify the server's key visually before you present your own authentication credentials. This technique is problematic in a way because if it's the first time you're connecting you don't know what it should be.. you have to call up the person operating the server and ask them to read you the key. I think the idea of putting it into the URL or other address notation is that you declare what you expect it to be and the local client will tell you if the peer presents something different. I suppose you could go the ssh route, just let someone accept whatever is presented.. though right now the key is dynamically generated, it could be changed so that it would present some key that changes once a day or something.. then you could show it on the web site that's expecting the payment, but then why wouldn't you just show the bitcoin address itself and send that way.
I guess I don't really understand your point with simplification.. if you have to copy/paste an address already, what does it matter if it's an internet address, a DNS address or a bitcoin address?
|
|
|
|
|
Show Posts
