Since I like your picture so damn much, let me explain it to you. (+1 internet for you, sir!)
You probably have the "Generate Bitcoins" option enabled under "Settings".
This will cause Bitcoin to use your CPU to hash.
Once it hashed what it was looking for? You generated a block!
If the outcome of the hash is lower than or equal to "the target", the data that was hashed is a block. Not sure about what exactly is the block, but I'm sure about the other stuff!
So, your CPU is hashing data to generate blocks, and blocks are Bitcoins! OK, maybe one day I will really understand what it is doing, but for now, Ill just consider it as usage of electricity turned into money (roughly said). Thank you for your help! A "hash" is basically a fingerprint of a piece of data. ("To hash" is the verb, obviously.) Anyhow, what ever you hash is basically like generating a fingerprint, they're fixed size and if you change one character, remove it or even something else, you get a completely different hash! If you hash "Hello, I'm Lord Jebe!" with SHA-256, you get "634ee5cd0971419655d8c61a93ecba406c8105b026afd6cf588a41503919fbd9". If you hash "Helo, I'm Lord Jebe!" (notice the typo), you get "82d90c440807866e3c01400223c466f8520b9e36fb4538c2ebeeb18cdecc71ec". Notice how the two hashes are totally different, this is natural and not predictive. There are different hashing methods out there, MD (Message Digest) 1/2/5 which are getting quite outdated, and SHA-256/512. SHA-256 is what Bitcoin uses right now. Now there's there's a 'target' set on the network, that target determines how difficult it is to generate blocks. If you hash some random data (which Bitcoin) does, and you generate a hash/fingerprint lower or equal than the target, you have generated a block! tl;dr: So, it's really not that hard, it's just generating a fingerprint from random data, if the finger print matches what the network's looking for, you got yourself a block, and thus generated some coins! |
|
|
|
You can't, read the rules: Rules: - 5 lots per person maximum, any cheaters will have all of their lots taken away and will be banished from the next games.
|
|
|
|
Since I like your picture so damn much, let me explain it to you. (+1 internet for you, sir!) You probably have the "Generate Bitcoins" option enabled under "Settings". This will cause Bitcoin to use your CPU to hash. Once it hashed what it was looking for? You generated a block! If the outcome of the hash is lower than or equal to "the target", the data that was hashed is a block. Not sure about what exactly is the block, but I'm sure about the other stuff!So, your CPU is hashing data to generate blocks, and blocks are Bitcoins! More information here: http://www.bitcoin.org/wiki/doku.php?id=hashhttp://www.bitcoin.org/wiki/doku.php?id=blockhttp://www.bitcoin.org/wiki/doku.php?id=targetAlso: Sorry for letting you hang there, I had the tab open and everything typed out, I just never clicked "post!". |
|
|
|
Well, I'll be holding world's SECOND Bitcoin Lottery. (Unless someone beat me to it!) I'll still manage everything myself, like I did last time: http://bitcointalk.org/index.php?topic=159.0. This time, we'll use the last 3 numbers of stock index closing prices, that is one number before (left of) the comma, and the two after (right of) the comma. All lots will be checked against all of the stock indices, they're listed below. We will have 3 winners, and the jackpot will be split in 3 for them. When someone wins, that person's lots are removed from the game, so there will be 3 individual winners. To enter, you have to have at least 15 10 posts. No spamming, I'm a forum moderator!  To buy a lot, post the lot numbers you want to buy in this thread and send me a message through the forum's message system. I want you to post your lots you want to buy in the thread because I don't want people asking me to buy the lot. I'll message you back with a Bitcoin address to send me the money to. (So don't send it to my address I have in my signature!)Rules: 50 BTC per lotp Scrap that! Since the Slashdotting alot of users picked up their own free 5 Bitcoins, so the lot price is lowered to 5 BTC!- 10% of the money is my profit, and the rest goes into the jackpot. (Which is quite small, usually lotteries take atleast 40%)
- The jackpot will be split in 3 for the 3 winners
- A winner cannot win again
- You need
15 10 posts to enter This is to avoid cheaters who buy more lots than allowed. - 5 lots per person maximum, any cheaters will have all of their lots taken away and will be banished from the next games.
- No refunds to the cheaters!
- Winning lots will be drawn on Wednesday the 28th of July2010 :p closing prices of the indices
- If no one wins, the next day's closing price of all stock indices will be used, until 3 winners have been selected.
- The winning numbers are gathered from http://www.google.com/finance
- The stock market that 'selected' the winner can also select another winner, (until we have of course 3 individual winners)
- If no payment received upon one hour before the 'drawing'? Lot is not valid and the Bitcoins will be returned, if sent, of course..
Indices we use to select the winners: - Dow Jones Industrial Average
- NYSE Energy Sector Index
- NYSE Composite Index
- NASDAQ Composite Index
- Note that this list will still grow with Indices I select!, expect another 6 or so...
|
|
|
|
|
F-Secure is in my opinion one of the better ones, I've almost never had problems with that. (Note: It's commercial, Arrr!)
But then again, last I seriously used Windows was when XP was the current, and Longhorn/Vista wasn't even heard of.
Norton, now that's a no-go.
|
|
|
|
flops*luck=coins, which seems to me to be about right. One even advocated for OpenCL/CUDA support, which seems to me like it would give those with OpenCL capable cards an incredible advantage in the "flops" category of flops*luck.
Now, some have said "If you have no luck, you don't get coins...." but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck. They operate upon statistical averages. (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).
Say I have a RNG that can output 1024 different numbers, and we run it 1024*1024 times. We will keep statistics of how many times it gives us what number between 0 and 1024. The more we run it, the more difference in the array between the two numbers which got out putted the least and the most. And so, I can say with a certain amount of security without looking like a fool that how RNGs are used in Bitcoin affects the "chance" of generating a block. Therefore, why not cap the number of hashes per second? If the operations were capped at say, 250khash/sec based upon system clock and not the available number of cycles, then anyone with the "minimum requirements" could participate in generation at no disadvantage to the guy with the TESLA cluster running CUDA (okay...so people aren't going to use TESLA clusters for this...but you see my point, I hope). Of course, difficulty would need to be adjusted accordingly to keep block generation on pace, and checks for blocks generated clients violating the cap (and thus outpacing other clients by cheating) would be required, but these are matters solved with relative ease in the code.
We can't. Bitcoin's Opensource so anyone can run a modified client and thus remove the cap! Now, some have said "If you have no luck, you don't get coins...." but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck. They operate upon statistical averages. (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).
The Linux kernel RNG is seeded by noise on the system actually. |
|
|
|
Ain't that the truth.
I was all excited, because I somehow happened to generate 100 coins within a couple hours of starting. A day later, I haven't generated any more at all.
CPU speed * Luck factor = coins. No luck? No coins. Anyhow, this made me laugh, +1 BTC for you, ultrasonicsite. |
|
|
|
In Australia we are facing massive censorship of the internet by politicians claiming they are "protecting the children".If you come out and say anything against this policy they accuse you of supporting child abuse.Im really tired of the whole nanny state mentality.
Way too strict, they block regular pr0n too. Not that I live in Australia, but I want my pr0nz! Anyhow, it seems the free days on the internet ... are over.  |
|
|
|
|
I have a friend who might be willing to translate it into Romanian, already dropped him a message.
|
|
|
|
What I would like to see is lower time to get started – currently, it takes several hours just to download all the blocks, which amount to few megabytes of data.
Or does it take so long because my PC has to verify all the blocks?
You've made me think of another question to ask: will all new instances of BitCoin clients always have to download all existing blocks? Won't that eventually mean that as the number of blocks increases, the time taken to download the blocks and the space to store it will be enormous. I'm presuming I've got this wrong, as the developpers are rather cleverer than me, but can someone explain the flaw in my thinking? If I am correct, Bitcoin *can* work with only the last block. If I'm not, correct me! But this is insecure because if that last block isn't verified, it might be bogus! Every block is signed with the previous block. (Or something like that. I'm not an expert on the algorithm.) So, if you don't have block 10, you can't verify if 11 is valid, you first need 10 for that, and to verify 10, you need 9, and so on. When Bitcoin starts, it begins downloading the genesis block, and verifying it, and continues down the line checking all blocks and saving them. It's like a linked chain! Eventually every block in existence has been checked and saved, and right now that's like 27 megabytes. The block downloading mechanism isn't that fast. If I am correct it writes the whole file to the harddrive everytime -- or maybe just one sector -- when it gets a new block, so it'll write 65000 times to your hard drive... not exactly what you call 'nice'. I have a solution. Anyhow, does Bitcoin need all the blocks to function? Yes Can we hardcode a block into Bitcoin to save time? Sorta, we don't want to download just from that hardcoded block on. Not saving every block makes the network insecure and starts a dependence on older clients which have saved all the blocks! So we cant save space? No, not by not saving the blocks, that's insecure. We can hardcode a block into Bitcoin, and initially let Bitcoin not download from the genesis block up to the hardcoded block. Bitcoin will then download only from the hardcoded block up to the current block, and after that the client can be used. (To generate/transfer coins/etc) So we have a he chain up until the verified block, we make the network insecure and start a dependence on the older clients which have saved all the blocks! By asking for that same block, and verifying it's local hardcoded copy, the client can just skip downloading the first blocks up to the hardcoded block temporarily. Then after those blocks have been downloaded, and ofcourse, verified from the hardcoded block on, Bitcoin will start downloading from the genesis block up to the hardcoded block and verify those. Thus enabling Bitcoin to be used without waiting that long, yet still preserving the genesis block up until the hardcoded block. And when the network grows larger, we can just move the hardcoded block to the current block when the release is compiled. This seems to me like a great solution to the problem of having to wait a long time. This might be insecure, but only so far. The hardcoded block's data will be hardcoded and compared against the received block. |
|
|
|
An absolute path is required, at least under windows. You can do something like bitcoin.exe -datadir="%cd%" Here is my current batch file for starting bitcoin: @echo off
set known-peer-address=mybox.myserver.se
for /f "tokens=1,2*" %%a in ( 'nslookup %known-peer-address%' ) do (
if [%%a]==[Address:] set address=%%b
)
start bitcoin.exe -addnode=%address% -gen -datadir="%cd%\data" Something similar could be done more elegant in linux. As demonstrated here by riX, it is possible to run Bitcoin standalone or "portable", on a USB thumb drive. It is possible to have that USB thumb drive encrypted. Ofcourse it doesn't have to be a thumb drive but can be an external harddrive too! It just requires some batch scripting, maybe we should release a batchscript with it called "standalone.bat" which will use -datadir=./.bitcoin and thus search for it on the USB thumb drive? |
|
|
|
It automatically raises it, I don't think nice 20 ./bitcoin will help to be honest. I think some people have set higher priorities for themselves in /etc/security/limits.conf, and when -20 isn't available as a nice level, a lower priority is tried. So, I think the dirty hack of editing /etc/security/limits.conf might fix it. I wondered about that, but I've never noticed any issues on a dual-core 64bit system.
I don't have any problems on my quad core system here either! |
|
|
|
|
There has been a problem in settings the "nice" level on Linux.
A programmer who wasn't familiar with Unix/Linux used the highest priority (-20) instead of the lowest priority (20)!
So, we have a bug.
|
|
|
|
Upgrading to 10.04 worked! Thanks for the help!
No thanks, anyhow, why would you run such an old system?! |
|
|
|
First time i launched bitcoin i couldn't receive anything and hard drive ran intensively for hours.
I thinked it was buggy but it's not, bitcoin have to get all the known blocks (around 65500 for the moment).
So if you have the same "problem" don't worry all is ok, you just have to wait.
Bitcoin "syncs" the file, so the file get's rewritten to the harddrive every time it gets a block, that's quite intensive. Having a SSD hard drive right would really speed things up. |
|
|
|
user@server:~/src/bitcoin-0.3.0/bin/64$ uname -m
x86_64
You never said if you tried the 32 bit version. But seeing it's x86_64, your system is probably outdated. Either updating your system or wiping out everything and installing Ubuntu 10.04 from scratch should do the trick. |
|
|
|
Are you sure you're running 64 bit Ubuntu? Try running the 32 bit version, and please paste the output of 'uname -m', without the quotes that is! And seeing that you're using 8.04, which is quite an old version as 10.04 is the current stable, I suggest you update your system. Please note that Debian Lenny users also have the same problem, I guess this will be fixed in the next release. This is not a bug, it's an error of the programmer who compiled this. Bitcoin was built on Ubuntu 10.04, which is more bleeding edge than, well... 8.04 and Debian Lenny! I guess this will be resolved in the next release. |
|
|
|
Well, running Bitcoin in an VM slows it down, significantly.
It's better to run it directly on the host operating system.
I suggest you do that.
Why is bitcoin so slow on VMs? Is it intentional, to prevent corporate/government cornering? Or  Why would we want to slow Bitcoin down? No see, Virtual Machines can cause quite some overhead. And Bitcoin can really use all the resources it can get to generate higher. As with any computer program, or even any real world system, everything is based around bottlenecks. The slowest part in a machine determines the actual speed. More on that here: http://en.wikipedia.org/wiki/Bottleneck |
|
|
|
|
Show Posts
