Topic: Armory - Discussion Thread - page 162. (Read 521829 times)

Indeed.  I actually almost sent the tx again, but fortunately I was paranoid enough to actually test - and if I had done it, it would probably have been saved by being a double-spend.

Perhaps when sending a tx failed, the error message should be that the tx "appears to have failed, but please check by waiting to the next block appear (or check in blockchain.info [link to tx]" or something like this.

he's right; you need to fix it asap.

That's an excellent point.  And I didn't mean to suggest the bug was "okay", but simply that it was better than the inverse bug.  I'd still like to find a good way to resolve it... but Armory's mechanism for sending transactions does not make this totally deterministic

I think this could cause some of its own problems, though.  If you have a user that simply trusts what the software tells them (which would be 90% of the normal population if/when bitcoin/armory gets extremely popular, luckily it's much lower while bitcoin is a niche market) they may send coins again if it says that it failed, without even looking at the history or manually checking if it really did go through.

It may be a lower priority bug for the time being, but in the long run, it's something you would want to try to find if at all possible, in my opinion.  But that's just my two cents.  

I'll put this behavior in the category of "undefined."   There's actually a good chance it would go through, unless the transaction being spent was very recent.  I could elaborate, but I don't think it's too important.  I'll apply my same not-sync-detect logic to the sending of transactions to warn the user that they should wait until full synchronization before spending.  It sounds like even if I don't get it right, this is an okay bug to have:  tell the user it didn't work, but it actually did.  Better than telling them it did work when it didn't, and the ensuing confusion...

---

Teaser:  the beta testing version will be out very soon.  I think I just finished the final feature, which is sometimes necessary for restoring very active wallets, both offline and online.  This is mainly for people who are restoring offline wallets from paper backup, where the offline wallet was used more times than the keypool size (100-200).  Since the wallet is offline it, has no way to know how many addresses were used, and will not recognize address 300 in its own wallet.  The mechanism for resolving this has been haunting me for a while -- I want to make it possible for users to extend the keypool, but 98% of the time, they don't need to be bothered with this concept because Armory succeeds silently without input. 

So, I have added it to the "Expert" interface, wallet properties now tells you how many addresses have been generated.  You can click on it, and extend the address pool manually.  If you think you used 1000 addresses in this wallet, put in 1,500 and it will extend the wallet for you.  If you supply a number greater than 1000, it will warn you that computation may take a while (this is another reason to switch to the new BIP 32 wallets -- address "chaining" is much quicker).



As far as I can tell, all my multi-threaded features work -- offline-to-online, rescanning, importing, sweeping, wallet restore, wallet import, all in different modes, etc.  I have to do a final testing pass on everything and then I will compile testing versions.  I can't wait to finally get this thing out there!

Mine got throught.  I was *almost* fully sync'ed, it may have propagated once the client caught up, or it may have propagated immediately despite the error, I don't know.  Before I had found the tx on blockchain.info, the client had caught up.

but i was fully synced.  otherwise the tx wouldn't have gone thru.

Oh, definitely evidence of my own testing bias... I wouldn't ever send a tx before satoshi is caught up, because I know in the back of my head what the result would be.  This is why I need other people to test and find stuff like this

The newest version (which I'm still battling), detects when Bitcoin-Qt is still synchronizing, and pops up a warning.  I should add to the warning that tx will not be broadcast right away, and perhaps add that same detection to the broadcast button to disable the message (or give a different one), when they do this.

I have seen that once, when I broadcasted the tx before the Satoshi client had caught up.  I should of course have reported it, but somehow felt it was only to be expected.

yes, it popped up immediately when i pushed the broadcast button.

Interesting... haven't seen that one before.  Perhaps I just need to bump up the time that Armory that waits before declaring that it failed...

this

You were told it wouldn't broadcast when you created it?  Or when you tried to actually broadcast it (you were able to broadcast it, it showed up on the ledger, but said it failed?)

Bug:  broadcasted a signed offline tx that got sent just fine but Armory had a pop up window that said the tx wouldn't be accepted by the network b/c of lack of a fee. 

Just a quick update... I'm on the absolute verge of the "real" release, with all the features completed for beta.  The issue is that restoring paper backups and importing wallet files, sometimes causes Armory to hang, and I've spent my whole day trying to track it down.  Unfortunately, it's not consistent, so I still haven't even been able to isolate where it's hanging.

On the upside, it hangs after it's done doing the wallet recovery scans, so it's okay once Armory is restarted.  I just can't release beta like that...

When I do find it and fix it, I will go into "pencil's down" mode and focus on testing.  A lot of testing.  And I will need help. 

---

Reposting the downloads for 0.84.1, because I'd still like people to help test that if they can.  I don't know how long it will take to track down this wallet importing, but bugs found in 0.84.1 are still relevant to 0.84.2 and I can fix it before I release.

Armory 0.84.1-almost-beta

Ubuntu/Debian 64-bit (*.deb)
Windows 64-bit (*.msi)
Windows 32-bit (*.msi)

I moved my ~/Library/Application\ Support/Armory directory to a safe place and then reopened Armory and it worked!  It started freaking out about losing the connection to the Satoshi client,  but I think that's just because I opened armory right after waking up my laptop so I was ~50 blocks behind.

And it just crashed.  I guess it must be one of my wallets.  I'll load them one at a time and see what happens.

So I tried just renaming them *.wallet.off, but they all still loaded I'll just move them out of the folder.

Testing my offline wallet first.

EDIT: My offline wallets load, but my wallet that I imported from Satoshi (back when that was a thing) and my encrypted hot wallet both cause a segfault.  I'm going to test them in Ubuntu.

Oh!  What about mempool.bin.  It's possible for that to be corrupt, too.

Because that is such a common cause of crashing, I put logic into 0.84.1 to detect when Armory fails to load more than 3 times, and automatically delete mempool.bin.  Even if that's not the problem, perhaps you can check for me that it is at least detecting it.

(1) There's a new entry in ArmorySettings.txt called "FailedLoadCount".  That should be incrementing every time it crashes
(2) The log file will eventually start reporting " attempts to load blockchain failed.  Removing mempool.bin."  It should happen every time after the third failed load.

Can you at least check for me that it is doing that?  Though, if it is doing that, then it is removing mempool.bin, and there's nothing more for you to try.  So far...

I'll try that in the morning.  Although the wallets load fine (albeit single threaded) with the dev branch.

You know what?  I bet there's a problem with one of your wallets.  One of of them is corrupt, maybe? 

Can you temporarily relocate your wallets out of the .armory directory and then reload?  I bet it will start, then.

It happens right after the blockchain finishes scanning.

This log might be helpful.

I just re-downloaded the blockchain.  Sorry, I didn't save the files, although I do have a time machine backup of them from awhile ago.  The fresh download still crashes.