Topic: Armory 0.93 testing release! (with 0.05 BTC bug bounty) - page 16. (Read 35695 times)

OS X 10.10
I also noticed that there is an option to rescan an individual lockbox when I right click it, can the same option be added to wallets?

Oh, I forgot to ask, which version of OS X you're running? I'm still running 10.9.5 on my Mac (I'll upgrade to 10.10 soon) but I also build and run Armory on VMs for the latest versions from 10.7-10.10.

0.93-bugfix now works for me.

Issue should be fixed now, feel free to pull 0.93-bugfix and give it a spin. As usual, wipe your existing DB beforehand

Lol, it is ugly but at least it works

Yeah, I can always revert to that one. I just don't like it because there's no way, short of trickery or copying files beforehand, to get files from external media. (That and, let's face it, the Qt browser is ugly.)

It was working fine with the old Qt file browser

Strange, and very frustrating to hear. Anybody else out there on OS X want to report on if the latest version freezes when they try to load or save a wallet? I swear that all's well on my setup.

0.92.99.3 fullnode on Windows 7 here. Armory is fully synchronized, not apparently doing anything, but the CPU usage averages about 22-24% of a core (6% total), whether the Armory window is visible or not. It did not do this in earlier versions (certainly not in 0.92, and I don't think it did it in 0.92.99.2).

I had issues (i.e. a crash) with it building the db for a supernode earlier, but I know that I don't have the very latest version (waiting for a Windows build), so I won't repeat that.

0.92.99.3, the text below "Armory is disconnected" has a broken tag, "br>", visible.

Yes and yes to the two bolded questions above.
I have another bug to report, I cannot sign transactions coming from lockboxes.

2015-01-24 15:47 (ERROR) -- Traceback (most recent call last):
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/MultiSigDialogs.py", line 2712, in doSign
self.doSignForInput(idstring, nIdx)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/MultiSigDialogs.py", line 2932, in doSignForInput
ustxi.createAndInsertSignature(pytx, addrObj.binPrivKey32_Plain)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/Transaction.py", line 1276, in createAndInsertSignature
derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/Transaction.py", line 1235, in createTxSignature
raise SignatureError('No PubKey that matches this privKey')
SignatureError: No PubKey that matches this privKey

That repeated itself in logs about 6 times before I was actually able to sign it by clicking the Sign button right after the passphrase text field closed.

One more:

Once I open the transaction window, it will not let me close it and there is no cancel button.
I'm not sure if it's like that on purpose, but sometimes it can get annoying because I either have to execute the transaction or quit Armory completely.

I also noticed that Armory now displays unconfirmed funds in Spendable Funds. However I try to send funds, the Send button does nothing and displays this error in the log each time I click it:

2015-01-22 06:45 (ERROR) -- Traceback (most recent call last):
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 757, in createTxAndBroadcast
ustx = self.validateInputsGetUSTX()
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 597, in validateInputsGetUSTX
utxoList = self.getUsableTxOutList(totalSend)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 828, in getUsableTxOutList
return list(self.wlt.getUTXOListForSpendVal(totalSend))
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/PyBtcWallet.py", line 52, in inner
return func(args, *kwargs)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/PyBtcWallet.py", line 451, in getUTXOListForSpendVal
return self.cppWallet.getSpendableTxOutListForValue(valToSpend, IGNOREZC);
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 1806, in getSpendableTxOutListForValue
def getSpendableTxOutListForValue(self, *args): return _CppBlockUtils.BtcWallet_getSpendableTxOutListForValue(self, *args)
RuntimeError

I'd also like a Cancel button on the Send Bitcoins dialog so I don't have to close Armory each time I accidentally open it.

tl;dr - Can everybody who runs OS X grab the latest version (0.92.99.3) and try to save and load some wallets? Once again, there may be issues I'm not seeing on my system or my VMs.

You're on OS X, right? Which version are you running? Are you using 0.92.99.3? Long story short, I switched the file browser to the native browser instead of a Qt-based one. It worked perfectly for me on my Mac and my Mac VMs. Unfortunately, I was never able to get anyone else to test it internally, so I just went off my test results and merged in the change.

(For technical types, on my system, an upgrade to an official Qt 4.8.7 snapshot appeared to resolve a long-standing issue that had been forcing us to use a Qt-based file browser. The Qt-based one doesn't support external media without the user playing tricks on it, so we'd greatly prefer the native browser.)

I've finally reproduced your issue, and I am now 95% sure 0.10 out of order block data is the culprit.

When I try to import Watching only wallet data from a text file, the file browser freezes. I can't scroll, select files, or even close it.

I happened to be importing another Watching only wallet, after I closed Armory instead of it scanning individual wallets, it started scanning the whole thing, I could not see balances on any wallet as if I had initiated a full rescan.

Also you might want to update the OP with the new testing release (0.92.99.3)

Wasn't what I was working on at all. Catching me off guard now

I didn't realize you had not tested against this yet. That sounds to me to be the mostly likely possibility.

10³

I currently suspect it is some sort of blind spot in the code in regards to out of order data in blk files. This is something I have not worked with at all, I simply trusted the unit tests we have for it, and now I realize it is the one factor I have never tested my code against. I would definitely withhold all other suspicions until I have scanned a 0.10 mainnet chain.

I'm making a point of downloading all blocks from the client in order to have as many out of order blocks as possible, so this is taking ages to sync. Hopefully it yields some valuable information.


I'm not sure about the timing but HDD_opts has been merged into bugfix earlier this week, so if you pulled that branch recently you're essentially running the same code. Also a bunch of fixes to that code were worked in bugfix, and I only just merged these back into HDD_opts today.

As for your wallets, how many addresses do they contain in total? More like 1k, 10k or 100k+?

Still can't successfully index the blockchain.

Using this morning's version of the 0.93_bugfix branch, and Bitcoin Core 0.10.0_rc3 (this time, bootstrapped from the most current bootstrap.dat instead of purely from the network) I get to block 323413 before it throws an error.

Is it possible for the contents of a wallet to interfere with a blockchain scan?

The reason I ask is because I did get Armory to scan the blockchain successfully once, before the HDD_optimization branch was merged, with just one wallet.
 
After the sync, I imported several more wallets and the rescan time was reported at 2 weeks. During several attempts at a complete rescan, and switching to the HDD_optimization branch and then back to the 0.93_bugfix branch, I've been unable to get a complete index of the blockchain.

Maybe one or more of my wallets is triggering a bug?

Lol found it in the op

https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.92.99.2-testing_winAll.exe

See with etotheipi, I don't have the binaries.