This should be fixed in SVN. |
|
|
|
|
Generating addresses is CPU-intensive, and you don't touch the network when you generate a new address. It could only cause damage if a non-unique address was created, but this is so unlikely that it's not even worth considering.
|
|
|
|
No. It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. So you would only download the most recent 200 or so blocks and then new blocks as they come in, relying on the network to verify the blocks for you. It would be a really lightweight way to use BitCoin. It would even be useful for "full network nodes" as they are downloading the whole block chain. Congrats on 100 posts!  |
|
|
|
|
TCP doesn't work with multicasting. And I doubt it will ever be easy for a home user to join a multicast group.
|
|
|
|
|
The BitCoin paper mentions "simplified payment verification" that could be used to accept payments without downloading all of the blocks. I don't know if this is implemented yet. It might only be enabled for clients that have "generate BitCoins" turned off.
|
|
|
|
Difficulty increased by a lot. GetNextWorkRequired RETARGET
nTargetTimespan = 1209600 nActualTimespan = 825067
Before: 1c20bca7 0000000020bca700000000000000000000000000000000000000000000000000
After: 1c16546f 0000000016546f575ab277f44c118de5ab277f44c118de5ab277f44c118de5ab The target decreased by 31.79%, so you should be generating 31.79% fewer BitCoins. |
|
|
|
|
Did your new installation finish downloading all of the blocks (currently about 54,200)? The transaction probably won't appear until it does.
|
|
|
|
|
Your CPU is creating SHA-256 hashes. It's not possible to cheat: if the hashes you create are invalid, no one else in the network will accept them. If you inject a 50,000-block chain of "easy blocks" into the network, everyone will immediately see that the hash for the first block in the chain is above the current target and ignore it and every block derived from it.
|
|
|
|
|
Difficulty just had a huge jump from 7.8% to 11.5% -- likely the biggest jump so far. Link2Voip sent out an email promoting BitCoin, so maybe they're responsible.
|
|
|
|
|
PayPal payments can be easily reversed. Unless an irreversible system like Liberty Reserve is used, it would be better for you to handle the payments.
Does BitCoin Market fill orders partially if the entire amount is not available?
|
|
|
|
|
Neither of those cards support SHA-256.
I would want to test several CPUs to see which has the best hashes-to-watts ratio. I suspect that a few modern CPUs would actually be better than a lot of old ones, but I'm not sure. All each node would need is a motherboard, CPU(s), and 512MB of RAM. They can boot from the network.
|
|
|
|
|
Deflation isn't a big problem because coins are very divisible. If only 5 coins remain in the system, people can just trade in 0.0000001 coin increments or something.
Proofs-of-work can't be reused like that because they are hashes of a particular block's contents.
|
|
|
|
|
Did you try "LD_LIBRARY_PATH=/usr/lib ./bitcoin"? Are you sure libcrypto.so.0.9.8 actually exists?
|
|
|
|
|
If BitCoin counted the number of hashes it calculates per second/minute, it would be possible to determine the average number of blocks that will be solved per day. This would be very useful.
If hashing works the way I think it does (nonce is incremented per try), this data could be gathered efficiently by saving the start nonce and start time and comparing it to the end nonce and end time whenever the nonce is regenerated.
|
|
|
|
|
The number of coins created per block is halved every 4 years, not the number of blocks created. 50 coins are created per block now. When we reach about 200,000 blocks, each block will be worth 25 coins. After another 200,000 blocks (4 years), each block will be worth 12.5 coins.
|
|
|
|
|
The network adjusts the difficulty so that roughly 6 blocks are created network-wide every hour. Each block can contain lots of transactions.
|
|
|
|
Do all CPUs--no matter their strength--produce the same amount of coins at the same rate? No. For each SHA-256 hash you calculate, you get one chance of solving the block. Better CPUs can hash more data per second. If not, can I give the Bitcoin application the highest priority on a system and dedicate all of the CPUs power to Bitcoin production? Will this produce more coins compared to running the application normally? It'll already use 100% of the CPU's capacity if nothing else wants to. Setting priority just says, "If CPU resources are scarce, prefer the higher-priority program over the lower one." |
|
|
|
Cool. This could be an easier alternative to Exchange Zone for exchanging digital currencies, with BitCoin as the medium of exchange. Do you charge any fees? |
|
|
|
Here's the approximate number of BitCoins that will be created over a 25-year period (starting now). An unpredictable number will be lost, though.  The JavaScript and resulting csv data is attached if you want to make a better graph. |
|
|
|
|
Show Posts
