The client generates a new address for you whenever the current one receives a transaction. The old addresses are still usable.
|
|
|
It's probably just a false positive. The bitcoin.exe I downloaded had the same MD5, so it probably wasn't intercepted at your end, at least.
|
|
|
I think it's already impossible by this point.
I've read (or skimmed through, at least) every post ever posted to the English boards other than "mining", so it isn't impossible.
|
|
|
It's becoming difficult to read all of the posts. Several threads I just skim nowadays.
|
|
|
You might as well just delete the page if you're going to do that. Probably less than 5% of existing services will post their identity information. I certainly wouldn't if I had a service on there.
|
|
|
So a transaction that gets recorded in block 1 won't be confirmed until block 2 is voted most accurate?
It gets one confirmation from the block that included it, the next block results in two total confirmations, etc. Also, what happens if my miner is working in block X and declares it self a winner (and sends it out), then I get a block from somebody else who claims they are the winner? What happens now...?
Whoever solves the next block decides. Until then, you assume yours will win.
|
|
|
Everyone doesn't broadcast their blocks. You only broadcast your block if you win, and you broadcast as soon as you win. 10 minutes is only an average because people can win at any time. It's like everyone is drawing raffle tickets as fast as possible from the same giant pool of tickets, and whenever someone pulls out a winning value, they yell, "I won!". When you solve a block, you send it to all your peers. They send it to all their peers, etc. Nodes don't broadcast blocks that they've already seen, so this eventually stops. Whoever solves the next block gets to vote for which previous block they think is accurate. Read: http://www.bitcoin.org/bitcoin.pdfThe wiki pages "network" and "block" (down right now)
|
|
|
Yup. I think this might be the last release I do that, though...
EDIT: Done, svn revision 251.
Thanks. I thought the idea of using SVN for "release candidate" code was good. Stability and security are very important for Bitcoin, so there needs to be a long testing period before stable releases are made.
|
|
|
Deleted. There are probably thousands of these. I wonder how dangerous it would be to delete all users with 0 posts that haven't logged in for a month. That'd be easier than checking every 0-post user for spam.
|
|
|
Generations won't show up on your MtGox/MyBitcoin/etc. balance, so make sure you use the address of a standalone client for payouts.
|
|
|
Are you going to put the source on SourceForge SVN?
|
|
|
Really old coins might be collected.
|
|
|
It would be cool to set up a bitcoin.org newsgroup server for serious discussion. Possibly this could also be attached to a mailing list system.
|
|
|
Off-topic discussion about repeat questions split.
|
|
|
Hardly anyone reads FAQ posts, and even fewer people read giant walls of text not organized into sections. Just post a link to a "canonical topic" in response to repeated questions.
|
|
|
Surely you're mistaken about how nLockTime transactions work.
No. They fail IsFinal(), which causes them not to be included. If they are included, the block will be invalid. They're stored in the memory pool like normal unconfirmed transactions. The sender and recipient can resend them to keep them fresh.
|
|
|
26 characters: 11111111111111111111BZbvjr I did wrongly remember the upper limit, though. It is 34 characters. I must have flipped the digits in my head.
|
|
|
If someone makes Bitcoin unusable for a long time by controlling >50% of the network, people might start weighting the "work" value of a chain by looking at its behavior in handling transactions. A chain of 20 blocks with no transactions is very likely to be malicious, for example. As long as it's done by weighting instead of outright rejection, legitimate clients shouldn't ever stay on separate chains for long.
|
|
|
|