Search content
Sort by
Showing 19 of 19 results by sflicht
Small request, because it would have saved me some time today. I think the releases page on the website should prominently point out that you need to delete/rename the databases folder when upgrading from 0.93 to 0.94 or 0.95.
sflicht:
You either let Armory manage bitcoind for you, or you start BitcoinQt manually and let it sync fully before you start Armory. Instead, you are starting BitcoinQt and letting Armory run on top of a blocks folder that Core is still indexing through milestones hashes, which guarantees you'll run into missing block data. Let BitcoinQt do its thing then start Armory.
You either let Armory manage bitcoind for you, or you start BitcoinQt manually and let it sync fully before you start Armory. Instead, you are starting BitcoinQt and letting Armory run on top of a blocks folder that Core is still indexing through milestones hashes, which guarantees you'll run into missing block data. Let BitcoinQt do its thing then start Armory.
First, the OS X version does not support Armory management of bitcoind, so I'm stuck with the BitcoinQt approach.
Second, I guess I can just wait till the blockchain downloads, and then have Armory build its db afterwards. But is there some reason in principle that Armory cannot recognize incomplete blocks? During normal operation (i.e. after most of the blockchain is downloaded), Bitcoin-Qt is periodically getting new blocks, so there is a short window every 10 minutes when the situation is similar. Also during normal operation, I assume Armory periodically scans for new blocks (after Bitcoin-Qt tells it a new one has arrived), to extend its own database and display fresh data to the user. When it does this, there are probably no new partial blocks yet (because the next one wouldn't come for at least 10 minutes). But there is a small chance that two blocks are found almost simultaneously, right? In which case, right after Bitcoin-Qt tells armory it's ok to update its db, it might start downloading other partial blocks from random peers. So why couldn't the same "missing block data" cause crashes even after the initial bootstrap? Or are there certain state guarantees about ~/.bitcoin/blocks that are satisfied *except* during the initial bootstrap?
Apologies if these are dumb questions, just curious.
Regardless, the documentation (for all versions, but especially OS X since there's no choice) should probably be clarified to inform the user who is manually running bitcoin-qt that they must not run Armory until the blockchain is "fully" downloaded. I did see this on a non-official website about armory, but I assumed it was probably wrong and just a waste of time.
FWIW the 0.93.0.7 patch seems *more* unstable on OS X: instead of popups about BDM errors, it just crashes outright.
I've included the OS error traceback and the ERROR part of my armory log below.
Log file opened at 1425473672: /Users/sflicht/Library/Application Support/Armory/armorycpplog.txt
-INFO - 1425473685: (BlockUtils.cpp:861) blkfile dir: /Users/sflicht/Library/Application Support/Bitcoin/blocks
-INFO - 1425473685: (BlockUtils.cpp:862) lmdb dir: /Users/sflicht/Library/Application Support/Armory/databases
-INFO - 1425473685: (lmdb_wrapper.cpp:478) Opening databases...
-INFO - 1425473685: (BlockUtils.cpp:1193) Executing: doInitialSyncOnLoad_Rescan
-INFO - 1425473685: (BlockUtils.cpp:1255) Total number of blk*.dat files: 78
-INFO - 1425473685: (BlockUtils.cpp:1256) Total blockchain bytes: 10,461,603,124
-INFO - 1425473685: (BlockUtils.cpp:1597) Reading headers from db
-INFO - 1425473686: (BlockUtils.cpp:1623) Found 254495 headers in db
-DEBUG - 1425473686: (Blockchain.cpp:211) Organizing chain w/ rebuild
-WARN - 1425473686: (BlockUtils.cpp:1285) --- Fetching SSH summaries for 1000 registered addresses
-INFO - 1425473686: (BlockUtils.cpp:1298) Left off at file 77, offset 106193333
-INFO - 1425473686: (BlockUtils.cpp:1301) Reading headers and building chain...
-INFO - 1425473686: (BlockUtils.cpp:1302) Starting at block file 77 offset 106193333
-INFO - 1425473686: (BlockUtils.cpp:1304) Block height 254435
-DEBUG - 1425473687: (Blockchain.cpp:211) Organizing chain w/ rebuild
-INFO - 1425473687: (BlockUtils.cpp:1339) Looking for first unrecognized block
-INFO - 1425473687: (BlockUtils.cpp:1488) Loading block data... file 77 offset 98453429
-ERROR - 1425473687: (BlockUtils.cpp:536) Next block header found at offset 98453437
-INFO - 1425473687: (BlockUtils.cpp:564) Reading raw blocks finished at file 77 offset 121385335
-INFO - 1425473687: (BlockUtils.cpp:1356) Wrote blocks to DB in 0.266411s
-ERROR - 1425473687: (lmdb_wrapper.cpp:1517) Block height exceeds DupID lookup table
-ERROR - 1425473687: (BlockUtils.cpp:1395) missing 58 block headers
-ERROR - 1425473687: (BDM_mainthread.cpp:427) BDM thread failed: Missing headers! This blockchain copy is corruptbeyond repair, time for a factory reset!
EDIT: Eventually managed to build the database and scan the tx history. Keeping my fingers crossed.
EDIT2: Still unstable. Bitcoin-QT is still slowly catching up, but Armory didn't seem to be communicating with it (~30 minutes without Armory getting the new blocks bitcoin downloaded). Restarting armory led to "Missing headers: factory reset required" errors. After a couple of "light" resets (no db rebuild) it seems to have resolved itself and is rescanning the tx history. I have no technical expertise on these matters, but I wonder if partially-downloaded blocks are causing issues?
I've included the OS error traceback and the ERROR part of my armory log below.
Code:
Process: Python [55136]
Path: /Users/USER/Downloads/Armory 2.app/Contents/MacOS/Python
Identifier: com.armory.armory
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Python [55136]
User ID: 501
Date/Time: 2015-03-04 07:52:28.384 -0500
OS Version: Mac OS X 10.10.2 (14C109)
Report Version: 11
Anonymous UUID: 5A98AC76-3157-7B75-505C-CA45B9237DF7
Sleep/Wake UUID: 6CFCD9AF-1AC6-4A02-BC77-B35669F33722
Time Awake Since Boot: 1200000 seconds
Time Since Wake: 8800 seconds
Crashed Thread: 5
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000011bb00000
VM Regions Near 0x11bb00000:
mapped file 000000011ab00000-000000011bb00000 [ 16.0M] r--/r-x SM=PRV /Users/USER/Library/Application Support/Bitcoin/*/*.dat
-->
MALLOC_LARGE 0000000122afc000-0000000122bf0000 [ 976K] rw-/rwx SM=PRV
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8c91d4de mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8c91c64f mach_msg + 55
2 com.apple.CoreFoundation 0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fff86a08ffb __CFRunLoopRun + 1371
4 com.apple.CoreFoundation 0x00007fff86a08858 CFRunLoopRunSpecific + 296
5 com.apple.HIToolbox 0x00007fff8f7ebaef RunCurrentEventLoopInMode + 235
6 com.apple.HIToolbox 0x00007fff8f7eb86a ReceiveNextEventCommon + 431
7 com.apple.HIToolbox 0x00007fff8f7eb6ab _BlockUntilNextEventMatchingListInModeWithFilter + 71
8 com.apple.AppKit 0x00007fff87d8ff81 _DPSNextEvent + 964
9 com.apple.AppKit 0x00007fff87d8f730 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194
10 com.apple.AppKit 0x00007fff87d83593 -[NSApplication run] + 594
11 QtGui 0x0000000105b9387a QEventDispatcherMac::processEvents(QFlags) + 538
12 QtCore 0x0000000105127cad QEventLoop::exec(QFlags) + 477
13 QtCore 0x000000010512aec7 QCoreApplication::exec() + 199
14 QtGui.so 0x0000000105392610 meth_QApplication_exec_(_object*, _object*) + 80
15 org.python.python 0x00000001000b0806 PyEval_EvalFrameEx + 20486
16 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
17 org.python.python 0x00000001000aaec6 PyEval_EvalCode + 54
18 org.python.python 0x00000001000d43e4 PyRun_FileExFlags + 164
19 org.python.python 0x00000001000d3f61 PyRun_SimpleFileExFlags + 769
20 org.python.python 0x00000001000eafd7 Py_Main + 3063
21 Python 0x0000000100000e55 0x100000000 + 3669
22 Python 0x0000000100000d71 0x100000000 + 3441
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8c923232 kevent64 + 10
1 libdispatch.dylib 0x00007fff8bc61a6a _dispatch_mgr_thread + 52
Thread 2:: com.apple.CFSocket.private
0 libsystem_kernel.dylib 0x00007fff8c9223fa __select + 10
1 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
2 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
3 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 3:
0 libsystem_kernel.dylib 0x00007fff8c91d4de mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8c91c64f mach_msg + 55
2 com.apple.CoreFoundation 0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fff86a08ffb __CFRunLoopRun + 1371
4 com.apple.CoreFoundation 0x00007fff86a08858 CFRunLoopRunSpecific + 296
5 com.apple.AppKit 0x00007fff87ef333b _NSEventThread + 137
6 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
7 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
8 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 4:
0 libsystem_kernel.dylib 0x00007fff8c9223fa __select + 10
1 org.python.python 0x00000001000b0806 PyEval_EvalFrameEx + 20486
2 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
3 org.python.python 0x000000010003658c function_call + 364
4 org.python.python 0x0000000100010d53 PyObject_Call + 99
5 org.python.python 0x00000001000aeccd PyEval_EvalFrameEx + 13517
6 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
7 org.python.python 0x00000001000b3139 fast_function + 297
8 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
9 org.python.python 0x00000001000b30d2 fast_function + 194
10 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
11 org.python.python 0x00000001000b30d2 fast_function + 194
12 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
13 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
14 org.python.python 0x000000010003658c function_call + 364
15 org.python.python 0x0000000100010d53 PyObject_Call + 99
16 org.python.python 0x000000010001dec6 instancemethod_call + 166
17 org.python.python 0x0000000100010d53 PyObject_Call + 99
18 org.python.python 0x00000001000b289d PyEval_CallObjectWithKeywords + 93
19 org.python.python 0x00000001000ed1a6 t_bootstrap + 70
20 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
21 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
22 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 5 Crashed:
0 libsystem_platform.dylib 0x00007fff8ae51fc9 _platform_memmove$VARIANT$Unknown + 41
1 _CppBlockUtils.so 0x0000000107205fce BinaryData::BinaryData(BinaryDataRef const&) + 78
2 _CppBlockUtils.so 0x0000000107257408 BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocksFromFile(BlockDataManager_LevelDB::BitcoinQtBlockFiles::BlkFile const&, unsigned long long, unsigned long long, std::__1::function const&, unsigned int)> const&) + 1144
3 _CppBlockUtils.so 0x0000000107254ead BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocks(std::__1::pair, std::__1::pair, std::__1::function const&, unsigned int)> const&) + 189
4 _CppBlockUtils.so 0x0000000107250883 BlockDataManager_LevelDB::loadBlockData(ProgressReporter&, std::__1::pair const&, bool) + 419
5 _CppBlockUtils.so 0x000000010724dfe9 BlockDataManager_LevelDB::loadDiskState(std::__1::function const&, bool) + 3081
6 _CppBlockUtils.so 0x00000001072a529e BlockDataManagerThread::run() + 462
7 _CppBlockUtils.so 0x00000001072a5019 BlockDataManagerThread::thrun(void*) + 9
8 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
9 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
10 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 5 crashed with X86 Thread State (64-bit):
rax: 0x0000000115d80000 rbx: 0x0000000107f00428 rcx: 0x000000000002902f rdx: 0x0000000000083a5c
rdi: 0x0000000115ddaa2d rsi: 0x000000011bb00000 rbp: 0x0000000107f00380 rsp: 0x0000000107f00380
r8: 0x0000000000000000 r9: 0x000000000000000b r10: 0x000000000000000d r11: 0xfffffffffa2daa2d
r12: 0x0000000000fa55cf r13: 0x0000000101b5a210 r14: 0x000000011baa55d3 r15: 0x0000000000083a5c
rip: 0x00007fff8ae51fc9 rfl: 0x0000000000010206 cr2: 0x000000011bb00000
Logical CPU: 2
Error Code: 0x00000004
Trap Number: 14
Binary Images: ....
Path: /Users/USER/Downloads/Armory 2.app/Contents/MacOS/Python
Identifier: com.armory.armory
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Python [55136]
User ID: 501
Date/Time: 2015-03-04 07:52:28.384 -0500
OS Version: Mac OS X 10.10.2 (14C109)
Report Version: 11
Anonymous UUID: 5A98AC76-3157-7B75-505C-CA45B9237DF7
Sleep/Wake UUID: 6CFCD9AF-1AC6-4A02-BC77-B35669F33722
Time Awake Since Boot: 1200000 seconds
Time Since Wake: 8800 seconds
Crashed Thread: 5
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000011bb00000
VM Regions Near 0x11bb00000:
mapped file 000000011ab00000-000000011bb00000 [ 16.0M] r--/r-x SM=PRV /Users/USER/Library/Application Support/Bitcoin/*/*.dat
-->
MALLOC_LARGE 0000000122afc000-0000000122bf0000 [ 976K] rw-/rwx SM=PRV
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8c91d4de mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8c91c64f mach_msg + 55
2 com.apple.CoreFoundation 0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fff86a08ffb __CFRunLoopRun + 1371
4 com.apple.CoreFoundation 0x00007fff86a08858 CFRunLoopRunSpecific + 296
5 com.apple.HIToolbox 0x00007fff8f7ebaef RunCurrentEventLoopInMode + 235
6 com.apple.HIToolbox 0x00007fff8f7eb86a ReceiveNextEventCommon + 431
7 com.apple.HIToolbox 0x00007fff8f7eb6ab _BlockUntilNextEventMatchingListInModeWithFilter + 71
8 com.apple.AppKit 0x00007fff87d8ff81 _DPSNextEvent + 964
9 com.apple.AppKit 0x00007fff87d8f730 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194
10 com.apple.AppKit 0x00007fff87d83593 -[NSApplication run] + 594
11 QtGui 0x0000000105b9387a QEventDispatcherMac::processEvents(QFlags) + 538
12 QtCore 0x0000000105127cad QEventLoop::exec(QFlags) + 477
13 QtCore 0x000000010512aec7 QCoreApplication::exec() + 199
14 QtGui.so 0x0000000105392610 meth_QApplication_exec_(_object*, _object*) + 80
15 org.python.python 0x00000001000b0806 PyEval_EvalFrameEx + 20486
16 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
17 org.python.python 0x00000001000aaec6 PyEval_EvalCode + 54
18 org.python.python 0x00000001000d43e4 PyRun_FileExFlags + 164
19 org.python.python 0x00000001000d3f61 PyRun_SimpleFileExFlags + 769
20 org.python.python 0x00000001000eafd7 Py_Main + 3063
21 Python 0x0000000100000e55 0x100000000 + 3669
22 Python 0x0000000100000d71 0x100000000 + 3441
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8c923232 kevent64 + 10
1 libdispatch.dylib 0x00007fff8bc61a6a _dispatch_mgr_thread + 52
Thread 2:: com.apple.CFSocket.private
0 libsystem_kernel.dylib 0x00007fff8c9223fa __select + 10
1 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
2 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
3 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 3:
0 libsystem_kernel.dylib 0x00007fff8c91d4de mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8c91c64f mach_msg + 55
2 com.apple.CoreFoundation 0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fff86a08ffb __CFRunLoopRun + 1371
4 com.apple.CoreFoundation 0x00007fff86a08858 CFRunLoopRunSpecific + 296
5 com.apple.AppKit 0x00007fff87ef333b _NSEventThread + 137
6 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
7 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
8 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 4:
0 libsystem_kernel.dylib 0x00007fff8c9223fa __select + 10
1 org.python.python 0x00000001000b0806 PyEval_EvalFrameEx + 20486
2 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
3 org.python.python 0x000000010003658c function_call + 364
4 org.python.python 0x0000000100010d53 PyObject_Call + 99
5 org.python.python 0x00000001000aeccd PyEval_EvalFrameEx + 13517
6 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
7 org.python.python 0x00000001000b3139 fast_function + 297
8 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
9 org.python.python 0x00000001000b30d2 fast_function + 194
10 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
11 org.python.python 0x00000001000b30d2 fast_function + 194
12 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
13 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725
14 org.python.python 0x000000010003658c function_call + 364
15 org.python.python 0x0000000100010d53 PyObject_Call + 99
16 org.python.python 0x000000010001dec6 instancemethod_call + 166
17 org.python.python 0x0000000100010d53 PyObject_Call + 99
18 org.python.python 0x00000001000b289d PyEval_CallObjectWithKeywords + 93
19 org.python.python 0x00000001000ed1a6 t_bootstrap + 70
20 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
21 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
22 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 5 Crashed:
0 libsystem_platform.dylib 0x00007fff8ae51fc9 _platform_memmove$VARIANT$Unknown + 41
1 _CppBlockUtils.so 0x0000000107205fce BinaryData::BinaryData(BinaryDataRef const&) + 78
2 _CppBlockUtils.so 0x0000000107257408 BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocksFromFile(BlockDataManager_LevelDB::BitcoinQtBlockFiles::BlkFile const&, unsigned long long, unsigned long long, std::__1::function const&, unsigned int)> const&) + 1144
3 _CppBlockUtils.so 0x0000000107254ead BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocks(std::__1::pair, std::__1::pair, std::__1::function const&, unsigned int)> const&) + 189
4 _CppBlockUtils.so 0x0000000107250883 BlockDataManager_LevelDB::loadBlockData(ProgressReporter&, std::__1::pair const&, bool) + 419
5 _CppBlockUtils.so 0x000000010724dfe9 BlockDataManager_LevelDB::loadDiskState(std::__1::function const&, bool) + 3081
6 _CppBlockUtils.so 0x00000001072a529e BlockDataManagerThread::run() + 462
7 _CppBlockUtils.so 0x00000001072a5019 BlockDataManagerThread::thrun(void*) + 9
8 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131
9 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176
10 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 5 crashed with X86 Thread State (64-bit):
rax: 0x0000000115d80000 rbx: 0x0000000107f00428 rcx: 0x000000000002902f rdx: 0x0000000000083a5c
rdi: 0x0000000115ddaa2d rsi: 0x000000011bb00000 rbp: 0x0000000107f00380 rsp: 0x0000000107f00380
r8: 0x0000000000000000 r9: 0x000000000000000b r10: 0x000000000000000d r11: 0xfffffffffa2daa2d
r12: 0x0000000000fa55cf r13: 0x0000000101b5a210 r14: 0x000000011baa55d3 r15: 0x0000000000083a5c
rip: 0x00007fff8ae51fc9 rfl: 0x0000000000010206 cr2: 0x000000011bb00000
Logical CPU: 2
Error Code: 0x00000004
Trap Number: 14
Binary Images: ....
Code:
Log file opened at 1425473672: /Users/sflicht/Library/Application Support/Armory/armorycpplog.txt
-INFO - 1425473685: (BlockUtils.cpp:861) blkfile dir: /Users/sflicht/Library/Application Support/Bitcoin/blocks
-INFO - 1425473685: (BlockUtils.cpp:862) lmdb dir: /Users/sflicht/Library/Application Support/Armory/databases
-INFO - 1425473685: (lmdb_wrapper.cpp:478) Opening databases...
-INFO - 1425473685: (BlockUtils.cpp:1193) Executing: doInitialSyncOnLoad_Rescan
-INFO - 1425473685: (BlockUtils.cpp:1255) Total number of blk*.dat files: 78
-INFO - 1425473685: (BlockUtils.cpp:1256) Total blockchain bytes: 10,461,603,124
-INFO - 1425473685: (BlockUtils.cpp:1597) Reading headers from db
-INFO - 1425473686: (BlockUtils.cpp:1623) Found 254495 headers in db
-DEBUG - 1425473686: (Blockchain.cpp:211) Organizing chain w/ rebuild
-WARN - 1425473686: (BlockUtils.cpp:1285) --- Fetching SSH summaries for 1000 registered addresses
-INFO - 1425473686: (BlockUtils.cpp:1298) Left off at file 77, offset 106193333
-INFO - 1425473686: (BlockUtils.cpp:1301) Reading headers and building chain...
-INFO - 1425473686: (BlockUtils.cpp:1302) Starting at block file 77 offset 106193333
-INFO - 1425473686: (BlockUtils.cpp:1304) Block height 254435
-DEBUG - 1425473687: (Blockchain.cpp:211) Organizing chain w/ rebuild
-INFO - 1425473687: (BlockUtils.cpp:1339) Looking for first unrecognized block
-INFO - 1425473687: (BlockUtils.cpp:1488) Loading block data... file 77 offset 98453429
-ERROR - 1425473687: (BlockUtils.cpp:536) Next block header found at offset 98453437
-INFO - 1425473687: (BlockUtils.cpp:564) Reading raw blocks finished at file 77 offset 121385335
-INFO - 1425473687: (BlockUtils.cpp:1356) Wrote blocks to DB in 0.266411s
-ERROR - 1425473687: (lmdb_wrapper.cpp:1517) Block height exceeds DupID lookup table
-ERROR - 1425473687: (BlockUtils.cpp:1395) missing 58 block headers
-ERROR - 1425473687: (BDM_mainthread.cpp:427) BDM thread failed: Missing headers! This blockchain copy is corruptbeyond repair, time for a factory reset!
EDIT: Eventually managed to build the database and scan the tx history. Keeping my fingers crossed.
EDIT2: Still unstable. Bitcoin-QT is still slowly catching up, but Armory didn't seem to be communicating with it (~30 minutes without Armory getting the new blocks bitcoin downloaded). Restarting armory led to "Missing headers: factory reset required" errors. After a couple of "light" resets (no db rebuild) it seems to have resolved itself and is rescanning the tx history. I have no technical expertise on these matters, but I wonder if partially-downloaded blocks are causing issues?
For anyone having issues with 0.93 BDM errors, I just pushed goatpig's fix into 0.93.0.70. Yeah weird version number. This will be 0.93.1 after we've confirmed it does what it's supposed to.
As usual, get it from the secure downloader within Armory (help->update software).
ashes of all installers [/url]
As usual, get it from the secure downloader within Armory (help->update software).
ashes of all installers [/url]
Secure downloader shows only 0.91 for OS X.
Have you incorporated the Ron-Shamir Entities into this? The paper's a little dated and it's unclear whether the balances on pg. 11 are still accurate, but it'd mean at least two additional billionaires.
If I recall correctly, the paper is from the time when bitcoin was trading at about $10. With my rake model, these entities have since shed 70% of their holdings, on average. I have included 350k DPR hidden stash and 400k mystery owners + all that I believe beyond reasonable doubt have 100k or more. The rest is statistics. The difficult part is that we don't know if for example Winklevoss have sold a part of their coins or not. They are sitting on 10,000% gains and their price projections are conservative so they may not be über bull.
The possible existence of large hidden holders is something that cannot be ruled out, still. The 400k may be 1-2M if somebody has a masterplan. At any rate it does not affect the rest of the distribution, and due to bitcoin's crashy nature, even economically I don't think these pose a threat. They are in position to do wonderful things though upon coming public
Risto, what's your best unbiased estimate of the number of bitcoin holders who use something approximating your rake model?
Re: RAM-Reduction & Backup Center Testing (version 0.89.99.16)
Hi,
Just a minor bug report. I'm running Ubuntu 13.04 64 bit. I managed to install 0.89.99.16 today (it's building the database now, and I'm looking forward to using the new version!). However I had a lot of headaches getting the installation to work. I downloaded the OfflineBundle but running the very simple install script f***ed up my package dependencies. I managed to resolve this by NOT installing the libqtwebkit4 in the bundle. I already had what I assume is the same version of this library, but installing the one in the bundle with dpkg somehow ran me into the following Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/1175902. Ultimately I escaped from the resulting dependency hellhole by using dpkg -i --force-overwrite to get back to the version of the deb in my apt cache.
I don't think this is an Armory bug per se, and I assume others have managed to install the 0.89.99.16 fine using the bundle on the website, but I thought I'd post this as a heads up in case anyone else runs into the same issue.
Just a minor bug report. I'm running Ubuntu 13.04 64 bit. I managed to install 0.89.99.16 today (it's building the database now, and I'm looking forward to using the new version!). However I had a lot of headaches getting the installation to work. I downloaded the OfflineBundle but running the very simple install script f***ed up my package dependencies. I managed to resolve this by NOT installing the libqtwebkit4 in the bundle. I already had what I assume is the same version of this library, but installing the one in the bundle with dpkg somehow ran me into the following Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/1175902. Ultimately I escaped from the resulting dependency hellhole by using dpkg -i --force-overwrite to get back to the version of the deb in my apt cache.
I don't think this is an Armory bug per se, and I assume others have managed to install the 0.89.99.16 fine using the bundle on the website, but I thought I'd post this as a heads up in case anyone else runs into the same issue.
Re: Bitcoin Wallet Recovery Services - for forgotten wallet password
Goddamn it. Probably a wonky "n" key on my keyboard. (I have a System76 laptop which is based on a Clevo case. The build quality is good overall, but the chiclet style keyboard is total bullshit compared to my old ThinkPad.)
Re: Bitcoin Wallet Recovery Services - for forgotten wallet password
Hi everyone,
I haven't read this whole thread, but I'd like to vouch for Dave's services and his personal integrity.
I lost a wallet back in May (see this thread: https://bitcointalk.org/index.php?topic=85495.msg2104596#msg2104596) and when I was unable to crack the passphrase myself I sent the wallet and some guesses about the passphrase to Dave (and some others). Last night he sent me 80% of the coins originally in the wallet, after (apparently) having been working intermittently on this recovery for 5 months or more.
Slightly more detail on this this reddit thread: http://www.reddit.com/r/Bitcoin/comments/1q8zan/dave_bitcoin_of_walletrecoveryservicescom_just/
-- Sam
I haven't read this whole thread, but I'd like to vouch for Dave's services and his personal integrity.
I lost a wallet back in May (see this thread: https://bitcointalk.org/index.php?topic=85495.msg2104596#msg2104596) and when I was unable to crack the passphrase myself I sent the wallet and some guesses about the passphrase to Dave (and some others). Last night he sent me 80% of the coins originally in the wallet, after (apparently) having been working intermittently on this recovery for 5 months or more.
Slightly more detail on this this reddit thread: http://www.reddit.com/r/Bitcoin/comments/1q8zan/dave_bitcoin_of_walletrecoveryservicescom_just/
-- Sam
... how would he reveal his identity after he died (and was thus beyond the reach of agents seeking retribution)?
Not being an expert in the bitcoin protocol, I'm curious if any of the data in the genesis block (https://en.bitcoin.it/wiki/Genesis_block) could contain
a hash that would point towards Satoshi's identity.
Not being an expert in the bitcoin protocol, I'm curious if any of the data in the genesis block (https://en.bitcoin.it/wiki/Genesis_block) could contain
a hash that would point towards Satoshi's identity.
Well I just wrote these coins off, for now. My new wallet encrypts and decrypts fine, so it must really have been a typo, I guess. 
If anyone wants to have a go at cracking the wallet, PM me. I'll send you the .dat file and what I thought the password was, and if you can
crack it using a script like the one in this thread, you can keep a fraction of the contents of the wallet that seems fair.
If anyone wants to have a go at cracking the wallet, PM me. I'll send you the .dat file and what I thought the password was, and if you can
crack it using a script like the one in this thread, you can keep a fraction of the contents of the wallet that seems fair.
I feel a moron for this, but I locked myself out of my wallet (w/ about 2.5 BTC in it) today,
right after setting a passphrase. (I use bitcoin-qt.)
I tried all the obvious typing variants of the phrase, and then ran the Ruby script in this thread for an hour or so (basically through depth 2 of all 1-character substitutions into the passphrase I thought I was using).
Anyone have suggestions for next steps? I haven't "forgotten" anything about my passphrase; I even wrote it down "exactly" to store elsewhere for safekeeping. I don't have an unencrypted backup because I am a moron.
I run Ubuntu, but I am still nervous that my system might have been compromised somehow, although that's pretty unlikely. I didn't do anything in particular to secure the system (I don't encrypt my filesystem). I ran a couple of utilities to check for rootkits, but they didn't find anything suspicious.
So... somehow I must have mistyped the passphrase twice in a non-obvious way, which seems extraordinarily unlikely. I tried:
* Case inversion (caps lock)
* Adding punctuation and a space at the end
* All obvious variants for punctuation and capitalization in the passphrase
The script (I think) tried:
* All adjacent character swaps
* All 1-letter character changes
* Most 2-letter character changes
The form of the passphrase is (with capitalization and punctuation)
"Proper Name, Same Name; random word another Word"
Can anyone think of other good typing modifications to try?
If not, can anyone think what could be going on other than a strange repeated typo, or a malicious actor having installed (somehow!) a keylogger on my system and then changing the passphrase? Also I didn't have bitcoind installed at all until today, when I added it to run the Ruby script for brute-forcing the passphrase. Would it even be possible for someone else without physical access to my machine (which I'm fairly certain was safe) to have changed my passphrase with only bitcoin-qt installed on my system?
I've been using a version of bitcoin-qt installed via the Ubuntu package manner roughly 2 months ago (I think), and I have had some issues; once the block data got corrupted and I had to redownload the whole blockchain and start a new wallet, although this was before I owned any bitcoins, so I just moved on. Could a buggy bitcoin installation have somehow caused my problem? Is it worth installing a new software wallet program and trying to import wallet.dat using that?
right after setting a passphrase. (I use bitcoin-qt.)
I tried all the obvious typing variants of the phrase, and then ran the Ruby script in this thread for an hour or so (basically through depth 2 of all 1-character substitutions into the passphrase I thought I was using).
Anyone have suggestions for next steps? I haven't "forgotten" anything about my passphrase; I even wrote it down "exactly" to store elsewhere for safekeeping. I don't have an unencrypted backup because I am a moron.
I run Ubuntu, but I am still nervous that my system might have been compromised somehow, although that's pretty unlikely. I didn't do anything in particular to secure the system (I don't encrypt my filesystem). I ran a couple of utilities to check for rootkits, but they didn't find anything suspicious.
So... somehow I must have mistyped the passphrase twice in a non-obvious way, which seems extraordinarily unlikely. I tried:
* Case inversion (caps lock)
* Adding punctuation and a space at the end
* All obvious variants for punctuation and capitalization in the passphrase
The script (I think) tried:
* All adjacent character swaps
* All 1-letter character changes
* Most 2-letter character changes
The form of the passphrase is (with capitalization and punctuation)
"Proper Name, Same Name; random word another Word"
Can anyone think of other good typing modifications to try?
If not, can anyone think what could be going on other than a strange repeated typo, or a malicious actor having installed (somehow!) a keylogger on my system and then changing the passphrase? Also I didn't have bitcoind installed at all until today, when I added it to run the Ruby script for brute-forcing the passphrase. Would it even be possible for someone else without physical access to my machine (which I'm fairly certain was safe) to have changed my passphrase with only bitcoin-qt installed on my system?
I've been using a version of bitcoin-qt installed via the Ubuntu package manner roughly 2 months ago (I think), and I have had some issues; once the block data got corrupted and I had to redownload the whole blockchain and start a new wallet, although this was before I owned any bitcoins, so I just moved on. Could a buggy bitcoin installation have somehow caused my problem? Is it worth installing a new software wallet program and trying to import wallet.dat using that?
Re: I'm buying buying Ripple XRP: 1 BTC per 10,000 XRP (plus free XRP starter kit)
Would like to experiment with the ripple wallet; please send me a small amount of XRP if you can spare it:
rLfUdXU79ior1TxuhKmozd3QJaunyGnNva
Tanks!
rLfUdXU79ior1TxuhKmozd3QJaunyGnNva
Tanks!
After the MtGox kerfuffle last week, it seems that some entrepreneurial folks have started a new project: https://github.com/buttercoin. The idea is for an open-source exchange framework that can handle heavy load with less lag and fuss than existing exchanges. Seems like a great idea! In particular, they seem to imagine a distributed order book, reducing parties like MtGox to the role of handling fiat transactions, although perhaps that is more of a long term goal. The tricky technological part is making a robust framework that can deal with an extremely large number of transactions per second (orders of magnitude more than existing BTC exchanges can perform). For more details you can see their hackpad: https://buttercoin.hackpad.com/. Apologies if I have mistakenly misrepresented their idea.
My question for the forum: how can I contribute? I'm an amateur coder, but with no particular experience with the technologies they are using for prototyping (CoffeeScript, node.js). The hackpad is a bit of a jumble right now, with just a bunch of design ideas, yet they still urge people to go ahead, clone the repo, and start coding. What's a good place to start?
My question for the forum: how can I contribute? I'm an amateur coder, but with no particular experience with the technologies they are using for prototyping (CoffeeScript, node.js). The hackpad is a bit of a jumble right now, with just a bunch of design ideas, yet they still urge people to go ahead, clone the repo, and start coding. What's a good place to start?
Update for those who, like me, were not in the ACH verification queue when this stuff went down:
I thought that it was impossible to enter the queue because the website refused to let me upload photos, even though the ones I was trying to upload were less than 2MB (the filesize limit specified on the site). But this morning, after seeing a tweet from @bitfloor, I tried again with a file size closer to 500K and it worked fine. Hopefully in a week or two I will be verified and will then attempt an ACH withdrawal. I have revised my estimate of the probability that I will get my USD back slightly upwards.
I thought that it was impossible to enter the queue because the website refused to let me upload photos, even though the ones I was trying to upload were less than 2MB (the filesize limit specified on the site). But this morning, after seeing a tweet from @bitfloor, I tried again with a file size closer to 500K and it worked fine. Hopefully in a week or two I will be verified and will then attempt an ACH withdrawal. I have revised my estimate of the probability that I will get my USD back slightly upwards.
I sure find it interesting that SOME people got emails saying they were closing, and most didn't.
I can guarantee I would have been buying BTC for $200 a pop to get the cash out of there. Some is better than none.
I can guarantee I would have been buying BTC for $200 a pop to get the cash out of there. Some is better than none.
Agreed. One can speculate that Bitfloor's intentions *might* have been pure: maybe they thought to send the emails over a period of hours to the entire userbase to avoid
an instant sell-off that would overwhelm their infrastructure. (Sure it sucks for people on the tail end of the announcement, but if they randomized
who the emails were sent to, I suppose I could seem them thinking this was a good idea.) But then things could have spun out of control too quickly, necessitating an immediate
trading halt. Regardless of their intentions, though, the idea is horrible.
In retrospect, there are a number of red flags about Bitfloor, beyond the theft last autumn (of which I was aware), like the lack of a ToS and the fact that they
are located in the USA. I chose to trade with them because of the CapOne360 deposits (very convenient and free!), but I'm glad I only risked a small amount of money.
I hope I get it back!
Pretty upset about the bitfloor situation. I have some (not a huge amount) USD stuck on there, and I am not ACH verified (and can't upload a photo to enter the verification queue). If -- as seems to be speculated on reddit -- this is related to Uncle Sam shutting down their bank due to money laundering concerns, then I have a very low confidence that I will ever get this money.
Please post here if you get any useful info through channels other than twitter and the bitfloor website (which I can check myself).
Please post here if you get any useful info through channels other than twitter and the bitfloor website (which I can check myself).