On Windows, findstr /c:"version message" debug.log It looks like the bad chain was on block 74678 recently. Can't wait to overtake it. On the stats at http://nullvoid.org/bitcoin/statistix.php there's been 5 blocks per hour in the last 3 hours. We had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour. |
|
|
|
|
The bad chain is also slowed down as more nodes upgrade.
We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain.
|
|
|
|
Most people running clients are not reading this message thread. So... Silly questions:
1) How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?
2) How will this affect clients that upgrade to 3.8.10 but don't remove their block chain files?
1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations. 2) If you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain. |
|
|
|
I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?
If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes. For today, try adding these parameters: -addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14 See http://bitcointalk.org/index.php?topic=828 |
|
|
|
Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain.
What is the status of that transaction?
From what I can tell, my (updated) sending client wallet shows the deducted amount.
Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?
Right, it will get reincorporated into the fixed chain. The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again. It's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear. Any blocks in the bad chain wouldn't have matured yet. |
|
|
|
|
For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP? Then we can -addnode= them and make sure to connect to at least one 0.3.10 node.
|
|
|
|
|
I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower. We need enough of us so that at least one node you connect to will be 0.3.10. The problem will start to go away when we make up more than 1/8th of the network.
It'll help if you port forward so you can get lots of connections.
|
|
|
|
Version 0.3.10 patches the block 74638 overflow bug. http://bitcointalk.org/index.php?topic=823The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's. Try the "-4way" switch to enable it and check if it's faster for you. Download from sourceforge: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip It is no longer necessary to delete blk*.dat. The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain. |
|
|
|
I think that you should add something about this: http://bitcointalk.org/index.php?topic=259.0There must be a label on the client that show a warning message if needed  Now everyone have always to check the website, and I think that this is bad. Agree, wanted to do that for a long time, haven't had time to do it. For now, you could also subscribe to the bitcoin-list mailing list. It rarely gets used except for announcements like this and major new versions. Subscribe/unsubscribe page: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list |
|
|
|
[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain.  Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice. |
|
|
|
Don't update the block chain download. When you take someone's block chain download, you don't want it right up to the end. A somewhat old one is better so it can download and verify the most recent blocks. tcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago. I just now uploaded rev 134 which is the makefile.unix that enables building with it on Linux. If you build rev 134 on Linux now you'll get the -4way switch. If you have problems building because of it, then edit makefile.unix and: - remove -DFOURWAYSSE2 - remove obj/sha256.o from the end of these lines: bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o The 0.3.10 linux build will have the -4way option when I build it. Here are the patch downloads for Windows: http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exehttp://www.bitcoin.org/download/bitcoin-0.3.10-win32.zipSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip Steps: 1) Shut down. 2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat files. http://knightmb.dyndns.org/files/bitcoin/blocks/http://rapidshare.com/files/413168038/BitcoinBlocks.torrent3) Upgrade to 0.3.10. 4) It should start out with less than 74000 blocks and redownload the rest. Or if you don't want to mess with downloading blk files, you can just do this: 1) Shut down. 2) Delete (or move) blk*.dat 3) Upgrade to 0.3.10. 4) It redownloads all blocks, probably take about an hour. |
|
|
|
|
Patch is uploaded to SVN rev 132!
For now, recommended steps:
1) Shut down.
2) Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat files)
3) Upgrade.
4) It should start out with less than 74000 blocks. Let it redownload the rest.
If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.
I'll build releases shortly.
|
|
|
|
|
Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends before block 74000 so the most recent security lockin will check it. Can someone find the link for that?
|
|
|
|
|
It would help if people stop generating. We will probably need to re-do a branch around the current one, and the less you generate the faster that will be.
A first patch will be in SVN rev 132. It's not uploaded yet. I'm pushing some other misc changes out of the way first, then I'll upload the patch for this.
|
|
|
|
Here's the preliminary change. Look right? I have more changes to make, this isn't all of it. Will SVN shortly. bool CheckTransaction() const
{
// Basic checks that don't depend on any context
if (vin.empty() || vout.empty())
return error("CTransaction::CheckTransaction() : vin or vout empty");
// Check for negative and overflow values
int64 nTotal = 0;
foreach(const CTxOut& txout, vout)
{
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
if (txout.nValue > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout.nValue too high");
nTotal += txout.nValue;
if (nTotal > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout total too high");
}
if (IsCoinBase())
{
if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
return error("CTransaction::CheckTransaction() : coinbase script size");
}
else
{
foreach(const CTxIn& txin, vin)
if (txin.prevout.IsNull())
return error("CTransaction::CheckTransaction() : prevout is null");
}
return true;
}
Don't sticky the topic, nobody looks up there. There'll be enough posts to bump. |
|
|
|
|
I just uploaded a quick build so testers can check if I built it right. (I don't have an i5 or AMD) If it checks out, I'll put together the full package and do all the release stuff.
|
|
|
|
|
I hope someone can test an i5 or AMD to check that I built it right. I don't have either to test with.
I'm also curious if it performs much worse on 32-bit linux vs 64-bit.
|
|
|
|
the extended-help might have been based on my idea, but the code was somewhat different.
The idea was the main part. When you posted your patch, I realized it should have been done that way instead of "-?". I always had reservations about "-?" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server. |
|
|
|
|
Some places where generation will gravitate to:
1) places where it's cheapest or free
2) people who want to help for idealogical reasons
3) people who want to get some coins without the inconvenience of doing a transaction to buy them
There are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience.
How expensive is heating oil? With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.
There's also kids putting it on their parent's power bill, employees their employer, botnets, etc.
Case 3 comes into play for small amounts. The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments. I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change.
|
|
|
|
|
Show Posts
