0.96 preliminary testing

[goatpig]

This time again.

Looking for people willing to build and try the dev branch. Changes can be seen here:

https://github.com/goatpig/BitcoinArmory/blob/dev/changelog.txt

This still needs some polish, but it's getting to the point where it's about done. SegWit is currently hardcoded disabled on mainnet, and enabled on testnet.

Due to the newly introduced script types, I strongly suggest people test this on testnet first before moving the mainnet.

Here is a list of what's missing/known as buggy, so that the testers can focus on what is supposed to be fully functional:

- The initialization progress bars are wacky atm.
- Still have to add a slider to the auto fee byte feature
- no .conf for the client yet
- have to redo the path settings GUI to go with the .conf addition
- still missing BIP9 rules detection to enable/disable SW
- armoryd is fubar

I'll be away from Friday to Monday, so don't expect me to reply to bug reports until then.

Happy testing!

[1715670702]

1715670702

[1715670702]

1715670702

[1715670702]

1715670702

[droark]

Would it be possible to pull in my PRs on Github so as to get the Mac build going again and various other small things? Thanks.

[goatpig]

Would it be possible to pull in my PRs on Github so as to get the Mac build going again and various other small things? Thanks.

Did #143 #148 #161 and #168. Other PRs need longer reviews and testing so that will have to wait till I get back.

To all people who submitted PRs, please rebase on top of dev. Thanks.

[achow101]

I currently have an open PR for translations: https://github.com/goatpig/BitcoinArmory/pull/89. The plan is to have this in for 0.96 so if people could test it and review it, that would be great.

[droark]

Just submitted a PR to get the OSX build going again. There are two problems that still need to be addressed.

- cppForSwig/ScriptRecipient.h is inconsistent. getSize() needs to return size_t or uint64_t. As is, the parent class returns size_t and the children return uint64_t. This causes a build error on OSX.
- There's an ArmoryMac issue in the Python code. I'll sort it out in a separate PR.

In addition, Armory doesn't output CSV spreadsheets. Python errors prevent it from happening. I was working on a patch for it and got pulled into something else. I don't think this has worked for quite awhile. I tried 0.94.1 and it didn't work there either. For various reasons, I do think this is a useful feature, and I would like to see it working again. I'm happy to help get the ball rolling, of course.

Thanks.

[achow101]

In the MultiSigDialogs, the MultiSig addresses are being displayed (and maybe stored?) as P2PKH addresses, not P2SH addresses. This is happening with addresses that were already there, and presumably with addresses that are created.

[Carlton Banks]

I'm getting alot of these with 5a84857:

Code:

Traceback (most recent call last):
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8386, in wltTableClicked
    self.setAddrBookTxModel(self.selectedWltID)
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8283, in setAddrBookTxModel
    self.addrBookTxModel = SentToAddrBookModel(wltID, self.main)
  File "/home/user/BitcoinArmory/armorymodels.py", line 1337, in __init__
    addressBook = self.wlt.cppWallet.createAddressBook();
  File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1949, in createAddressBook
    def createAddressBook(self): return _CppBlockUtils.WalletContainer_createAddressBook(self)
RuntimeError: can't connect socket

....when using the Send dialog (triggered by either Coin Control button or Choose Address button). Subsequently, other parts of the GUI throw this error too (not necessarily with the same traceback).

[goatpig]

I currently have an open PR for translations: https://github.com/goatpig/BitcoinArmory/pull/89. The plan is to have this in for 0.96 so if people could test it and review it, that would be great.

Opened a code review of the PR in Github, please go over it.

Just submitted a PR to get the OSX build going again. There are two problems that still need to be addressed.

Merged #170, don't know the status on #151

-------------

Anything else I haven't mentioned is still being reviewed/fixed.

[goatpig]

I'm getting alot of these with 5a84857:

Code:

Traceback (most recent call last):
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8386, in wltTableClicked
    self.setAddrBookTxModel(self.selectedWltID)
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8283, in setAddrBookTxModel
    self.addrBookTxModel = SentToAddrBookModel(wltID, self.main)
  File "/home/user/BitcoinArmory/armorymodels.py", line 1337, in __init__
    addressBook = self.wlt.cppWallet.createAddressBook();
  File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1949, in createAddressBook
    def createAddressBook(self): return _CppBlockUtils.WalletContainer_createAddressBook(self)
RuntimeError: can't connect socket

....when using the Send dialog (triggered by either Coin Control button or Choose Address button). Subsequently, other parts of the GUI throw this error too (not necessarily with the same traceback).

Looks like the DB is not running.

[Carlton Banks]

That's it. Entering Send dialog reliably kills the db. Built with latest Whonix (Debian 8.7 based)

[goatpig]

Any error on the db side?

[Carlton Banks]

Not after it crashes

Code:

-ERROR - 1487006286: (nodeRPC.cpp:162) missing server option in node configuration file

That's the only error, I don't think that's the issue. Launch ArmoryQt.py with gdb? Or just for ArmoryDB?

[achow101]

Not after it crashes

Code:

-ERROR - 1487006286: (nodeRPC.cpp:162) missing server option in node configuration file

That's the only error, I don't think that's the issue. Launch ArmoryQt.py with gdb? Or just for ArmoryDB?

That's the issue I think. Your node can't connect to the RPC server of Bitcoin Core because it isn't set to have the RPC server enabled (at least that's what it thinks). However the send needs RPC functions for the fee/byte stuff.

[Carlton Banks]

Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf

[achow101]

Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf

The bitcoin.conf requirements have changed. It now requires that you have server=1 set (although that should have already been set to enable the RPC server anyways) and it will check for it. It does not require rpcuser or rpcpassword to be set. In fact, I recommend that you don't set those.

Double check that that option is set in the bitcoin.conf and see if it still fails with it set. I will attempt to test this out on my end as well.

[Carlton Banks]

Shouldn't just running with -server=1 from bash work? It's not.

I've screwed up my Bitcoin installation anyway, getting strangely random amount of inability to retain the last ~50 blocks, accompanied by SegFault errors, and long startups. Don't tell me, delete the most recent blk.dat files to force a reindex?

[achow101]

Shouldn't just running with -server=1 from bash work? It's not.

No, it specifically looks for server=1 in the bitcoin.conf. I mentioned it to goatpig yesterday on IRC but he said for now it will just look for that line the conf file, later it will probably be changed to just listening for a response from the RPC connection, which it does anyways.

I've screwed up my Bitcoin installation anyway, getting strangely random amount of inability to retain the last ~50 blocks, accompanied by SegFault errors, and long startups. Don't tell me, delete the most recent blk.dat files to force a reindex?

No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex.

[Carlton Banks]

Makes more sense. Core issue is now more pressing, however.

No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex.

I'm not seeing anything relevant in debug.log. Put simply, Core isn't retaining the most recent ~50 blocks between restarts. The amount of missing blocks varies each restart. Provoked by Core not shutting down cleanly when it was tx scanning the wallet (I'd forgotten to add the -disablewallet argument, was being impatient and so interrrupted the Rescan)

I'm not sure whether reindexing will necessarily fix this, and reindexing is a lot of time to commit to.

[achow101]

Makes more sense. Core issue is now more pressing, however.

No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex.

I'm not seeing anything relevant in debug.log. Put simply, Core isn't retaining the most recent ~50 blocks between restarts. The amount of missing blocks varies each restart. Provoked by Core not shutting down cleanly when it was tx scanning the wallet (I'd forgotten to add the -disablewallet argument, was being impatient and so interrrupted the Rescan)

Let's move this part of the discussion to Tech Support.


Back to topic.

I am currently testing send and receiving to and from all three address types on testnet. For some reason, when I receive, it suddenly switches back to "Dashboard Scanning Mode" and it doesn't leave that mode even though DB says scanning has completed. Also, this switch only happened when a new block arrived, but it was not the first block that had arrived with Armory started. Restarting the client fixed the problem.

It also seems that I am getting the "missing server option from the conf file" error even though that option is set. Actually it wasn't set, but I think that is because Armory is looking for a bitcoin.conf in <datadir>/testnet3 instead of in <datadir> as I'm pretty sure Core still uses the one in <datadir>

This is the error and backtrace I get from just attempting to start ArmoryDB now:

Code:

Thread 4 "ArmoryDB" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffda81c700 (LWP 7888)]
__GI__IO_fwrite (buf=0x7fffd00018f0, size=281, count=1, fp=0x0) at iofwrite.c:37
37	iofwrite.c: No such file or directory.
(gdb) backtrace
#0  __GI__IO_fwrite (buf=0x7fffd00018f0, size=281, count=1, fp=0x0) at iofwrite.c:37
#1  0x000000000067de93 in HttpSocket::makePacket (this=0xb20bb0, packet=0x7fffda81b2d0, 
    msg=0x7fffd0002e60 "{\"id\": 0, \"jsonrpc\": \"2.0\", \"method\": \"getinfo\", \"params\": []}")
    at StringSockets.cpp:83
#2  0x000000000067e5d2 in HttpSocket::writeAndRead (this=0xb20bb0, 
    msg="{\"id\": 0, \"jsonrpc\": \"2.0\", \"method\": \"getinfo\", \"params\": []}", sockfd=2147483647)
    at StringSockets.cpp:123
#3  0x000000000066d952 in NodeRPC::testConnection (this=0xb20a60) at nodeRPC.cpp:70
#4  0x000000000066d6fc in NodeRPC::setupConnection (this=0xb20a60) at nodeRPC.cpp:51
#5  0x000000000066d81c in NodeRPC::testConnection (this=0xb20a60) at nodeRPC.cpp:60
#6  0x0000000000467302 in BlockDataManager::getNodeStatus (this=0xb0d410) at BlockUtils.cpp:1242
#7  0x00000000004d9dc9 in BlockDataManagerThread::<lambda()>::operator()(void) const (__closure=0x7fffda81bd30)
    at BDM_mainthread.cpp:141
#8  0x00000000004db708 in std::_Function_handler<void(), BlockDataManagerThread::run()::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...) at /usr/include/c++/5/functional:1871
#9  0x000000000043a5e4 in std::function<void ()>::operator()() const (this=0x7fffda81bd30)
    at /usr/include/c++/5/functional:2267
#10 0x00000000006701d2 in NodeRPC::waitOnChainSync(std::function<void ()>) (this=0xb20a60, callbck=...)
    at nodeRPC.cpp:277
#11 0x00000000004da6ce in BlockDataManagerThread::run (this=0x7fffffffd970) at BDM_mainthread.cpp:154
#12 0x00000000004db214 in BlockDataManagerThread::thrun (_self=0x7fffffffd970) at BDM_mainthread.cpp:302
#13 0x00000000004e05ba in std::_Bind_simple<void* (*(BlockDataManagerThread*))(void*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xb218b8) at /usr/include/c++/5/functional:1531
#14 0x00000000004e04c4 in std::_Bind_simple<void* (*(BlockDataManagerThread*))(void*)>::operator()() (
    this=0xb218b8) at /usr/include/c++/5/functional:1520
#15 0x00000000004e0454 in std::thread::_Impl<std::_Bind_simple<void* (*(BlockDataManagerThread*))(void*)> >::_M_run() (this=0xb218a0) at /usr/include/c++/5/thread:115
#16 0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#17 0x00007ffff7bc16ba in start_thread (arg=0x7fffda81c700) at pthread_create.c:333
#18 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I am getting the same error that Carlton is getting when hitting the send button.

Here is the backtrace from gdb:

Code:

(gdb) backtrace
#0  __GI__IO_fwrite (buf=0x7fff70017d80, size=163, count=1, fp=0x0) at iofwrite.c:37
#1  0x000000000056a57c in HttpSocket::makePacket(char**, char const*) ()
#2  0x000000000056a9a9 in HttpSocket::writeAndRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int) ()
#3  0x0000000000562b56 in NodeRPC::getFeeByte(unsigned int) ()
#4  0x000000000051d997 in std::_Function_handler<Arguments (std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&), BDV_Server_Object::buildMethodMap()::{lambda(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&)#24}>::_M_invoke(std::_Any_data const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&) ()
#5  0x000000000051bd9f in BDV_Server_Object::executeCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&) ()
#6  0x000000000052a1a1 in Clients::runCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#7  0x000000000052a4c0 in FCGI_Server::processRequest(FCGX_Request*) ()
#8  0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x00007ffff7bc16ba in start_thread (arg=0x7fff7f7fe700) at pthread_create.c:333
#10 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

It seems that the issue is related to being unable to connect to the RPC server. I will investigate.


Edit: I have resolved the above issues, it was due to some extra debugging code left in the codebase. Here's a PR for it: https://github.com/goatpig/BitcoinArmory/pull/172. Still hunting down bugs in the send dialog, will continue in more posts instead of editing this one.

Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it.

[goatpig]

Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf

It looks for .bitcoin/testnet3/bitcoin.conf in testnet. At any rate, it should work if the RPC is off as well. That's a bug that needs fixing.

Actually it wasn't set, but I think that is because Armory is looking for a bitcoin.conf in <datadir>/testnet3 instead of in <datadir> as I'm pretty sure Core still uses the one in <datadir>

I did this on purpose. I am aware of the reason why it should use the .conf in the parent bitcoin folder, but it's weird enough that I'd rather not introduce weird edge cases in my own path discovery code.

I will move RPC detection to simply probing the socket soon enough.

Edit: I have resolved the above issues, it was due to some extra debugging code left in the codebase. Here's a PR for it: https://github.com/goatpig/BitcoinArmory/pull/172. Still hunting down bugs in the send dialog, will continue in more posts instead of editing this one.

Already have a fix for that locally. I'm going through the PRs first then pushing this fix.

Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it.

That has to do with the dashboard snafu, will fix it soon.