|
Title: 0.96 preliminary testing Post by: goatpig on February 10, 2017, 12:19:43 AM 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! Title: Re: 0.96 preliminary testing Post by: droark on February 10, 2017, 09:02:57 AM 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.
Title: Re: 0.96 preliminary testing Post by: goatpig on February 10, 2017, 09:45:33 AM 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. Title: Re: 0.96 preliminary testing Post by: achow101 on February 10, 2017, 02:29:37 PM 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.
Title: Re: 0.96 preliminary testing Post by: droark on February 12, 2017, 04:15:04 AM 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. Title: Re: 0.96 preliminary testing Post by: achow101 on February 12, 2017, 04:48:14 PM 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.
Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 13, 2017, 02:35:21 PM I'm getting alot of these with 5a84857:
Code: Traceback (most recent call last): ....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). Title: Re: 0.96 preliminary testing Post by: goatpig on February 13, 2017, 04:32:47 PM 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. Quote 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. Title: Re: 0.96 preliminary testing Post by: goatpig on February 13, 2017, 04:33:19 PM I'm getting alot of these with 5a84857: Code: Traceback (most recent call last): ....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. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 13, 2017, 05:24:36 PM That's it. Entering Send dialog reliably kills the db. Built with latest Whonix (Debian 8.7 based)
Title: Re: 0.96 preliminary testing Post by: goatpig on February 13, 2017, 05:35:36 PM Any error on the db side?
Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 13, 2017, 10:32:50 PM 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? Title: Re: 0.96 preliminary testing Post by: achow101 on February 13, 2017, 10:36:29 PM Not after it crashes 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.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? Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 13, 2017, 11:39:16 PM Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf
Title: Re: 0.96 preliminary testing Post by: achow101 on February 13, 2017, 11:51:45 PM 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. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 14, 2017, 12:22:24 AM 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? Title: Re: 0.96 preliminary testing Post by: achow101 on February 14, 2017, 12:38:16 AM 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.Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 14, 2017, 12:46:54 AM 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. Title: Re: 0.96 preliminary testing Post by: achow101 on February 14, 2017, 12:51:19 AM Makes more sense. Core issue is now more pressing, however. Let's move this part of the discussion to Tech Support.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) 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. This is the error and backtrace I get from just attempting to start ArmoryDB now: Code: Thread 4 "ArmoryDB" received signal SIGSEGV, Segmentation fault. I am getting the same error that Carlton is getting when hitting the send button. Here is the backtrace from gdb: Code: (gdb) backtrace 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. Title: Re: 0.96 preliminary testing Post by: goatpig on February 14, 2017, 10:16:56 AM 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. Quote 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. Quote 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. Quote 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. Title: Re: 0.96 preliminary testing Post by: achow101 on February 14, 2017, 06:17:07 PM Should DB being shutting down when Client closes even though I run DB separately?
Title: Re: 0.96 preliminary testing Post by: goatpig on February 14, 2017, 09:41:14 PM Should DB being shutting down when Client closes even though I run DB separately? DB now uses a cookie file setup to authorize special commands like shutdown. Any local client can read that cookie file, which the DB creates under any circumstances. I guess I could add some cli magic in there to make it a bit more intuitive. Title: Re: 0.96 preliminary testing Post by: droark on February 15, 2017, 03:03:48 AM Test suite is broken. Submitted a PR.
Title: Re: 0.96 preliminary testing Post by: goatpig on February 15, 2017, 09:25:07 PM Quote 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. Fixed. Quote Should DB being shutting down when Client closes even though I run DB separately? Won't do it anymore now. Quote Test suite is broken. Submitted a PR. Merged. Also merged the translation PR, have fun with that. Edit: If your PR adds a feature or fixes something I missed from previous versions, please update the changelog as accordingly as well. Title: Re: 0.96 preliminary testing Post by: goatpig on February 16, 2017, 01:42:12 PM Shouldn't just running with -server=1 from bash work? It's not. Should be fixed now. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 16, 2017, 10:47:34 PM I'll be checking it out right after I mend my blockchain data, it'll be done soon with any luck
Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 19, 2017, 01:08:08 PM Shouldn't just running with -server=1 from bash work? It's not. Should be fixed now. I can now confirm that. Issues I found (8adfd62)
Title: Re: 0.96 preliminary testing Post by: droark on February 19, 2017, 08:16:07 PM Another problem (and one that seems to have been around for years): The transaction export feature is broken. There are two problems.
- In qtdialogs.py, order_ascending and order_descending aren't defined. - There's something wrong with SWIG. I got the following error on the command line when running the export command after defining the two order values. Code: (ERROR) Traceback (most recent call last): This probably has to do with order_ascending and order_descending, which need to be HistoryOrdering objects. I can't seem to find examples in Git. Will keep looking and submit a PR if I can. EDIT: Okay, I think I found it. The Python code relies on code in BlockDataViewer.h/cpp. However, that code goes into ArmoryDB. SwigClient.h/cpp appears to have its own BlockDataViewer. This is what Python accesses. The Python BDV doesn't have the code required for the Tx exporting. I'll look into that and see if how easy it would be to copy the code over. Title: Re: 0.96 preliminary testing Post by: goatpig on February 19, 2017, 10:37:02 PM EDIT: Okay, I think I found it. The Python code relies on code in BlockDataViewer.h/cpp. However, that code goes into ArmoryDB. SwigClient.h/cpp appears to have its own BlockDataViewer. This is what Python accesses. The Python BDV doesn't have the code required for the Tx exporting. I'll look into that and see if how easy it would be to copy the code over. That most likely means this is data that needs to be pulled from the DB. You would have to populate the director with the method, write ser/deser routines and get the client to pull the data. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 23, 2017, 02:12:26 PM Both the Create Wallet button and dropdown selection yields this:
Code: Traceback (most recent call last): ...and no Create Wallet dialog Title: Re: 0.96 preliminary testing Post by: goatpig on February 23, 2017, 03:20:07 PM Both the Create Wallet button and dropdown selection yields this: Code: Traceback (most recent call last): ...and no Create Wallet dialog Will go over these once the autotools branch is ready. On that note, would you mind pulling that branch and trying it out? You need to setup git submodules this way once you check out the branch: Code: git submodule init Then you can build the usual autotools way: Code: sh autogen.sh make dist works, but make install doesn't yet. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 23, 2017, 03:34:29 PM Can do. Is autotools not a dependency for gitian, or is that wrong?
Title: Re: 0.96 preliminary testing Post by: goatpig on February 23, 2017, 03:46:54 PM Can do. Is autotools not a dependency for gitian, or is that wrong? It is, and that's end game here. But autotools itself is a messy thing, that got me spending the best part of a week just to get Armory back into the state it was with plain makefiles. So... baby steps =) Title: Re: 0.96 preliminary testing Post by: droark on February 25, 2017, 10:40:25 PM Submitted a PR for C++11 detection, which is broken on Macs. There's also some sort of ASM compile issue for Crypto++. Haven't been able to decipher that one yet. Here's an example.
Code: Making all in cryptopp Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 26, 2017, 12:23:45 AM Okay, so the autotools branch is compiling and running fine for me, using latest Whonix (debian 8.7 based)
Title: Re: 0.96 preliminary testing Post by: goatpig on February 26, 2017, 12:47:34 AM Submitted a PR for C++11 detection, which is broken on Macs. There's also some sort of ASM compile issue for Crypto++. Haven't been able to decipher that one yet. Here's an example. https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/cryptopp/Makefile.am#L9 It is failing to trigger this if block. It needs -DCRYPTOPP_DISABLE_ASM but that depends on this conditional: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/cryptopp/configure.ac#L53 i.e. if the configure scripts detects clang as the compiler. Feel free to change the condition to UNAME_DARWIN or expand on the conditions to add this def. Title: Re: 0.96 preliminary testing Post by: droark on February 26, 2017, 02:23:40 AM Submitted a PR for C++11 detection, which is broken on Macs. There's also some sort of ASM compile issue for Crypto++. Haven't been able to decipher that one yet. Here's an example. https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/cryptopp/Makefile.am#L9 It is failing to trigger this if block. It needs -DCRYPTOPP_DISABLE_ASM but that depends on this conditional: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/cryptopp/configure.ac#L53 i.e. if the configure scripts detects clang as the compiler. Feel free to change the condition to UNAME_DARWIN or expand on the conditions to add this def. Thanks. Submitted another PR. I'm still having a problem. This happens at the end of the build. Code: cp cppForSwig/.libs/libCppBlockUtils.so ./_CppBlockUtils.so Title: Re: 0.96 preliminary testing Post by: goatpig on February 26, 2017, 02:30:31 AM Quote Code: cp cppForSwig/.libs/libCppBlockUtils.so ./_CppBlockUtils.so What folder does libtool build on OSX? Try replacing /cppForSwig/.libs with $(builddir) Title: Re: 0.96 preliminary testing Post by: droark on February 26, 2017, 04:01:40 AM What folder does libtool build on OSX? Try replacing /cppForSwig/.libs with $(builddir) Nevermind. Found the problem and updated the PR. OS X puts out .dylib files instead of .so. Adjusted the Makefile to account for that. Title: Re: 0.96 preliminary testing Post by: droark on February 27, 2017, 01:58:38 AM Found two more problems.
- There seems to be some sort of repo cloning issue. Every time I've cloned onto my Ubuntu VM, the FCGI subproject never downloads. I got around it by manually downloading the code and copying it over. Still, something's up, and I'm not sure what it is. (OSX is fine.) - The C++ wallet mirroring seemed to pause when it hit an error. Code: (ERROR) ArmoryUtils.py:3217 - Error in pybkgdthread: 'WalletComparisonClass' object has no attribute 'tr' I'm also seeing some other errors on startup. The first one is repeated once, and the second is repeating multiple times. Code: (ERROR) Traceback (most recent call last): Title: Re: 0.96 preliminary testing Post by: achow101 on February 27, 2017, 02:07:14 AM - There seems to be some sort of repo cloning issue. Every time I've cloned onto my Ubuntu VM, the FCGI subproject never downloads. I got around it by manually downloading the code and copying it over. Still, something's up, and I'm not sure what it is. (OSX is fine.) When you clone, runCode: git submodule init Title: Re: 0.96 preliminary testing Post by: goatpig on February 27, 2017, 02:18:50 AM Found two more problems. - There seems to be some sort of repo cloning issue. Every time I've cloned onto my Ubuntu VM, the FCGI subproject never downloads. I got around it by manually downloading the code and copying it over. Still, something's up, and I'm not sure what it is. (OSX is fine.) - The C++ wallet mirroring seemed to pause when it hit an error. Code: (ERROR) ArmoryUtils.py:3217 - Error in pybkgdthread: 'WalletComparisonClass' object has no attribute 'tr' I'm also seeing some other errors on startup. The first one is repeated once, and the second is repeating multiple times. Code: (ERROR) Traceback (most recent call last): These errors are fixed in dev Title: Re: 0.96 preliminary testing Post by: goatpig on February 28, 2017, 10:27:01 PM
Fixed Quote
Can't reproduce the coin control thing, you're gonna have to narrow it down. I got some other bug on the fee part that may cover what you found, more on that when that fix is out. Both the Create Wallet button and dropdown selection yields this: Code: Traceback (most recent call last): ...and no Create Wallet dialog Fixed Another problem (and one that seems to have been around for years): The transaction export feature is broken. There are two problems. - In qtdialogs.py, order_ascending and order_descending aren't defined. - There's something wrong with SWIG. I got the following error on the command line when running the export command after defining the two order values. Code: (ERROR) Traceback (most recent call last): This probably has to do with order_ascending and order_descending, which need to be HistoryOrdering objects. I can't seem to find examples in Git. Will keep looking and submit a PR if I can. EDIT: Okay, I think I found it. The Python code relies on code in BlockDataViewer.h/cpp. However, that code goes into ArmoryDB. SwigClient.h/cpp appears to have its own BlockDataViewer. This is what Python accesses. The Python BDV doesn't have the code required for the Tx exporting. I'll look into that and see if how easy it would be to copy the code over. Fixed Title: Re: 0.96 preliminary testing Post by: Ente on February 28, 2017, 11:04:10 PM I just tried to install the dev branch.
After pulling, changing branch to dev and installing a few new dependencies, I did Quote sh autogen.sh ./configure make make gives me Quote make all-recursive make[1]: Entering directory '/opt/BitcoinArmory' Making all in cppForSwig make[2]: Entering directory '/opt/BitcoinArmory/cppForSwig' Making all in lmdb make[3]: Entering directory '/opt/BitcoinArmory/cppForSwig/lmdb' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/opt/BitcoinArmory/cppForSwig/lmdb' Making all in fcgi make[3]: Entering directory '/opt/BitcoinArmory/cppForSwig/fcgi' make[3]: *** No rule to make target 'all'. Stop. make[3]: Leaving directory '/opt/BitcoinArmory/cppForSwig/fcgi' Makefile:1453: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/opt/BitcoinArmory/cppForSwig' Makefile:417: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/opt/BitcoinArmory' Makefile:348: recipe for target 'all' failed make: *** [all] Error 2 I wouldn't be surprised if I messed something up with dependencies and all, but can't make much sense out of that error. Running on debian 8 by the way. Cheers, Ente Title: Re: 0.96 preliminary testing Post by: achow101 on February 28, 2017, 11:14:36 PM I just tried to install the dev branch. Did you runAfter pulling, changing branch to dev and installing a few new dependencies, I did Quote sh autogen.sh ./configure make make gives me Quote make all-recursive make[1]: Entering directory '/opt/BitcoinArmory' Making all in cppForSwig make[2]: Entering directory '/opt/BitcoinArmory/cppForSwig' Making all in lmdb make[3]: Entering directory '/opt/BitcoinArmory/cppForSwig/lmdb' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/opt/BitcoinArmory/cppForSwig/lmdb' Making all in fcgi make[3]: Entering directory '/opt/BitcoinArmory/cppForSwig/fcgi' make[3]: *** No rule to make target 'all'. Stop. make[3]: Leaving directory '/opt/BitcoinArmory/cppForSwig/fcgi' Makefile:1453: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/opt/BitcoinArmory/cppForSwig' Makefile:417: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/opt/BitcoinArmory' Makefile:348: recipe for target 'all' failed make: *** [all] Error 2 I wouldn't be surprised if I messed something up with dependencies and all, but can't make much sense out of that error. Running on debian 8 by the way. Cheers, Ente Code: git submodule init Title: Re: 0.96 preliminary testing Post by: Carlton Banks on February 28, 2017, 11:41:35 PM Can't test the new fixes, the main transaction window and balances are blank. Block height reads "Offline"
Code: BDM is ready! A new block arrives, and kicks the main tx window into life, tx details don't work. Still no balances. Block height is still "Offline" Code: New Block: 455196 The memory leak error is repeated hundreds of times, edited for brevity Edit: dbLog.txt has this as the last line, the rest is normal stuff I believe Code: -ERROR - 1488326155: (BitcoinP2P.cpp:926) caught SocketError exception in processDataStackThread: POLLNVAL in readFromSocketThread Title: Re: 0.96 preliminary testing Post by: achow101 on March 01, 2017, 12:22:42 AM --snip-- Are you using the latest dev? If so, I think it is currently unstable. Goatpig was working on some fixes to the socket (related to that dblog error you posted) and I don't think they are completely done yet (something about edge cases).Title: Re: 0.96 preliminary testing Post by: goatpig on March 01, 2017, 07:04:45 AM Should be good now. Make sure to make clean and autogen again, quite a lot of stuff has changed. Also make sure the submodule is up to date.
Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 01, 2017, 12:23:30 PM Should the git submodule update command not produce some delta feedback in respect of the changes ? I got a new prompt with nothing. Do I need to make clean first?
Edit: some idiot forgot to git checkout dev before loading the submodule. Move along... Title: Re: 0.96 preliminary testing Post by: Ente on March 01, 2017, 03:31:35 PM Did you run Code: git submodule init That did the trick, thank you. It all ran through smoothly, as far as I can see. I now get a GUI, but only a rotating wheel: Code: python /opt/BitcoinArmory/ArmoryQt.py --armorydb-ip=192.168.0.1 --armorydb-port=9001 Code: (ERROR) ArmoryUtils.py:1230 - Error getting system details: No idea why the DB would be already running, I only see that one process running. Anything I can do on my side? Cheers, Ente Title: Re: 0.96 preliminary testing Post by: goatpig on March 01, 2017, 07:05:05 PM Should the git submodule update command not produce some delta feedback in respect of the changes ? I got a new prompt with nothing. Do I need to make clean first? It should. I'm not an expert with submodules though, first time trying it. There are other ways to get the submodules to update with a command from the top most repo: http://stackoverflow.com/questions/1030169/easy-way-pull-latest-of-all-submodules Otherwise, the "brute force" method is to git pull in the submodule repo. Once I'll more familiar with it I'll update the readme with the most convenient method. Quote No idea why the DB would be already running, I only see that one process running. Anything I can do on my side? Quote No idea why the DB would be already running, I only see that one process running. That line just means the client successfully probed the ip:port you gave it for a listening socket and won't start a local DB. Quote Anything I can do on my side? Do you have some python or C++ in you? EDIT: also please detail your setup. If you dont have any coding in you, I'll make you a separate branch with extra verbose in there for you to paste back here. Title: Re: 0.96 preliminary testing Post by: droark on March 02, 2017, 02:25:01 AM - There seems to be some sort of repo cloning issue. Every time I've cloned onto my Ubuntu VM, the FCGI subproject never downloads. I got around it by manually downloading the code and copying it over. Still, something's up, and I'm not sure what it is. (OSX is fine.) When you clone, runCode: git submodule init Thanks. That did the trick. I wonder if there's a way to update this. Anyway.... These errors are fixed in dev Thanks. Seems like dev is getting a bit more stable. There are still some problems on Linux, though. (I've been sending some testnet coins throughout the day.) - Coin Control seems to be broken. I have to specify which UTXOs I want to use, otherwise Armory complains. I can get the exact message if you need it. - After ~7-8 blocks come in, Armory seems to stop picking up new blocks even though Core keeps chugging along. No messages on the command line. When I close, I have to force quit. The blocks seem to be picked up upon restart. - While it's just a wild hunch, I suspect the C++ and Python wallet code is out of sync. Is there any way to reset the C++ side, similar to Rebuild & Rescan? (I typically just nuke the DB directory and let Armory rebuild.) - I'm still seeing a couple of errors on the command line. Code: (ERROR) ArmoryUtils.py:3741 - Unsupported language specified. Defaulting to English (en) Code: (ERROR) ArmoryQt.py:2129 - ***WARNING: Wallet could not be loaded: /home/droark/.armory/testnet3/armory_22LowGmee_.WatchOnly.wallet (skipping) Title: Re: 0.96 preliminary testing Post by: goatpig on March 02, 2017, 06:59:45 AM - Coin Control seems to be broken. I have to specify which UTXOs I want to use, otherwise Armory complains. I can get the exact message if you need it. Please do Quote - After ~7-8 blocks come in, Armory seems to stop picking up new blocks even though Core keeps chugging along. No messages on the command line. When I close, I have to force quit. The blocks seem to be picked up upon restart. Try to narrow it down. I'll try to reproduce on my end. Feel free to add verbose if you got an idea of where it's happening. Quote Code: (ERROR) ArmoryUtils.py:3741 - Unsupported language specified. Defaulting to English (en) This is a false positive from the translation PR. I'm guessing it should set the default the first time, which it isn't doing. Quote Code: (ERROR) ArmoryQt.py:2129 - ***WARNING: Wallet could not be loaded: /home/droark/.armory/testnet3/armory_22LowGmee_.WatchOnly.wallet (skipping) That's quorum's MS wallets, don't cheat now =D Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 02, 2017, 04:37:29 PM
Fixed yep (both) Quote A little messing around with the "Use only selected UTXOs" option ended up with a bunch of AttributeError: 'DlgWalletDetails' object has no attribute 'wltAddrModel' with differing tracebacks, followed by the fee adjustment failing altogether. Clicking Send! in that state produced an Insufficient Fee dialog with this text featuring "Your specified fee results in a rate of %d satoshis per byte/b>. This is much lower than the median satoshi/byte rate of %s BTC" Can't reproduce the coin control thing, you're gonna have to narrow it down. I got some other bug on the fee part that may cover what you found, more on that when that fix is out. So, I can reliably reproduce the issue:
This error is produced.... Code: (ERROR) Traceback (most recent call last): .... plus this dialog appears when clicking Preview Tx: There was an error constructing your transaction, due to a quirk in the way Bitcoin transactions work. If you see this error more than once, try sending your BTC in two or more separate transactions. Both the Create Wallet button and dropdown selection yields this: Fixed There's more.... Create New is good now, but Delete Wallet produces this..... Code: Traceback (most recent call last): ...the wallet is deleted, but only after shutdown/restart Title: Re: 0.96 preliminary testing Post by: achow101 on March 02, 2017, 05:59:21 PM Transaction details won't open.
Traceback: Code: Traceback (most recent call last): Title: Re: 0.96 preliminary testing Post by: goatpig on March 02, 2017, 07:35:18 PM ...the wallet is deleted, but only after shutdown/restart I'm aware of this one, pissed me off at one point so I left it on the back burner. Will fix the rest, dunno about this one atm, high cost to reward ratio for something that can be done by just deleting the underlying file manually and restarting the client. Title: Re: 0.96 preliminary testing Post by: droark on March 02, 2017, 10:09:09 PM - Coin Control seems to be broken. I have to specify which UTXOs I want to use, otherwise Armory complains. I can get the exact message if you need it. Please do I can't seem to reproduce this right now. However, the fee window is broken. If I tell it I want a flat fee, the actual fee is different. For example, if I want a fee of 0.0001 BTC, Armory actually wants it to be 0.00011576 BTC (45.05 sat/B). I have to tell it 0.00008638 BTC (38.91 sat/B). I then have to tell Armory to use something like 0.00008362 BTC in order for the real fee to be 0.0001 BTC. This is the latest dev build. Quote Quote - After ~7-8 blocks come in, Armory seems to stop picking up new blocks even though Core keeps chugging along. No messages on the command line. When I close, I have to force quit. The blocks seem to be picked up upon restart. Try to narrow it down. I'll try to reproduce on my end. Feel free to add verbose if you got an idea of where it's happening. I left it overnight and saw a network error on the command line. Unfortunately, I didn't save it. :( This was long after Armory stopped accepting blocks. Nothing's in the Python logs, and the C++ logs are garbled junk for some reason. I'll keep an eye out. Quote Quote Code: (ERROR) ArmoryUtils.py:3741 - Unsupported language specified. Defaulting to English (en) This is a false positive from the translation PR. I'm guessing it should set the default the first time, which it isn't doing. Yeah. Something doesn't seem to be set, or at least sticking. Quote Quote Code: (ERROR) ArmoryQt.py:2129 - ***WARNING: Wallet could not be loaded: /home/droark/.armory/testnet3/armory_22LowGmee_.WatchOnly.wallet (skipping) That's quorum's MS wallets, don't cheat now =D Oops. :) Title: Re: 0.96 preliminary testing Post by: goatpig on March 03, 2017, 01:36:16 AM Transaction details won't open. Traceback: Code: Traceback (most recent call last): Works for me. Is there only a few select transactions it cannot display? Title: Re: 0.96 preliminary testing Post by: achow101 on March 03, 2017, 03:26:05 AM Transaction details won't open. Traceback: Code: Traceback (most recent call last): Works for me. Is there only a few select transactions it cannot display? Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 04, 2017, 08:22:05 PM I expect you're aware of this goatpig; Wallet Properties -> Receive Coins button produces
Code: (ERROR) Traceback (most recent call last): Title: Re: 0.96 preliminary testing Post by: Ente on March 04, 2017, 10:22:18 PM Should the git submodule update command not produce some delta feedback in respect of the changes ? I got a new prompt with nothing. Do I need to make clean first? It should. I'm not an expert with submodules though, first time trying it. There are other ways to get the submodules to update with a command from the top most repo: http://stackoverflow.com/questions/1030169/easy-way-pull-latest-of-all-submodules Otherwise, the "brute force" method is to git pull in the submodule repo. Once I'll more familiar with it I'll update the readme with the most convenient method. Quote No idea why the DB would be already running, I only see that one process running. Anything I can do on my side? Quote No idea why the DB would be already running, I only see that one process running. That line just means the client successfully probed the ip:port you gave it for a listening socket and won't start a local DB. Quote Anything I can do on my side? Do you have some python or C++ in you? EDIT: also please detail your setup. If you dont have any coding in you, I'll make you a separate branch with extra verbose in there for you to paste back here. Sorry for the late reply. Unfortunately no, no developer here. I might identify simple typos after staring half an hour at the code, but that's about it. I'll gladly paste extra-verbose output here. I am running Armory on Debian 8, kernel 4.4.38-11, in a Qubes/Xen VM. Ente Title: Re: 0.96 preliminary testing Post by: droark on March 04, 2017, 11:37:32 PM Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees.
Code: Your transaction comes with a fee rate of 0.00 satoshi/Byte. Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee. Title: Re: 0.96 preliminary testing Post by: goatpig on March 04, 2017, 11:43:36 PM Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees. Code: Your transaction comes with a fee rate of 0.00 satoshi/Byte. Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee. Can you give me a step by step of how you get to that? Title: Re: 0.96 preliminary testing Post by: goatpig on March 05, 2017, 01:38:12 AM I expect you're aware of this goatpig; Wallet Properties -> Receive Coins button produces Code: (ERROR) Traceback (most recent call last): Fixed Title: Re: 0.96 preliminary testing Post by: goatpig on March 05, 2017, 01:39:04 AM Sorry for the late reply. Unfortunately no, no developer here. I might identify simple typos after staring half an hour at the code, but that's about it. I'll gladly paste extra-verbose output here. I am running Armory on Debian 8, kernel 4.4.38-11, in a Qubes/Xen VM. Ente I'll be looking into this soon, sit tight. Title: Re: 0.96 preliminary testing Post by: goatpig on March 05, 2017, 09:59:50 AM - After ~7-8 blocks come in, Armory seems to stop picking up new blocks even though Core keeps chugging along. No messages on the command line. When I close, I have to force quit. The blocks seem to be picked up upon restart. I've pushed some code that should fix this at least on the db side. Can you observe both client and db, and in particular if the client drops the connection with the db, is the db still fine? Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 05, 2017, 12:53:37 PM I expect you're aware of this goatpig; Wallet Properties -> Receive Coins button produces Code: (...) Fixed Possibly this issue is known/WIP also....
QR code & text remains the P2PKH address. Instead of generating one P2PKH, 100 addresses are generated/displayed, and no compressed P2SH addresses at all. Edit(Edit): Title: Re: 0.96 preliminary testing Post by: droark on March 05, 2017, 06:30:02 PM Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees. Code: Your transaction comes with a fee rate of 0.00 satoshi/Byte. Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee. Can you give me a step by step of how you get to that? Okay, now that I've played around with it, the real bug is if the amount being sent is really low. If it's >= 0.1 BTC, you're good. If it's <0.1 BTC, the fee is calculated at times but not at others. Here are examples. I'm not sure there's a pattern to this. Some may work at times but not at others, especially once you start putting in values and then trying new values. 0.09 - No fee 0.001 - Fee 0.01 - No fee 0.011 - No fee 0.0111 - Fee 0.021 - Fee 0.02 - No fee 0.020 - Fee Title: Re: 0.96 preliminary testing Post by: goatpig on March 06, 2017, 01:24:50 AM I expect you're aware of this goatpig; Wallet Properties -> Receive Coins button produces Code: (...) Fixed Possibly this issue is known/WIP also....
QR code & text remains the P2PKH address. Instead of generating one P2PKH, 100 addresses are generated/displayed, and no compressed P2SH addresses at all. Edit(Edit): Fixed Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees. Code: Your transaction comes with a fee rate of 0.00 satoshi/Byte. Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee. Can you give me a step by step of how you get to that? Okay, now that I've played around with it, the real bug is if the amount being sent is really low. If it's >= 0.1 BTC, you're good. If it's <0.1 BTC, the fee is calculated at times but not at others. Here are examples. I'm not sure there's a pattern to this. Some may work at times but not at others, especially once you start putting in values and then trying new values. 0.09 - No fee 0.001 - Fee 0.01 - No fee 0.011 - No fee 0.0111 - Fee 0.021 - Fee 0.02 - No fee 0.020 - Fee Can't reproduce. This has to do with your utxo mix. Try singling it out with coin selection. Title: Re: 0.96 preliminary testing Post by: droark on March 06, 2017, 01:48:36 AM Can't reproduce. This has to do with your utxo mix. Try singling it out with coin selection. As best I can tell, this happens when a wallet's unspent outputs include P2PKH and P2SH-P2PK. (I'm still playing with P2SH-P2WPKH.) If I choose between P2PKH or P2SH-P2PK, the fee code seems to work fine. Regarding the spend dialog, I have noticed something a bit confusing. The dialog, when showing where the coins will go (including the fee), says it'll spend X BTC from the wallet. This includes change sent back into the wallet. I guess this is technically accurate, since the UTXOs are being spent. I think it'd make more sense if it was just the coins leaving the wallet altogether (i.e., everything but the change address and any wallet addresses receiving coins). Title: Re: 0.96 preliminary testing Post by: goatpig on March 06, 2017, 11:44:48 AM Sorry for the late reply. Unfortunately no, no developer here. I might identify simple typos after staring half an hour at the code, but that's about it. I'll gladly paste extra-verbose output here. I am running Armory on Debian 8, kernel 4.4.38-11, in a Qubes/Xen VM. Ente My test worked right away. I'm using a Win8 guest with a Ubuntu 16.04 guest through VBox. As soon as I managed to get nginx through, the client on the host found the server on the guest. For now I'm going to assume something is off in your configuration. For starters, run sanity checks on your server. Next, post your config file and let's go over it. Title: Re: 0.96 preliminary testing Post by: achow101 on March 08, 2017, 04:41:32 AM We have managed to get Armory fully translated into another language, German. Please help use test that the translations are working properly by switching to the other languages and by using the German translations to find any missing strings or bugs with displaying the strings or dialog boxes.
Note that some Usermode strings are not translated. That has been fixed and the translations will be applied once the translation resources are updated later. Title: Re: 0.96 preliminary testing Post by: droark on March 08, 2017, 08:31:34 AM Having some trouble getting the OSX build going. I'm getting the following on the command line.
Code: Doug-Armory:MacOS droark$ ./Armory Poking around online, somebody mentioned that otool -l was a good thing to look at when analyzing libraries. Here's what I see for the version of _CppBlockUtils.so I'm building, then the one for a functioning 0.95.1 library. As best I can tell, the new Make system is installing some code and telling the system to look for it in a given location. This won't work for redistribution of generated binaries. The new version also seems to want to load libc++ instead of libstdc++. (This isn't necessarily bad. It's just a possible sign that wires are getting crossed somewhere.) If anybody has any suggestions, I'd appreciate hearing them. Code: Mach header Code: Mach header Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 11, 2017, 07:14:34 PM I'm not quite sure what the status is with the wallet format. It's obviously changed, but which changes are working now? (even on testnet in the case of PSWPKH)
It's very much a nit, but the format version string still reads 1.35 when I create a new wallet, and it seems rather like the old wallet format has it's address chain folded into the new format somehow? I WANT A NUMBER (even if it's 1.35.0.0.0.1 ;D) Can I delete the old wallet files, or are they the file system representation of the address chain for the new format? Title: Re: 0.96 preliminary testing Post by: goatpig on March 11, 2017, 07:57:01 PM I'm not quite sure what the status is with the wallet format. It's obviously changed, but which changes are working now? (even on testnet in the case of PSWPKH) It's very much a nit, but the format version string still reads 1.35 when I create a new wallet, and it seems rather like the old wallet format has it's address chain folded into the new format somehow? I WANT A NUMBER (even if it's 1.35.0.0.0.1 ;D) Can I delete the old wallet files, or are they the file system representation of the address chain for the new format? The mirror wallets use the stub for the new wallets. The stub doesn't have support for encryption, comments nor BIP32/39/44. Completing the wallet format will be the focus of 0.97 The C++ mirror wallets are only a watching only copy of the 1.35 Python wallets. Mirror wallets are necessary to manage the nested P2SH address types. They also serve as the interface to the DB. The Python wallets are only used by the GUI (which does not understand C++ wallets yet) from now on. The Python wallets still hold your private keys, that currently never hit the C++ wallet code. The private keys are exposed to the new C++ signer when spending from a nested P2SH output. P2PKH signing only uses the old code path. Both paths share the same underlying crypto code under the hood, that part has not changed. The tx messaging format is still the same, so P2PKH outputs created by 0.96 can still be signed by older versions all the way down to 0.92. Older signers won't be able to make sense of any nested address type however. Coin selection and tx composition has been rewritten in C++ to accommodate for satoshi/byte fees and tx size prediction. It should also provide improved privacy and leverage the witness data weighting discount. This is the only part of the code path that was forcibly changed from previous versions. You can opt out of the other changes by just sticking to P2PKH outputs, in which case the new wallet code will not be involved at all in signing nor verification. You cannot delete the old files, these still are your wallets, even the WO versions. The GUI still operates on those. Since the new code only serves as an interface to augment the Python wallets, it does not call for a new version number. Also, while this may be confusing, wallet versioning in Armory actually refers to the address derivation scheme iteration, not the wallet design as a whole. That sheme part has not changed. As a matter of fact, the Python wallet code has not changed, you can verify this by browsing the commit history. Only new conditional code paths have been added to handle nested address types in the GUI. None of that data is written to the Python wallets, it is saved with the C++ wallet container intsead. While you cannot delete your old wallet files, you can delete any .lmdb file at no risk of data loss. These are generated on when missing on every start. The fully fledged new wallets will use another extension. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 11, 2017, 09:12:10 PM The mirror wallets use the stub for the new wallets. The stub doesn't have support for encryption, comments nor BIP32/39/44. But the mirror spec does support BIP32/39/44? I received my Trezor recently, and would like it working with Armory ASAP The C++ mirror wallets are only a watching only copy of the 1.35 Python wallets. Mirror wallets are necessary to manage the nested P2SH address types. They also serve as the interface to the DB. The Python wallets are only used by the GUI (which does not understand C++ wallets yet) from now on. The Python wallets still hold your private keys, that currently never hit the C++ wallet code. The private keys are exposed to the new C++ signer when spending from a nested P2SH output. P2PKH signing only uses the old code path. Both paths share the same underlying crypto code under the hood, that part has not changed. The tx messaging format is still the same, so P2PKH outputs created by 0.96 can still be signed by older versions all the way down to 0.92. Older signers won't be able to make sense of any nested address type however. So 0.96 signing will be recommended for compatibility from now on? And the recommended signing version should freeze at 0.97 assuming the wallet format is finalised in that version? Coin selection and tx composition has been rewritten in C++ to accommodate for satoshi/byte fees and tx size prediction. It should also provide improved privacy and leverage the witness data weighting discount. This is the only part of the code path that was forcibly changed from previous versions. You can opt out of the other changes by just sticking to P2PKH outputs, in which case the new wallet code will not be involved at all in signing nor verification. How does the rewrite improve privacy? You cannot delete the old files, these still are your wallets, even the WO versions. The GUI still operates on those. Since the new code only serves as an interface to augment the Python wallets, it does not call for a new version number. Also, while this may be confusing, wallet versioning in Armory actually refers to the address derivation scheme iteration, not the wallet design as a whole. That sheme part has not changed. What exactly does the scheme comprise, in comparison to the overall format? It sounds like the scheme is simply a component of the format. As a matter of fact, the Python wallet code has not changed, you can verify this by browsing the commit history. Only new conditional code paths have been added to handle nested address types in the GUI. None of that data is written to the Python wallets, it is saved with the C++ wallet container intsead. While you cannot delete your old wallet files, you can delete any .lmdb file at no risk of data loss. These are generated on when missing on every start. The fully fledged new wallets will use another extension. I have to say I like that you've done it this way, it provides flexibility and hence options to the user, allowing each user to use their own judgement of the possible risks of the changes to the code and act accordingly (which you no doubt intended). Title: Re: 0.96 preliminary testing Post by: achow101 on March 12, 2017, 12:35:28 AM But the mirror spec does support BIP32/39/44? The C++ wallets will support BIP 32/44 at some point, as the goal is to move off of the python wallets over to the C++ wallets which will be the entirely new format. The plan is for that to support BIP 32/44, Segwit, and compressed keys. I think it may also support BIP 39 and P2SH, but I'm not sure about that as it's up to goatpig.I received my Trezor recently, and would like it working with Armory ASAP Armory would need to have hardware wallet support for that to work, and that is something I am planning on doing after the new wallet stuff is finished.So 0.96 signing will be recommended for compatibility from now on? And the recommended signing version should freeze at 0.97 assuming the wallet format is finalised in that version? Yes. 0.96 is the new recommended offline signer version as it will have support for segwit and the other output types.How does the rewrite improve privacy? There were changes to coin selection which optimize for privacy, i.e. sticking to inputs from the same address instead of any input in the wallet.Title: Re: 0.96 preliminary testing Post by: goatpig on March 12, 2017, 06:35:45 AM But the mirror spec does support BIP32/39/44? I received my Trezor recently, and would like it working with Armory ASAP No, there is support for that yet. Quote So 0.96 signing will be recommended for compatibility from now on? And the recommended signing version should freeze at 0.97 assuming the wallet format is finalised in that version? If you use anything but P2PKH, you will have to use 0.96. After 0.97 will come out, the signer shouldn't change for the foreseeable future Quote How does the rewrite improve privacy? The main change is that the former coin selection code had to run on a flat fee. The new code is built to operate on just a fee/byte hint, so it outperforms the original code just by design alone (had to add a lot of code to predict tx size). It performs better with flat fee inputs as well since it evaluates its fee/byte effect. The coin-age mechanic does not reflect tx priority anymore, its impact on the coin selection calculation has been greatly reduced. This was the primary metric that allowed the former code to consolidate utxos. The conditions for that consolidation were very restrictive too. Since the new code can predict tx size and adjust fee/byte if necessary, the conditions for consolidations are much laxer. Basically, as long as it can maintain the best privacy score, the code will actively try to consume more utxos than it creates. Utxo consolidation is a long term improvement on privacy. You won't see a benefit from it unless you wallet is highly fragmented. The other changes are around change output obfuscation. The rework around fee/byte support and size prediction is more flexible than the previous code. While the previous code did try to pick outputs that obfuscated the change value, this code has an option ("Adjust Fee") that will pick outputs and adapt the fee to align the decimal point between spend value and change value when using fee/byte. While this change has no effect on flat fees, it is particularly efficient with fee/byte. Since the mirror wallets can handle 2 new P2SH types, it can also match change script type with spend script type. The previous code forced all outputs to P2PKH (the only type it could make sense of). With the new code, in auto change mode (you can modify that in the settings dialog), it will match the change script type with the spend script type. If you don't set it on auto (you can choose to force a specific change script type, say if you want all change to be SW), it will warn you when it differs from the spend script type. Lastly, all these changes properly apply to explicit utxo sets created through coin control. Some of the new code may inflate your fee to improve privacy. The fee inflation is currently hard coded to not increase your fee/byte by more than 10%. I may add an option in the future to modify that margin. Quote What exactly does the scheme comprise, in comparison to the overall format? It sounds like the scheme is simply a component of the format. The format defines how the wallet is handled on disk, error checking and encryption parameters, as well as which cryptographic asset it manages and how. The derivation scheme only defines how cryptographic assets are derived from the seed. In this particular case, Armory 1.35c should be compared to BIP32/44, and the Python wallets (which are unversioned) should be compared to the C++ wallets. Quote I have to say I like that you've done it this way, it provides flexibility and hence options to the user, allowing each user to use their own judgement of the possible risks of the changes to the code and act accordingly (which you no doubt intended). Don't want to potentially split the user base by forcing a new wallet code on the community. There are people out there still using 0.93 for whatever reason. At any rate, SegWit is opt-in, so the code around it should be opt-in too. This doesn't apply to coin selection though, that stuff needed reworked around fee/byte. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 12, 2017, 09:32:02 PM Something that just occurred to me
Is it not the case that "native" (i.e. not nested P2SH) P2WPKH and P2WSH address formats will appear subsequent to Segwit activation? And I say "appear", as they're AFAIA unspecified at this point. Any reasonable expectation that the un-nested Witness address specifications will be available to implement before 0.97? Surely the wallet format needs to be change to incorporate them, although presumably not the signer? Will the wallet format actually stabilise at 97.1 or 0.98, in other words? Title: Re: 0.96 preliminary testing Post by: droark on March 12, 2017, 10:30:59 PM Hello. If anybody out there can compile Armory on Macs, I'd appreciate a little backup. goatpig checked in a fix today that seems to have gotten Armory going again on Macs. :) (It had been broken since the Autotools stuff got checked in.) There are still some compilation issues, though, and probably some runtime issues. I'll PR some changes I had baking before goatpig's fix. More eyeballs and testers would be appreciated, especially once I check in the changes I'd like to make.
Thanks. Title: Re: 0.96 preliminary testing Post by: goatpig on March 13, 2017, 05:11:33 PM Something that just occurred to me Is it not the case that "native" (i.e. not nested P2SH) P2WPKH and P2WSH address formats will appear subsequent to Segwit activation? And I say "appear", as they're AFAIA unspecified at this point. Any reasonable expectation that the un-nested Witness address specifications will be available to implement before 0.97? Surely the wallet format needs to be change to incorporate them, although presumably not the signer? Will the wallet format actually stabilise at 97.1 or 0.98, in other words? sipa has a proposal: https://gist.github.com/sipa/c291da162f6ef8cc770bfc7f015c6c49 It will be discussed at the s3nd meet among other topics: https://s3nd.org/berlin2017 I can't tell whether this will be ready for 0.97, but I expect it will be by 0.98. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 13, 2017, 06:53:40 PM Ah, so there is at least a proposal for a spec (I seem to remember there was an old one that was withdrawn)
Last wallet question Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now. Title: Re: 0.96 preliminary testing Post by: goatpig on March 13, 2017, 07:35:24 PM Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now. Both nested script types have been tested on the testnet. I cross compiled 0.96 for my RPi yesterday and will test the nested compressed key script on the mainnet with my own coins sometimes before I post the first testing builds. Title: Re: 0.96 preliminary testing Post by: droark on March 13, 2017, 09:33:23 PM Just submitted a PR (https://github.com/goatpig/BitcoinArmory/pull/187) that should squash the final-ish bug keeping the OSX build from getting off the ground. It's still not quite working, though. While the DB is being populated after the initial block/Tx scan, Armory seems to get confused and never gets past the scan stage, despite Armory appearing to still be scanning. I really don't see anything else in the logs, unfortunately.
Code: -INFO - 1489439887: (SocketObject.cpp:516) POLLIN recv return 0 Title: Re: 0.96 preliminary testing Post by: goatpig on March 14, 2017, 07:38:30 AM While the DB is being populated after the initial block/Tx scan, Armory seems to get confused and never gets past the scan stage, despite Armory appearing to still be scanning. I really don't see anything else in the logs, unfortunately. Code: -INFO - 1489439887: (SocketObject.cpp:516) POLLIN recv return 0 Use some print statements in the client side callback thread, figure out what signal is not going through: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/SwigClient.cpp#L894 It should receive one case of CBO_BDM_Ready after the scan is complete. Before that, it should be all CBO_progress packets. If it gets those properly, then something is chocking in this scope: https://github.com/goatpig/BitcoinArmory/blob/master/ArmoryQt.py#L5834 Title: Re: 0.96 preliminary testing Post by: droark on March 15, 2017, 03:05:02 AM While the DB is being populated after the initial block/Tx scan, Armory seems to get confused and never gets past the scan stage, despite Armory appearing to still be scanning. I really don't see anything else in the logs, unfortunately. Code: -INFO - 1489439887: (SocketObject.cpp:516) POLLIN recv return 0 Use some print statements in the client side callback thread, figure out what signal is not going through: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/SwigClient.cpp#L894 It should receive one case of CBO_BDM_Ready after the scan is complete. Before that, it should be all CBO_progress packets. If it gets those properly, then something is chocking in this scope: https://github.com/goatpig/BitcoinArmory/blob/master/ArmoryQt.py#L5834 Thanks. Will do. Pushed some more build stuff in the meantime. The build process should be reasonably solid at this point. Title: Re: 0.96 preliminary testing Post by: droark on March 16, 2017, 01:22:14 AM While the DB is being populated after the initial block/Tx scan, Armory seems to get confused and never gets past the scan stage, despite Armory appearing to still be scanning. I really don't see anything else in the logs, unfortunately. Code: -INFO - 1489439887: (SocketObject.cpp:516) POLLIN recv return 0 Use some print statements in the client side callback thread, figure out what signal is not going through: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/SwigClient.cpp#L894 It should receive one case of CBO_BDM_Ready after the scan is complete. Before that, it should be all CBO_progress packets. If it gets those properly, then something is chocking in this scope: https://github.com/goatpig/BitcoinArmory/blob/master/ArmoryQt.py#L5834 Just checked. No CBO_BDM_Ready message comes in. Also discovered that FINISH_LOAD_BLOCKCHAIN_ACTION is never seen in ArmoryQt.py either. Looked at the code a little bit but didn't have much time to sift through it. Where should I look next? Title: Re: 0.96 preliminary testing Post by: goatpig on March 16, 2017, 09:49:59 AM Just checked. No CBO_BDM_Ready message comes in. Also discovered that FINISH_LOAD_BLOCKCHAIN_ACTION is never seen in ArmoryQt.py either. FINISH_LOAD_BLOCKCHAIN_ACTION is triggered by CBO_BDM_Ready. Quote Where should I look next? On the DB side, the signal is emitted here: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BDM_Server.cpp#L1420 There is a lot of code running before it gets to this point. This is the point at which the signal is being prepared to be sent over the socket. My intuition tells me the issue is taking place after that event. A simple print statement should determine that the code always gets past this point (or just looking at the DB log, if it gets past "enabling zero conf", the scan was successful) If the issue is happening before this, I'll lay out the details of the code behind that signal for you to observe. Assuming it gets past this point, my first and foremost culprit would be packet mangling over the socket. The code will not choke over a bad packet, it will simply ignore it. The first thing you should do is log the packets you get from the DB. https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/SwigClient.cpp#L987 retval is a string, you can either output it to stdout or save it to a file. Let the code run and show me the packet log for analysis. EDIT: Here is my packet log for comparison: Code: -INFO - 1489659588: (..\SwigClient.cpp:988) 040c4244565f50726f67726573730704617e578b9b30ef3f000000004d00000000 The last packet is the BDM_ready signal. This 42444d5f5265616479 stands for BDM_Ready in hexits, the last part is a 4bytes integer with its header (02). Title: Re: 0.96 preliminary testing Post by: droark on March 16, 2017, 06:21:56 PM Thanks. I looked into some of this late last night. You wrote a much more detailed version of what I found.
Here's an excerpt from dbLog.txt. I think there's something wrong with how the file's written, as it crashed my normal text editor! (A bug in my text editor, I know, but the actual log is still mangled under other text editors. ~550 KB worth of ^@ can be seen at the front of my log under vim and nano.) While I haven't confirmed yet, I suspect something's going wrong inside this call (https://github.com/goatpig/BitcoinArmory/blob/9921f3e79a7fe1c95b0e15caec0bce1ecde0890b/cppForSwig/BDM_Server.cpp#L1387). In any event, it seems like the registerWalletMutex_ lock gets screwed up along the way and leaves ArmoryDB hanging. Code: --------ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR - - - - - - - 14896841641489684164148968416414896841641489684164- 148968416414896841641489684164: : : : : : : (((((: (((BlockchainScanner.cppBlockchainScanner.cppBlockchainScanner.cppBlockchainScanner.cppBlockchainScanner.cppBlockchainScanner.cppBlockchainScanner.cpp:::::BlockchainScanner.cpp::271271271271271:271271271) ) ) ) ) ) ) ) raw data does not match expected block hashraw data does not match expected block hashraw data does not match expected block hashraw data does not match expected block hashraw data does not match expected block hashraw data does not match expected block hashraw data does not match expected block hash Title: Re: 0.96 preliminary testing Post by: goatpig on March 16, 2017, 08:17:32 PM The error in your code snippet is the scan process failing to grab valid block data (it's failing the merkle hash check in basically every thread).
Quote I suspect something's going wrong inside this call Is the promise failing to signal the future or the code leading to set the promise failing? This is surprising, that code didn't change at all from 0.95 to 0.96. Have you considered building with XCode 8? Title: Re: 0.96 preliminary testing Post by: droark on March 16, 2017, 09:19:16 PM The error in your code snippet is the scan process failing to grab valid block data (it's failing the merkle hash check in basically every thread). Interesting. Quote Quote I suspect something's going wrong inside this call (https://github.com/goatpig/BitcoinArmory/blob/9921f3e79a7fe1c95b0e15caec0bce1ecde0890b/cppForSwig/BDM_Server.cpp#L1387) Is the promise failing to signal the future or the code leading to set the promise failing? This is surprising, that code didn't change at all from 0.95 to 0.96. Have you considered building with XCode 8? Okay, I confirmed that, for whatever reasons, the wait() call causes things to go sideways, or at least gets stuck due to registerAddressBatch() never truly finishing. The code doesn't crash. It just never seems to get past the wait. Right now, I'm compiling on an OSX 10.12/Xcode 8 combo, as that's the easiest for me. (10.11/7.3.1, the combo I use for release builds, requires me to use a VM. It seems to fail in a similar manner, though, based off a version I ran a few days ago.) Just in case I've missed something, I've copied & pasted the entire ArmoryDB log. Maybe the cookie error means something? Hard to say since I don't know this code. Code: Log file opened at 1489698375: /Users/droark/Library/Application Support/Armory/testnet3/dbLog.txt Title: Re: 0.96 preliminary testing Post by: goatpig on March 16, 2017, 09:22:16 PM cookie error means you aren't running your node with server=1. Maybe that has something to do with the whole process? That's the only new code somehow related to this (it uses the same notification pipeline).
Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 16, 2017, 09:37:11 PM Yep, exactly the symptoms I experienced (cookie error) before achow101 set it straight. Needs to be in the 0.96 release notes, and if possible written to bitcoin.conf automatically (IMO)
Title: Re: 0.96 preliminary testing Post by: goatpig on March 16, 2017, 09:49:03 PM Yep, exactly the symptoms I experienced (cookie error) before achow101 set it straight. Needs to be in the 0.96 release notes, and if possible written to bitcoin.conf automatically (IMO) Code just needs fixed to not nuke everything else on failure. As for the automated bitcoin.conf modification, that introduces the credential issues from before that I don't want to deal with at all. I don't mind that the RPC may fail to setup, I mind that it takes the entire ship on its way down. Title: Re: 0.96 preliminary testing Post by: droark on March 16, 2017, 10:08:31 PM Yep, exactly the symptoms I experienced (cookie error) before achow101 set it straight. Needs to be in the 0.96 release notes, and if possible written to bitcoin.conf automatically (IMO) Agreed (although a bitcoin.conf auto-write worries me). It didn't make my main problem go away but it did fix that particular error. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 16, 2017, 10:15:07 PM Hmmm, can't help but agree. I say it though as I'm anticipating constant creation of new & potentially long threads where this issue is troubleshooted, until round about the end of time itself
:D Title: Re: 0.96 preliminary testing Post by: droark on March 17, 2017, 01:22:42 AM cookie error means you aren't running your node with server=1. Maybe that has something to do with the whole process? That's the only new code somehow related to this (it uses the same notification pipeline). Gaaaaaaah. I thought I had deleted the DB earlier and started from scratch. I hadn't. Once I did, Armory scanned everything just fine. Just curious, is ArmoryDB supposed to take awhile to shut down? It takes something like 20-30 seconds to shut down on my machine, even though the CPU isn't active for most of that time. Of course, it's an improvement over 0.95, where it never shut down, period. :) Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 17, 2017, 06:53:04 AM Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now. Both nested script types have been tested on the testnet. I cross compiled 0.96 for my RPi yesterday and will test the nested compressed key script on the mainnet with my own coins sometimes before I post the first testing builds. Any news on this? Title: Re: 0.96 preliminary testing Post by: goatpig on March 17, 2017, 07:26:22 AM It takes something like 20-30 seconds to shut down on my machine, even though the CPU isn't active for most of that time. Of course, it's an improvement over 0.95, where it never shut down, period. :) This is still (imo) the FCGI lib taking a while to shutdown. Again, you can try to profile that stuff. Here is a list of all the threads that need end for the process to exit gracefully: Code: 1) client callback thread This list assumes you got out of the initial scan. Otherwise, it gets a lot more complicated. Just exiting the main thread should be enough to kill the process, although that alone won't guarantee a gracious shutdown. The most important thing to do during shutdown is to properly close the LMDB objects. Quote Any news on this? Sorry, busy IRL, will get to it sometimes before the Sunday. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 17, 2017, 10:00:30 AM Sorry, busy IRL, will get to it sometimes before the Sunday. No real rush, like I said, I'd just prefer to start using compressed keys for everyone's sake. On that note, will compressed keys become the default key chain in the new wallets? And nested P2WPKH subsequently? I'm hardly expecting a no, I'm just wondering if you think that might cause an issue I'm not seeing. A mild Bug in 0.96 The scroll bar magic (that traverses super long balance lists) becomes stuck if I try to get beyond a certain proportion of the balance entries. I'm just clicking, holding the click, and dragging the bar all the way to the base of the bar's range. Releasing the click and re-dragging to the base of the bar gets me to the actual definitively oldest tx, but trying to do the same trick on the way back to the top doesn't work; the magic itself begins to loop to the sticking point, as if that's the most recent transaction. Simply using the 'Goto' button's 'Top' hyperlink style thingy remedies this bottom->top sticking. Edit - A separate issue is possibly triggered by this; after provoking this bug, when a new block comes in, Armory sends the tx entry highlight/selection bar ~ 60 tx entries lower down the list, where it would ordinarily remain scrolled to the top and de-highlight the entry that was highlighted before the block arrived. If that makes sense! The server=1/RPC cookie issue If the absence of server=1 can be detected, why not get Armory to produce an Error dialog box to tell the user how to deal with the issue? As I said, there'll be infinity threads about this if it's not handled at the software end somehow Title: Re: 0.96 preliminary testing Post by: achow101 on March 17, 2017, 01:03:31 PM The server=1/RPC cookie issue Since the RPC stuff is now handled by the DB side, I imagine there's something that makes it difficult for an error on the DB end to trigger an error on the client end, although I am not sure. I can take a look and see if I can do anything about it this weekend.If the absence of server=1 can be detected, why not get Armory to produce an Error dialog box to tell the user how to deal with the issue? As I said, there'll be infinity threads about this if it's not handled at the software end somehow Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 17, 2017, 01:40:00 PM Right, but the front end and the back end talk to each other. I guess it's a question of which you prefer, taking the time to change the code, or fielding alot of users getting the same problem in the subforum.
If even droark isn't clued in enough to picked it up straight away, I'd predict ~ 75% of users will be wailing about it without checking the pre-existing 12+ frontpage threads here describing the same issue. Title: Re: 0.96 preliminary testing Post by: droark on March 17, 2017, 04:29:36 PM Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now. Both nested script types have been tested on the testnet. I cross compiled 0.96 for my RPi yesterday and will test the nested compressed key script on the mainnet with my own coins sometimes before I post the first testing builds. Any news on this? Just now saw this. I've done a few transactions on testnet. Nothing thorough by any means but no problems on my end, other than the fee code being a bit screwy for awhile. (I believe it was cleared up awhile back.) It takes something like 20-30 seconds to shut down on my machine, even though the CPU isn't active for most of that time. Of course, it's an improvement over 0.95, where it never shut down, period. :) This is still (imo) the FCGI lib taking a while to shutdown. Again, you can try to profile that stuff. Here is a list of all the threads that need end for the process to exit gracefully: Thanks. Will look when I get a chance. Title: Re: 0.96 preliminary testing Post by: goatpig on March 17, 2017, 06:43:45 PM No real rush, like I said, I'd just prefer to start using compressed keys for everyone's sake. On that note, will compressed keys become the default key chain in the new wallets? And nested P2WPKH subsequently? I'm hardly expecting a no, I'm just wondering if you think that might cause an issue I'm not seeing. There are 2 separate code paths for this: 1) Requesting payment addresses. This defaults to P2PKH. I did not add an option to change the default in the settings dialog, I'll have to deal with it eventually. 2) Change addresses. If left on auto, the code will try to match the spend script type. If all spend scripts are P2PKH, it will create a P2PKH change output and vice versa. When pay script types are mixed, auto will favor nested change types. In case of a SW tx, it will favor nested SW, otherwise nested P2PK. This helps privacy at the cost of converting to compressed keys (or eventually SW) by default. You can however force the change type default to whatever you want in the setting dialog. You will receive a warning about reduced privacy if your change type differs from the pay script type however. The drawbacks are 2 fold: You cannot sign for nested types with pre 0.96 signers, and you can't expect to see your funds by simply importing the private keys in another wallet software and expect to see the balance of the nested scripts. These probably don't scan for these P2SH variations. I will most likely mitigate that by offering disgruntled users an opportunity to scan their wallets against my DB on demand, to create a tx and move their coins out in one sweep. Quote The scroll bar magic (that traverses super long balance lists) becomes stuck if I try to get beyond a certain proportion of the balance entries. I'm just clicking, holding the click, and dragging the bar all the way to the base of the bar's range. This doesn't trigger the Qt signal for hitting the end of the list until after you release the bar. I'm not sure where to get the signal for that event (if there's even one). I was aware of that limitation when I wrote this code but the cost of just figuring out how to get a signal off of the scroll bar is too high to bother as it is. It may appear lazy, but I settled for the model's signal, which won't trigger until after user input is completed. Hence is works by releasing the scroll bar, just using the arrows, or rolling the mouse scroller. Quote If the absence of server=1 can be detected, why not get Armory to produce an Error dialog box to tell the user how to deal with the issue? As I said, there'll be infinity threads about this if it's not handled at the software end somehow I will eventually report the RPC status in the bottom right corner tooltip overlay. I don't intent to leave the bug there to begin with, it shouldn't prevent the DB from setting up. Title: Re: 0.96 preliminary testing Post by: goatpig on March 17, 2017, 09:59:54 PM I can't reproduce the server=1 issue, can someone lay out the exact steps?
Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 17, 2017, 10:44:50 PM Do you mean that 0.96 connects the DB to the wallet without server=1 ? What sorcery is this? :D
Title: Re: 0.96 preliminary testing Post by: goatpig on March 17, 2017, 10:55:19 PM It does, whether the RPC works or not. The particular issue with the messed up cookie file is due to how the config file works with the testnet. When running against the testnet, Core still uses the .conf in the mainnet datadir to init, but will create the cookie file in the testnet datadir.
Title: Re: 0.96 preliminary testing Post by: bvoid on March 25, 2017, 07:07:13 PM Goatpig is it possible to upload the Armory_0.96_win64.exe (beta) on the website? I can't transfer my coins because of the "the broadcast process failed unexpectedly" bug. Thanks! :)
Title: Re: 0.96 preliminary testing Post by: goatpig on March 25, 2017, 07:28:40 PM Goatpig is it possible to upload the Armory_0.96_win64.exe (beta) on the website? I can't transfer my coins because of the "the broadcast process failed unexpectedly" bug. Thanks! :) I understand your predicament but I can't yet push code that I don't believe is production ready. While you can build the code from source by pulling the dev branch, I am sorry but you will have to wait for signed binaries from me. Hopefully I'll have a test build out tomorrow. Otherwise, sometimes next week. Title: Re: 0.96 preliminary testing Post by: goatpig on March 26, 2017, 03:35:51 PM Pushed RBF.
Everything under the hood works. The GUI is rudimentary however. Basically it does not yet sort out corner cases like RBF -> CPFP -> RBF. By design, conflicts between RBF and CPFP outputs are side stepped: CPFP and RBF are mutually exclusive. However, this isn't represented the GUI yet, which is the other part that needs polished before the UX is acceptable. As it stands, you can: - CPFP any eligible output correctly. - Create RBF transactions - CPFP an replacable output (say the change to your RBF spend) - RBF any eligible RBF output. However conflicts are not handled: you can for example pick a replaceable output from one tx and a replaceable output from a child tx to the first one. This is a conflicting set of outputs. The GUI does not implement conflict detection and handling yet, but the Tx will obviously be invalid. Once conflicts are handled the GUI, the code will be ready for testing releases. ETA Monday or Tuesday. I have no yet tested spending from nested scripts on the mainnet, so please stay away from these until I risk my own money with them first. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 26, 2017, 08:39:01 PM Builds, but dies before ArmoryDB launches with this:
Code: def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals): Title: Re: 0.96 preliminary testing Post by: goatpig on March 27, 2017, 11:44:54 AM I'm an idiot, forgot to push a file. Should work now.
Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 27, 2017, 02:38:53 PM All is well.
What's the purpose of the RBF button on the Send form? I'm getting no addresses in the fields, whether I tick the RBF checkbox or not. Needs wallet 1.35c, or compressed keys? Or a different setting? (in Core maybe?) Title: Re: 0.96 preliminary testing Post by: goatpig on March 27, 2017, 03:01:41 PM It works like the coin control dialog, but only lists RBF outputs. For an output to be listed there you need to
1) Create a transaction with the RBF option checked. 2) Have the transaction broadcast successful. All redeemed outputs should show in the RBF dialog. I guess I should rename the button to have it convey that meaning. The idea is that RBF and coin control are mutually exclusive (since coin control also lists CPFP outputs, and these will more often than not conflict with RBF outputs). If there is a demand for RBF to work with coin control, I'll look into that improvement in a later release. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 27, 2017, 03:10:36 PM Why not make it more direct? i.e. Right click eligible zero confs in the main tx window, a new (and probably simpler) dialog handles the fee bumping.
Presumably bumping the fee on some inputs and not others is meaningless, as all inputs are children of the overall parent transaction, for which there is a single fee applied for every byte? Makes sense to me, especially now that age-related priority is deprecated and on it's way to retirement. Title: Re: 0.96 preliminary testing Post by: goatpig on March 27, 2017, 04:42:05 PM Why not make it more direct? i.e. Right click eligible zero confs in the main tx window, a new (and probably simpler) dialog handles the fee bumping. There will be an option to do that eventually but for now RBF is an expert feature. A bit of reasoning: 1) A sole bump fee feature hinges on a few assumptions that won't be met half the time. If the user expects to be able to bump fees off of the ledger, it supposes all transactions are RBF by default. I do not intent to do this. RBF will remain an opt-in feature in Armory, and off by default. I will most likely allow people to change the default in the settings, and consider adding a warning message on low fee transactions to turn on RBF. But I won't just force the thing on. 2) As a result, the whole bump off of the ledger part will be confusing. Either users will never use it (they would work with the outputs directly instead), or they turn to rely on the feature but end up confused when they fail to RBF. 3) RBF is not the only way to "pull in" a transaction. CPFP can be used to that effect as well, albeit for a higher fee at the cost of more block space. I want to let people have the choice, which would mean implementing a "pull transaction" option to the fee bump feature. Not that I think it's a bad idea, but now there is a lot of extra GUI to implement, and I don't want to pigeon people into a single feature as a way out. 4) How do I signal a transaction is eligible for replacement in the tx ledger? There is only so much room in the comment column (and text only gets you so far), nor is it very feasible to flash colors per line in these ledgers, and even that doesn't evidence what to do to bump the tx. Ideally a button just showing up on the particular line named "bump me!" would do the job. But I'm not sure the ledger model allows anything but text to be returned as entries to an index, so I can't go into this with a guarantee I can implement the model. 5) Most importantly, I cant skip the coin control like RBF GUI, because it is the only way to cleanly evidence RBF entries in a zero conf chain, and which child zc gets knocked off by a replacement. And also because at its core RBF is a double spend feature, so it should be usable in that way. It's not my place to figure out how that will be useful, but Armory is a wallet for advanced users, so it shouldn't curtail people to a narrow UX. Given that this UI has to go in either way, I have to do it first. And before you argue this stuff won't happen, RBF is a fringe feature to begin with. You do not need this during regular operations, only when crazy stuff like a wild spam spike appears or the chain is being attacked, or you are trying to taint coins after a chain split. Who knows how convoluted things can get then. This is why RBF should be snafu proof from the get go. Title: Re: 0.96 preliminary testing Post by: Carlton Banks on March 27, 2017, 05:45:47 PM The way I imagined it was:
Maintain the opt-in checkbox on the Send form, and create an overridden/inherited version of the right-click contextual menu that only presents "RBF" option for those transactions for which the opt-in had been stipulated in the Send form. I think I see what you're getting at with chains of zero-confs though, but is it not the case that doing it as I describe would force the user in such circumstances to figure out for themselves which dependent tx is holding the others up? i.e. it would force the user to take responsibility for setting their own fees, and discourage bad practices, like creating chains of dependent tx's with insufficient fees? Would making it easier in one way, yet making it harder feature to discover and understand in others, achieve less abuse of the RBF feature in practice? Title: Re: 0.96 preliminary testing Post by: achow101 on March 29, 2017, 01:02:42 PM Every couple of hours, ArmoryDB disconnects and reconnects to my Bitcoin Core node for some reason. It hits a StopBlockingLoop exception in processDataStackThread but I am not sure why.
I am running a build of Bitcoin Core's development branch, so it may be possible that something was changed for the next version of Core that is causing this error to occur. If that is the case, then this needs to be fixed so that we don't get a repeat of the "transaction timed out" errors. I put it in gdb and let it run until that exception was thrown. Here is the backtrace of when gdb stopped at the exception being thrown (I think this is the right place for it to stop): Code: #0 0x00007ffff78c58bd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 Title: Re: 0.96 preliminary testing Post by: johnlu on March 30, 2017, 12:55:01 PM Hi goatpig. I know 0.96 will be released when it is ready :D
Do yo have an estimated date? I know you wouldn't like to commit to a shipping date or so. I just ask this to know how the roadmap is going through. Thanks for your support and efforts for the community! :-) Title: Re: 0.96 preliminary testing Post by: achow101 on March 30, 2017, 12:57:12 PM Hi goatpig. I know 0.96 will be released when it is ready :D The first testing build should be out today. Goatpig just bumped the version numbers and yesterday he told me he was going to release the first testing binaries today.Do yo have an estimated date? I know you wouldn't like to commit to a shipping date or so. I just ask this to know how the roadmap is going through. Thanks for your support and efforts for the community! :-) Title: Re: 0.96 preliminary testing Post by: goatpig on March 31, 2017, 08:00:58 PM Testing builds are out, moved the code to the testing branch. Dev will be unstable again soon. Unsticking this thread.
Tested the compressed key script on the mainnet. RBF too. So far so good. Quote Would making it easier in one way, yet making it harder feature to discover and understand in others, achieve less abuse of the RBF feature in practice? Usually, honest users don't try as hard to get things to work as malevolent ones. You are better off making the thing easy to use in the end. But UX is a pain to work on, so in due time. Title: Re: 0.96 preliminary testing Post by: bvoid on March 31, 2017, 08:49:45 PM No exe's in the test branch?
Title: Re: 0.96 preliminary testing Post by: goatpig on March 31, 2017, 09:09:19 PM No exe's in the test branch? I don't understand the question Title: Re: 0.96 preliminary testing Post by: achow101 on March 31, 2017, 09:31:13 PM No exe's in the test branch? Binaries are not committed to the source code, they are not source code. You can can get the 0.96 testing binaries from https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.99.1-testing |