Armory 0.95 testing phase

[achow101]

Do you use compressed or uncompressed key for segwit?

Armory uses uncompressed keys. Segwit wallet support has not been implemented yet.

[droark]

Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here. ArmoryDB still segfaults when Armory runs but at least Armory will compile and start.

[goatpig]

Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here. ArmoryDB still segfaults when Armory runs but at least Armory will compile and start.

It's failing to create sockets on localhost. If you could look into it that would be a great help

[achow101]

Not sure if this was already reported.

I don't see any of my addresses having a balance when I look at the wallet properties. But I can still send (at least fairly sure that I can) Bitcoin. But coin control doesn't work.

[goatpig]

Not sure if this was already reported.

I don't see any of my addresses having a balance when I look at the wallet properties. But I can still send (at least fairly sure that I can) Bitcoin. But coin control doesn't work.

Haven't ported these features yet. Coming soon.

[jl2012]

Do you use compressed or uncompressed key for segwit?

Armory uses uncompressed keys. Segwit wallet support has not been implemented yet.

To prevent spamming we may want to make uncompressed keys in segwit non-standard or even invalid. It'd be better for you to use compressed key as it's cheaper anyway

[achow101]

Do you use compressed or uncompressed key for segwit?

Armory uses uncompressed keys. Segwit wallet support has not been implemented yet.

To prevent spamming we may want to make uncompressed keys in segwit non-standard or even invalid. It'd be better for you to use compressed key as it's cheaper anyway

AFAIK compressed keys will be used in the new wallet format that goatpig will be making. The version with segwit wallet capabilities will have that new wallet.

[goatpig]

It'd be better for you to use compressed key as it's cheaper anyway

That goes without saying in new wallets. The current wallet format only uses uncompressed keys however.

It's an age old, stable format that has proved itself, so I will develop the new format from scratch and leave the current one untouched. The difficulty will be around how to operate legacy wallets imported into the new format with regard to address chains and old backups.

[Carlton Banks]

Getting the following with 69577e5:

Code:

(ERROR) BDM.py:184 - DB error: DB version mismatch. Use another dbdir!

...with the accompanying dialog box ("Press OK to quit Armory" etc).


Doesn't matter which directory Armory is pointed at, or if there's an absence of ./databases directory.

[goatpig]

Getting the following with 69577e5:

Code:

(ERROR) BDM.py:184 - DB error: DB version mismatch. Use another dbdir!

...with the accompanying dialog box ("Press OK to quit Armory" etc).


Doesn't matter which directory Armory is pointed at, or if there's an absence of ./databases directory.

Changed some formatting and bumped the internal version, use a fresh DB.

[droark]

Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here. ArmoryDB still segfaults when Armory runs but at least Armory will compile and start.

It's failing to create sockets on localhost. If you could look into it that would be a great help

Okay. Just looked at the code. Haven't activated debug mode yet but I'd imagine the crash is in the FCGI code, which appears to be pretty ancient. It's not maintained and hasn't been updated in years. I'm not even sure it ever supported OS X. (It was developed before OS X existed and, AFAIK, there was no attempt to port the code.)

I'm not entirely offhand sure how to proceed. I don't have a lot of free time to look into this, and if the problem is with the FCGI codebase, who knows how long it'd take to resolve everything. If somebody wants to help, I'd appreciate it.

EDIT: Derp. Was going off what goatpig said and assumed it was a socket thing. I don't think it is now. Have a core dump and am trying to decipher everything. It won't tell me which thread crashed, unfortunately.

EDIT 2: Okay. Dropped the blockfile reading code down to a single thread. Looks like the code doesn't like my copy of testnet's blk00050.dat. Here's the trace for what I believe is the offender. (Unfortunately, LLDB doesn't seem to like to explicitly state which thread crashed. Grrr.)

Code:

  thread #4: tid = 0x0003, 0x000000010039d93f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator<unsigned char>::construct<unsigned char, unsigned char const&>(this=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 16 at memory:1731, stop reason = signal SIGSTOP
    frame #0: 0x000000010039d93f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator<unsigned char>::construct<unsigned char, unsigned char const&>(this=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 16 at memory:1731
    frame #1: 0x000000010039d92f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator_traits<std::__1::allocator<unsigned char> >::__construct<unsigned char, unsigned char const&>(__a=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 32 at memory:1647
    frame #2: 0x000000010039d90f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator_traits<std::__1::allocator<unsigned char> >::construct<unsigned char, unsigned char const&>(__a=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 32 at memory:1493
    frame #3: 0x000000010039d8ef ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(this=0x00007000001824e0, __first="", __last="") + 159 at __split_buffer:263
    frame #4: 0x000000010039af4f ArmoryDB`std::__1::enable_if<(__is_forward_iterator<unsigned char const*>::value) && (is_constructible<unsigned char, std::__1::iterator_traits<unsigned char const*>::reference>::value), std::__1::__wrap_iter<unsigned char*> >::type std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::insert<unsigned char const*>(this=0x0000700000182918 size=4, __position=(item = '\0'), __first="", __last="") + 1519 at vector:1981
    frame #5: 0x0000000100399d7b ArmoryDB`BinaryData::append(this=0x0000700000182918, bd2=0x00007000001828e8) + 411 at BinaryData.cpp:45
    frame #6: 0x000000010061b334 ArmoryDB`BCTX::getHash(this=0x00007f9eab43c288) const + 276 at BlockDataMap.h:79
    frame #7: 0x0000000100651129 ArmoryDB`BCTX::moveHash(this=0x00007f9eab43c288) + 25 at BlockDataMap.h:96
    frame #8: 0x0000000100648466 ArmoryDB`BlockData::deserialize(this=0x00007000001838c0, data="\x04", size=3868256, blockHeader=0x0000000000000000, getID=function<unsigned int ()> @ 0x0000700000183aa0, checkMerkle=true)>, bool) + 6390 at BlockDataMap.cpp:98
    frame #9: 0x00000001005d5faf ArmoryDB`DatabaseBuilder::addBlocksToDB(this=0x00007f9ea9617918, data="\x04", size=3868256, offset=129075608)::$_3::operator()(unsigned char const*, unsigned long, unsigned long) const + 223 at DatabaseBuilder.cpp:322
    frame #10: 0x00000001005d5eb9 ArmoryDB`bool std::__1::__invoke_void_return_wrapper<bool>::__call<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) [inlined] decltype(__f=0x00007f9ea9617918, __args=0x0000700000183c08, __args=0x0000700000183c00, __args=0x0000700000183bf8)::$_3&>(fp)(std::__1::forward<unsigned char const*, unsigned long, unsigned long>(fp0))) std::__1::__invoke<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) + 153 at __functional_base:416
    frame #11: 0x00000001005d5e7b ArmoryDB`bool std::__1::__invoke_void_return_wrapper<bool>::__call<DatabaseBuilder::addBlocksToDB(__args=0x00007f9ea9617918, __args=0x0000700000183c08, __args=0x0000700000183c00, __args=0x0000700000183bf8)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) + 91 at __functional_base:437
    frame #12: 0x00000001005d5d59 ArmoryDB`std::__1::__function::__func<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3, std::__1::allocator<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3>, bool (unsigned char const*, unsigned long, unsigned long)>::operator(this=0x00007f9ea9617910, __arg=0x0000700000183c08, __arg=0x0000700000183c00, __arg=0x0000700000183bf8)(unsigned char const*&&, unsigned long&&, unsigned long&&) + 89 at functional:1437
    frame #13: 0x00000001005db97f ArmoryDB`std::__1::function<bool (unsigned char const*, unsigned long, unsigned long)>::operator(this=0x00007000001849a0, __arg="\x04", __arg=3868256, __arg=129075608)(unsigned char const*, unsigned long, unsigned long) const + 175 at functional:1817
    frame #14: 0x00000001005d0296 ArmoryDB`DatabaseBuilder::parseBlockFile(this=0x00007f9eab405e80, fileMap="\x04", fileSize=132943864, startOffset=0, callback=function<bool (const unsigned char *, unsigned long, unsigned long)> @ 0x00007000001849a0)>) + 2998 at DatabaseBuilder.cpp:443
    frame #15: 0x00000001005ce94e ArmoryDB`DatabaseBuilder::addBlocksToDB(this=0x00007f9eab405e80, bdl=0x0000700000185420, fileID=50, startOffset=0, bo=std::__1::shared_ptr<BlockOffset>::element_type @ 0x00007f9eab4058c8 strong=3 weak=1) + 638 at DatabaseBuilder.cpp:343
    frame #16: 0x00000001005ce47b ArmoryDB`DatabaseBuilder::updateBlocksInDB(this=0x0000700000184e48, fileID=50, startOffset=0, bo=std::__1::shared_ptr<BlockOffset>::element_type @ 0x00007f9eab4058c8 strong=3 weak=1, verbose=true)> const&, bool, bool)::$_2::operator()(unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>, bool) const + 283 at DatabaseBuilder.cpp:227
    frame #17: 0x00000001005cc758 ArmoryDB`DatabaseBuilder::updateBlocksInDB(this=0x00007f9eab405e80, progress=0x00007f9eab405eb0, verbose=true, initialLoad=true)> const&, bool, bool) + 3384 at DatabaseBuilder.cpp:268
    frame #18: 0x00000001005c8ffa ArmoryDB`DatabaseBuilder::init(this=0x00007f9eab405e80) + 1370 at DatabaseBuilder.cpp:50
    frame #19: 0x00000001003fe976 ArmoryDB`BlockDataManager::loadDiskState(this=0x00007f9eab404310, progress=0x0000700000186c60, forceRescan=false)> const&, bool) + 1126 at BlockUtils.cpp:1553
    frame #20: 0x00000001003fe4e2 ArmoryDB`BlockDataManager::doInitialSyncOnLoad(this=0x00007f9eab404310, progress=0x0000700000186c60)> const&) + 274 at BlockUtils.cpp:1510
    frame #21: 0x00000001004c36b7 ArmoryDB`BlockDataManagerThread::run(this=0x00007fff5f87b788) + 951 at BDM_mainthread.cpp:161
    frame #22: 0x00000001004c325d ArmoryDB`BlockDataManagerThread::thrun(_self=0x00007fff5f87b788) + 29 at BDM_mainthread.cpp:261
    frame #23: 0x00000001004cef6d ArmoryDB`void* std::__1::__thread_proxy<std::__1::tuple<void* (*)(void*), BlockDataManagerThread*> >(void*) [inlined] decltype(__f=0x00007f9eab600330, __args=0x00007f9eab600338)(void*)>(fp)(std::__1::forward<BlockDataManagerThread*>(fp0))) std::__1::__invoke<void* (*)(void*), BlockDataManagerThread*>(void* (*&&)(void*), BlockDataManagerThread*&&) + 24 at __functional_base:416
    frame #24: 0x00000001004cef55 ArmoryDB`void* std::__1::__thread_proxy<std::__1::tuple<void* (*)(void*), BlockDataManagerThread*> >(void*) [inlined] void std::__1::__thread_execute<void* (*)(void*), BlockDataManagerThread*, 1ul>(__t=0x00007f9eab600330)(void*), BlockDataManagerThread*>&, std::__1::__tuple_indices<1ul>) + 40 at thread:337
    frame #25: 0x00000001004cef2d ArmoryDB`void* std::__1::__thread_proxy<std::__1::tuple<void* (*)(void*), BlockDataManagerThread*> >(__vp=0x00007f9eab600330) + 365 at thread:347
    frame #26: 0x00007fff98ad699d libsystem_pthread.dylib`_pthread_body + 131
    frame #27: 0x00007fff98ad691a libsystem_pthread.dylib`_pthread_start + 168
    frame #28: 0x00007fff98ad4351 libsystem_pthread.dylib`thread_start + 13

[goatpig]

Does it always fail at the exact same spot?

[droark]

Does it always fail at the exact same spot?

Yes. I've run it three times. It appears to fail in the exact same spot.

Code:

-INFO  - 1471593104: (DatabaseBuilder.cpp:232) parsed block file #49
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3870106bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3433982bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3342432bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3868824bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 927851bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 645525bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 1047951bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3619855bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3862069bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3863112bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876516bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876290bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876291bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 2067742bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 113849bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 1282bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 275530bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 308762bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 171058bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 2562966bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 128376bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3291330bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3295429bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3333425bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3768617bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876436bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3857598bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3628980bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868328bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3869601bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868498bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868406bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876397bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
Segmentation fault: 11 (core dumped)

Trace looks the same as the trace I posted previously. Same parameters going into deserialize() and the other function calls.

As a side note, once it hits blk00047.dat, the "Found next block after skipped Xbytes" message comes up a lot. It only comes up once before hitting that file. Don't know if that matters but I thought I'd bring it up.

[goatpig]

As a side note, once it hits blk00047.dat, the "Found next block after skipped Xbytes" message comes up a lot. It only comes up once before hitting that file. Don't know if that matters but I thought I'd bring it up.

It's throwing while it tries to deser the block here:

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/DatabaseBuilder.cpp#L314

This is mostly the same code as 0.94. Do you get the same error with the same blockchain data with 0.94?

[achow101]

Hmm. Latest build of dev. I don't see any of my transactions now and no balance. The dashboard tab says I am online but the right hand corner says offline.

[goatpig]

Hmm. Latest build of dev. I don't see any of my transactions now and no balance. The dashboard tab says I am online but the right hand corner says offline.

I'm aware of this. Dev is going to be in limbo for the weekend while I work on some lower level stability issues.

[Carlton Banks]

I'm experiencing issues with latest Dev also, Db reaches tx scanning and gets stuck. No crash, just wheel-spinning. 2/2 scans produced the same result (at different block heights)

[droark]

This is mostly the same code as 0.94. Do you get the same error with the same blockchain data with 0.94?

No, although it does seem like things slow down quite a bit when reading from the later files. (Fresh DB but everything's multithreaded.) There's definitely something present that Armory doesn't like, although 0.94.1 doesn't crash. With Armory, it takes me ~22 min. to get the testnet DB built from scratch. It slows down when getting near the end (AFAIK) of the files, then takes a little while for the blockchain to organize.

Also, it takes 2-3 min. for Armory 0.94.1 to shut down in testnet mode, with 100% CPU utilization the entire time. Don't know if it's related but it seems plausible. Nothing shows up on the command line while all this is happening.

[alomar]

is Armory compatible with Bitcore from Bitpay?

[Carlton Banks]

is Armory compatible with Bitcore from Bitpay?

This should be a thread in it's own right, first off.

I'm not sure that Bitcore/Armory has ever been tried. Bitcore is in many ways just a re-implementation of Bitcoin Core as far as I'm aware, but there aren't particularly compelling reasons to use it. Although I've not heard of any recent changes to the development direction that might somehow make it attractive for use with Armory? (and not your own personal convenience).