I think we should be signing the Windows binaries as well. Binary signatures are not only used by browsers and the OS when running setup programs. Anti-virus scanners also use them to build binary reputations and avoid false positives. Bitcoin does things that can look a tiny bit malware like (connecting to P2P networks and exchanging lots of random-looking data), so signing the executables can't hurt.
I don't think Microsoft doing an Apple and trying to ban unsigned code is going to ever happen, at least not on regular desktop Windows. There are far, far, far too many legacy/in-house apps out there that are business critical and yet never been signed, never will be signed.
Topic: Bitcoin-Qt / bitcoind version 0.8.0 release candidate 1 - page 2. (Read 20789 times)
The windows setup.exe is signed, as is the Mac .app bundle. The executables inside them are not signed (I can't think of a good reason to sign them, it would not increase download security at all).
You can also still check the download packages using the SHASUMS.asc file, which is signed with my gpg key.
And if you are running Linux or Windows you could check all of the files in the installer against other core developer's keys.
If the code signing certificate was revoked then we would go back to just using gpg keys. The code signing certificate is great because Windows and OSX know how to check it automatically when the download happens.
You can also still check the download packages using the SHASUMS.asc file, which is signed with my gpg key.
And if you are running Linux or Windows you could check all of the files in the installer against other core developer's keys.
If the code signing certificate was revoked then we would go back to just using gpg keys. The code signing certificate is great because Windows and OSX know how to check it automatically when the download happens.
Thank you very much for the clarification. My concern was actually would the .exe would continue to run under Windows 8 if the certificate was revoked after installation? I believe that under Windows XP/Vista/7 the .exe would continue to run, but I am not clear under Windows 8. The possible danger here is Microsoft being able to shut-down Bitcoin-Qt / bitcoind after installation by revoking the certificate hence the reference to a Treacherous Computing attack.
I did run into a somewhat similar situation back in 2005 where an expired certificate on APC PowerChute not only prevented the software from installing but also caused significant damage to the Windows registry. I spent the better part of a Sunday afternoon fixing the Windows registry in order to bring the server back to health The OS was Windows Server 2003. Granted this was an installation faliure but given the direction that Microsoft is taking with Windows 8 RT, I would be rather safe than sorry when it comes to Windows 8 on Intel/AMD.
The windows setup.exe is signed, as is the Mac .app bundle. The executables inside them are not signed (I can't think of a good reason to sign them, it would not increase download security at all).
You can also still check the download packages using the SHASUMS.asc file, which is signed with my gpg key.
And if you are running Linux or Windows you could check all of the files in the installer against other core developer's keys.
If the code signing certificate was revoked then we would go back to just using gpg keys. The code signing certificate is great because Windows and OSX know how to check it automatically when the download happens.
You can also still check the download packages using the SHASUMS.asc file, which is signed with my gpg key.
And if you are running Linux or Windows you could check all of the files in the installer against other core developer's keys.
If the code signing certificate was revoked then we would go back to just using gpg keys. The code signing certificate is great because Windows and OSX know how to check it automatically when the download happens.
Mac and Windows binaries are signed with certificates owned by the Bitcoin
Foundation, to be compatible with the new security features in OSX 10.8 and
Windows 8.
are these signatures only visible in windows 8? because i'm looking at the binary and it does not have a digital signature. Foundation, to be compatible with the new security features in OSX 10.8 and
Windows 8.
...
Improvements
------------
Mac and Windows binaries are signed with certificates owned by the Bitcoin
Foundation, to be compatible with the new security features in OSX 10.8 and
Windows 8.
...
What happens if these certificates are revoked? Could this lead to a Treacherous Computing, http://www.gnu.org/philosophy/can-you-trust.html, attack against Bitcoin?
using win7 64bit.
during sync the client crashed twice claiming the db is corrupted. first time restarting the client helped, second time i had to reboot. now its running smooth.
during sync the client crashed twice claiming the db is corrupted. first time restarting the client helped, second time i had to reboot. now its running smooth.
Fully syncs up without a problem on Windows 7 x64. Haven't done any transactions on it though.
Around block 188,000, bitcoin threw an error that it "could not write block" and exited. Continuing to download the blockchain without issue after a restart.
This is a fresh install on Windows 7 x64.
This is a fresh install on Windows 7 x64.
ie. each file's number went down by one, and a new file was started even though the previous one (was #3, now #2) didn't get anywhere near to 2GB.
Is that normal?
Is that normal?
Yes. The new code creates 128 MB block files, but it will keep the old ones as is.
Before the upgrade, I had:
After the upgrade, I have:
ie. each file's number went down by one, and a new file was started even though the previous one (was #3, now #2) didn't get anywhere near to 2GB.
Is that normal?
Code:
-rw------- 1 chris chris 2097307549 Aug 8 2012 blk0001.dat
-rw------- 1 chris chris 2097177246 Dec 4 18:48 blk0002.dat
-rw------- 1 chris chris 1420134352 Feb 12 11:52 blk0003.dat
-rw------- 1 chris chris 2097177246 Dec 4 18:48 blk0002.dat
-rw------- 1 chris chris 1420134352 Feb 12 11:52 blk0003.dat
After the upgrade, I have:
Code:
-rw------- 2 chris chris 2097307549 Aug 8 2012 blocks/blk00000.dat
-rw------- 2 chris chris 2097177246 Dec 4 18:48 blocks/blk00001.dat
-rw------- 2 chris chris 1420134352 Feb 12 11:52 blocks/blk00002.dat
-rw------- 1 chris chris 50331648 Feb 13 19:21 blocks/blk00003.dat
-rw------- 2 chris chris 2097177246 Dec 4 18:48 blocks/blk00001.dat
-rw------- 2 chris chris 1420134352 Feb 12 11:52 blocks/blk00002.dat
-rw------- 1 chris chris 50331648 Feb 13 19:21 blocks/blk00003.dat
ie. each file's number went down by one, and a new file was started even though the previous one (was #3, now #2) didn't get anywhere near to 2GB.
Is that normal?
Upgrade process went great for me. Took 23 minutes (Debian Squeeze, 32GB RAM, 8 Core CPU, and Hardware Raid 6). Shut it down, backed up data, removed blk* files, and restarted. No problems thus far. P2pool seems to like it just fine.
Ran with:
bitcoin-qt.exe -datadir=E:\bitcoin_database -dbcache=4000 -logtimestamps -txindex=1 -reindex=1
On i7 with 4 core+HT with 12gig ram on a nice new ssd on win7 64bit.
Took 30mins till started checking sigs. Then took another 30mins for last 4000ish blocks.
Used max of about 1.5-1.7gig.
Never read from disk for the chainstate - only wrote .logs
Only re-orged the blocks/index a few times.
Was entirely CPU bound. Initially on one thread then on all threads whilst checking sigs (ran at about 80% of the 8 virtual core busy which with hyperthreading is probably ideal).
Did a bit of checking in log file and are checking 1200 trans/second.
bitcoin-qt.exe -datadir=E:\bitcoin_database -dbcache=4000 -logtimestamps -txindex=1 -reindex=1
On i7 with 4 core+HT with 12gig ram on a nice new ssd on win7 64bit.
Took 30mins till started checking sigs. Then took another 30mins for last 4000ish blocks.
Used max of about 1.5-1.7gig.
Never read from disk for the chainstate - only wrote .logs
Only re-orged the blocks/index a few times.
Was entirely CPU bound. Initially on one thread then on all threads whilst checking sigs (ran at about 80% of the 8 virtual core busy which with hyperthreading is probably ideal).
Did a bit of checking in log file and are checking 1200 trans/second.
upgraded on OSX 10.6.8, rescanning blocks took about 8 hrs but it seems to load faster now. connects to more peers than 0.7.2, before I would often be stuck at 8.
Working fine on a Macbook Pro OSX Snow Leopard.
Here's the debug log's tail:
...
LoadBlockIndex(): transaction index disabled
LoadBlockIndex(): hashBestChain=0000000000000290e9c5ca7f9c4fb014c4f9f639dcffa6821c4616b7762509f7 height=220932 date=2013-02-13 09:02:08
init message: Verifying block database integrity...
Verifying last 288 blocks at level 3
LevelDB read failure: IO error: /home/default/.bitcoin/chainstate/029837.sst: No such file or directory
************************
EXCEPTION: 13leveldb_error
Database I/O error
bitcoin in Runaway exception
Is there any way to recover from this error?
I double-checked that there's plenty of disk space left.
...
LoadBlockIndex(): transaction index disabled
LoadBlockIndex(): hashBestChain=0000000000000290e9c5ca7f9c4fb014c4f9f639dcffa6821c4616b7762509f7 height=220932 date=2013-02-13 09:02:08
init message: Verifying block database integrity...
Verifying last 288 blocks at level 3
LevelDB read failure: IO error: /home/default/.bitcoin/chainstate/029837.sst: No such file or directory
************************
EXCEPTION: 13leveldb_error
Database I/O error
bitcoin in Runaway exception
Is there any way to recover from this error?
I double-checked that there's plenty of disk space left.
I have a feeling that the tech support answer for this will be "remove the index directories and reindex".
I would try fsck, and then look in lost+found for a 0-2MB file. Move it to the datadir as 029837.sst. See if Bitcoin doesn't stop crashing.
Here's the debug log's tail:
...
LoadBlockIndex(): transaction index disabled
LoadBlockIndex(): hashBestChain=0000000000000290e9c5ca7f9c4fb014c4f9f639dcffa6821c4616b7762509f7 height=220932 date=2013-02-13 09:02:08
init message: Verifying block database integrity...
Verifying last 288 blocks at level 3
LevelDB read failure: IO error: /home/default/.bitcoin/chainstate/029837.sst: No such file or directory
************************
EXCEPTION: 13leveldb_error
Database I/O error
bitcoin in Runaway exception
Is there any way to recover from this error?
I double-checked that there's plenty of disk space left.
...
LoadBlockIndex(): transaction index disabled
LoadBlockIndex(): hashBestChain=0000000000000290e9c5ca7f9c4fb014c4f9f639dcffa6821c4616b7762509f7 height=220932 date=2013-02-13 09:02:08
init message: Verifying block database integrity...
Verifying last 288 blocks at level 3
LevelDB read failure: IO error: /home/default/.bitcoin/chainstate/029837.sst: No such file or directory
************************
EXCEPTION: 13leveldb_error
Database I/O error
bitcoin in Runaway exception
Is there any way to recover from this error?
I double-checked that there's plenty of disk space left.
Dan, I think there might be something wrong with your hard disk. Check /var/log/messages .... it shouldn't take a day to index 4000 blocks. Also if a hard disk is dying, getting very slow is one of the first symptoms.
The checkpoint for this release is 216116, the current block is 220944. Full verification is done on block contents after the checkpoint, so it is expected to run slower on the last 4000 blocks.
I just finished an upgrade of a previously synchronized Bitcoin 0.7.2 on Win7, it took 70 minutes from startup to "up to date".
The Win32 client reports being built with Qt 4.8.3, the current release is v4.8.4, and has a good many fixes.
I just finished an upgrade of a previously synchronized Bitcoin 0.7.2 on Win7, it took 70 minutes from startup to "up to date".
The Win32 client reports being built with Qt 4.8.3, the current release is v4.8.4, and has a good many fixes.
Upgraded a 32-bit system running 0.7.3 on Debian Squeeze. The conversion of the old blocks seemed to slow down near the end, but left things running overnight and everything worked.
Pretty much a similar story here. On Ubuntu LTS running with -reindex.
A significant slowdown towards the last 4000 blocks. Took almost a day to reindex those 4000.
Another issue:
I had to reset my machine (cold restart) and now I get in terminal upon launching bitcoin-qt:
************************
EXCEPTION: 13leveldb_error
Database I/O error
bitcoin in Runaway exception
I'm on ext4 with journaling.
Geez, I thought LevelDB on a journaling fs can't be corrupted by a reset.
- Installed 0.7.2 on a WinXP box (vmware virtual machine).
- Downloaded some blocks, up to 135k or so.
- Cleanly shut down bitcoin.
- Installed 0.8.0rc1.
- Bitcoin sucessfully reindexed the existing blocks, then started to download from that point.
- Suspended the virtual machine.
- Downloaded some more blocks from home, then suspended the VM again.
- (related?) Installed Ares p2p software. Version 2.2.4 FWIW. (this was yesterday at home)
- Today at work, downloaded more blocks.
- While clicking around on Ares, I got a couple of dialog boxes about Visual C++ runtime
and mentioning bitcoin. However, I was able to click on the bitcoin window and bring it to top, giving it focus. I wasn't able to do that with Ares though (when I tried, one of the dialog boxes' title flashed, indicating me that I had to pay attention to it before using Ares again). So I happily disregarded the dialogs, only to see the bitcoin window disappear and the Ares one become unresponsive.
Code:
received block 00000000000000ad0e1ec1f69424abd586077ef7a7b953ecec8ebafa30a61ee2
ProcessBlock: ORPHAN BLOCK, prev=00000000000006c74bc0eaf942f5c93b53afd19c4b7d4b0ed35dcfe549ea824f
received block 00000000000006a58a50091c4feb7d8af30cb316ba6ecae8472efb29f125d9e5
ProcessBlock: ORPHAN BLOCK, prev=00000000000000ad0e1ec1f69424abd586077ef7a7b953ecec8ebafa30a61ee2
received block 000000000000051cfd88579acf5d0a5d20bd0232dc7ca174dd057e35ecf15187
ProcessBlock: ORPHAN BLOCK, prev=00000000000006a58a50091c4feb7d8af30cb316ba6ecae8472efb29f125d9e5
received block 000000000000006e3986d9f8510fc62cf8370678ca501ba24c228184cd268bef
ProcessBlock: ORPHAN BLOCK, prev=000000000000051cfd88579acf5d0a5d20bd0232dc7ca174dd057e35ecf15187
************************
EXCEPTION: St9bad_alloc
std::bad_alloc
C:\Archivos de programa\Bitcoin\bitcoin-qt.exe in ThreadMessageHandler()
************************
EXCEPTION: St9bad_alloc
std::bad_alloc
C:\Archivos de programa\Bitcoin\bitcoin-qt.exe in ThreadSocketHandler()
Flushed 12767 addresses to peers.dat 78ms
Sorry no timestamping (it should be on by default IMHO). Searching for "EXCEPTION" in the debug.log I find two additional bad_alloc messages. One of them appears 400 lines above this, so most probably it happened earlier today. The other one could be from yesterday, can't tell for sure. They could be related to the VM suspends.
Jump to: