0.94 preliminary testing phase

[goatpig]

That is some weird implementation of operator<< with stringstream on these compilers! I'll push that change and merge the OSX build PR in a minute.

[droark]

Okay. Having two problems with the OS X build.

1)The balance isn't quite right. It's missing a few transactions here and there. Nothing in the logs that I can see.

2)I can't send coins. Am getting the following error.

Code:

(ERROR) Traceback (most recent call last):
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 785, in createTxAndBroadcast
    ustx = self.validateInputsGetUSTX()
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 766, in validateInputsGetUSTX
    utxoSelect, scriptValPairs, pubKeyMap)
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/Transaction.py", line 2148, in createFromTxOutSelection
    return self.createFromPyTx(thePyTx, pubKeyMap, txMap, p2shMap)
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/Transaction.py", line 2058, in createFromPyTx
    cppPrevTx = TheBDM.bdv().getTxByHash(txhash)
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 2115, in getTxByHash
    def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError: invalid blkFolder

[Carlton Banks]

Both 16a1569 and 3f02b93 are compiling and Db building OK for me. Now testing with Core 0.12.0 final also (still have a 0.11.2 copy of the blockchain that I will continue to test)

[achow101]

I am having some build problems that I can't figure out. My build output is on pastebin here: http://pastebin.com/QAVGGuui

Looks like you are missing entire parts of the  C++ STL. Which compiler are you using? Also, is it C++11 compatible?

I am using gcc 5.2.1.

It looks like the problem is fixed and now I am running it for testing.

Edit: I'm getting an error about invalid varint

Code:

-DEBUG - 1456328054: (Blockchain.cpp:213) Organizing chain 
-INFO  - 1456328054: (DatabaseBuilder.cpp:47) updated HEADERS db in 0.311487s
-ERROR - 1456328054: (StoredBlockObj.cpp:1346) invalid varint in SSH data
-ERROR - 1456328054: (BDM_mainthread.cpp:429) BDM thread failed: invalid varint

[goatpig]

Lots of changes, everybody will have to rebuild the DB from scratch.

2)I can't send coins. Am getting the following error.

should be fixed now

1)The balance isn't quite right. It's missing a few transactions here and there. Nothing in the logs that I can see.

Are you getting a different balance/ledger scanning the same datadir with another version of Armory? Is there a pattern in the missing transactions (I don't do multisig refs in this db, if you have a lot of lockbox activity you will be missing ledger entries but not balance)? I updated the top block reporting mechanic, is the new db reporting the proper top block now?

Edit: I'm getting an error about invalid varint

Does the error persist with this version?

[goatpig]

Pushed some more changes, make sure you pull from b24dcb2 onwards.

[achow101]

Does the error persist with this version?

Pushed some more changes, make sure you pull from b24dcb2 onwards.

Working well. No problems yet.

Edit: I also get the same coin control problem droark mentioned in the other thread. Here is the traceback:

Code:

(ERROR) Traceback (most recent call last):
  File "/home/andy/bitcoin/armory/BitcoinArmory/ui/TxFrames.py", line 785, in createTxAndBroadcast
    ustx = self.validateInputsGetUSTX()
  File "/home/andy/bitcoin/armory/BitcoinArmory/ui/TxFrames.py", line 602, in validateInputsGetUSTX
    utxoList = self.getUsableTxOutList(totalSend)
  File "/home/andy/bitcoin/armory/BitcoinArmory/ui/TxFrames.py", line 863, in getUsableTxOutList
    utxos = cppAddr.getSpendableTxOutList(IGNOREZC)
  File "/home/andy/bitcoin/armory/BitcoinArmory/CppBlockUtils.py", line 1969, in getSpendableTxOutList
    def getSpendableTxOutList(self, ignoreZC=True): return _CppBlockUtils.ScrAddrObj_getSpendableTxOutList(self, ignoreZC)
RuntimeError: not implemented

[goatpig]

I also get the same coin control problem droark mentioned in the other thread

Should be fixed now.

Introduced a new feature to rescan balances. Let's you fix balance errors without doing a full rescan, takes less than a minute on average (it's actually <1 sec on my machine). No need to wipe the DB with this commit, just try it as is.

[achow101]

I also get the same coin control problem droark mentioned in the other thread

Should be fixed now.

Introduced a new feature to rescan balances. Let's you fix balance errors without doing a full rescan, takes less than a minute on average (it's actually <1 sec on my machine). No need to wipe the DB with this commit, just try it as is.

They both appear to work now.

[Carlton Banks]

An issue switching Core client between 0.12 and 0.11.2: I'm finding that building the Armory db with 0.11.2 initially, then restarting Armory using 0.12 (with all 0.12 validated blocks) renders Armory stuck at the last block the initial build using 0.11.2 had previously reached. Doing the same test, but with 0.12 providing Armory with the initial block data to build the  db recognises the latest block when restarted using 0.11.2. Had this problem with builds previous to b24dcb2 also. Not sure what happens when doing 0.12.0 > 0.11.2 > 0.12.0 etc, haven't tried that

[achow101]

An issue switching Core client between 0.12 and 0.11.2: I'm finding that building the Armory db with 0.11.2 initially, then restarting Armory using 0.12 (with all 0.12 validated blocks) renders Armory stuck at the last block the initial build using 0.11.2 had previously reached. Doing the same test, but with 0.12 providing Armory with the initial block data to build the  db recognises the latest block when restarted using 0.11.2. Had this problem with builds previous to b24dcb2 also. Not sure what happens when doing 0.12.0 > 0.11.2 > 0.12.0 etc, haven't tried that

Perhaps that has something to do with bitcoin core 0.12 obfuscating the chainstate after syncs and reindexs. See the downgrade warning in the release notes.

[goatpig]

I'll test that directly sometimes later.

[goatpig]

Added a couple changes. Maybe that will fix the 0.11.x -> 0.12 swapping.

Going over the RBF PR, it's missing some stuff so I'll have to implement that before merging in into dev.

[achow101]

Added a couple changes. Maybe that will fix the 0.11.x -> 0.12 swapping.

Going over the RBF PR, it's missing some stuff so I'll have to implement that before merging in into dev.

IIRC RBF is only missing the actual mempool replacement stuff and the ability to create RBF transactions.

For the clean up ATI stuff, do you want to remove all of the phone home stuff? In my PR, I only have it commented out because you said earlier that it may be brought back in the future.

[goatpig]

Added a couple changes. Maybe that will fix the 0.11.x -> 0.12 swapping.

Going over the RBF PR, it's missing some stuff so I'll have to implement that before merging in into dev.

IIRC RBF is only missing the actual mempool replacement stuff and the ability to create RBF transactions.

RBF transactions aren't flagged in the main ledger nor the tx info dialog. No detection of RBF inheritence either.

For the clean up ATI stuff, do you want to remove all of the phone home stuff? In my PR, I only have it commented out because you said earlier that it may be brought back in the future.

Deactivating it is fine for now. I will have to evaluate the code and its usefulness eventually.

[goatpig]

RBF handling is actually a lot more complicated than I expected. This is gonna take me a day.

[achow101]

Added a couple changes. Maybe that will fix the 0.11.x -> 0.12 swapping.

Going over the RBF PR, it's missing some stuff so I'll have to implement that before merging in into dev.

IIRC RBF is only missing the actual mempool replacement stuff and the ability to create RBF transactions.

RBF transactions aren't flagged in the main ledger nor the tx info dialog. No detection of RBF inheritence either.

Hm. I thought my PR flagged RBF transactions in the tx info dialog.

[goatpig]

Hm. I thought my PR flagged RBF transactions in the tx info dialog.

It detects RBF in transaction.py, which is a file limited to creating transactions, not processing transaction history. Detection needs to take place at ledger creation (ideally on the C++ side), and it has to deal with inheritance properly, which I am working on.

[goatpig]

Pushed opt-in RBF detection. Regarding inheritence, I went took the simple route: any ZC of ZC is flagged as mempool replaceable, whether the chain of ZC has an RBF input somewhere or not.

If this version passes the test, I'll release the first testing build based on this state.

[achow101]

Pushed opt-in RBF detection. Regarding inheritence, I went took the simple route: any ZC of ZC is flagged as mempool replaceable, whether the chain of ZC has an RBF input somewhere or not.

If this version passes the test, I'll release the first testing build based on this state.

Awesome. Will be building and testing.

Edit: Build error:

Code:

g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -std=c++11 -O2 -pipe -fPIC -c BDM_supportClasses.cpp
BDM_supportClasses.cpp: In member function ‘std::map<BinaryData, std::vector<BinaryData> > ZeroConfContainer::purge(std::function<bool(const BinaryData&)>)’:
BDM_supportClasses.cpp:620:52: error: invalid initialization of non-const reference of type ‘BinaryData&’ from an rvalue of type ‘BinaryData’
          auto& bhash = lastKnownHeader->getPrevHash();
                                                    ^
Makefile:97: recipe for target 'BDM_supportClasses.o' failed
make[1]: *** [BDM_supportClasses.o] Error 1

Edit 2: Does armoryd indicate if the transaction is RBF? Or is it just GUI right now?