Topic: Armory 0.96.3 released - page 4. (Read 15626 times)

..happened twice again:


At least in this cae, it seems like my machine was offline (unrelated to armory) and went online (I have to pull the ethernet cable once in a while). That's why it found the blocks so fast.

Cheers,

Ente

Yes please! :-)

Ente

Can I ask you a few questions about your DB usage and experience in PMs?

Tonight, apparently ArmoryDB crashed. This happened once before, months ago. Both times on 0.96.3.
This is what I got in logs:
A simple "service armorydb {stop-start}" fixed it (I had to stop it, only a start didn't suffice).

It's a FIY only, it's no hassle for me, and eventually I'll update to 0.96.4 anyway.

Cheers,

Ente

Unequivocal and to the point, thank you.

I suspected as much.  Your dedication to this project has earned my enduring respect sir.

TY for your assistance on this question which I think I have now posted to the correct thread:

Now updating a friend's Win 10 computer, which formerly had Armory 0.93.3 and an old Bitcoin core database.  Both of them fully deleted and scrubbed.  


Installed Armory 0.96.3 to his Win 10 off line computer, and also to his on line desktop (Win 10).  Installed the new Bitcoincore 0.15.1
database to the friend's desktop.  Per a successful summer 2017 experiment (re Armory 0.96.0.4 with bitcoin core 0.14.2) I let the BC core 0.15.1 fully sync itself before attempting to sync with Armory 0.96.3.  

Armory 0.96.3 seems to recognize that the BCcore 0.15.1 database might be present, but does not sync properly to the 0.15.1 data base.  

All paperbackups successfully installed into the off line Armory 0.96.3 and watching only copies also indicate correctly to the On Line Armory 0.96.3.  The watching only On Line wallets have been identified as "This Wallet Is Mine" under Wallet Properties (and where the On Line Armory 0.96.3 now correctly indicates Offline Security for each respective "Watching Only copy").  Balance continues to indicate as zero for each of those wallets.  

Is there some other procedure needed to be performed for those wallets to indicate their balances and for Armory 0.96.3 to be fully synced to core datebase 0.15.1  

Each time Armory 0.96.3 is activated it does not update the BCcore 0.15.1 database (which only updates when Armory is closed, and BCcore is separately opened)

TY for your assistance.

Nothing is ever getting phased out.

Greetings goatpig

I recently read in the bitcoin wiki


Should users with older format cold storage paper wallets be concerned about not being able to access their coins due to this "phase out"?

Didn't work.  Moved the bug to RC1 thread.

Yeah you want .2 or RC1

0.96.1 has same problem, different error:

(ERROR) TxFrames.py:834 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 828, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2682, in signUnsignedTx
    ustx.createAndInsertSignatureForInput(idx, addrObj.binPrivKey32_Plain)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2646, in createAndInsertSignatureForInput
    ustxi.createAndInsertSignature(self.pytxObj, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1398, in createAndInsertSignature
    derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1355, in createTxSignature
    raise SignatureError('No PubKey that matches this privKey')
SignatureError: No PubKey that matches this privKey
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 828, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2682, in signUnsignedTx
    ustx.createAndInsertSignatureForInput(idx, addrObj.binPrivKey32_Plain)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2646, in createAndInsertSignatureForInput
    ustxi.createAndInsertSignature(self.pytxObj, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1398, in createAndInsertSignature
    derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1355, in createTxSignature
    raise SignatureError('No PubKey that matches this privKey')
SignatureError: No PubKey that matches this privKey

Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 828, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2682, in signUnsignedTx
    ustx.createAndInsertSignatureForInput(idx, addrObj.binPrivKey32_Plain)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2646, in createAndInsertSignatureForInput
    ustxi.createAndInsertSignature(self.pytxObj, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1398, in createAndInsertSignature
    derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1355, in createTxSignature
    raise SignatureError('No PubKey that matches this privKey')
armoryengine.ArmoryUtils.SignatureError: No PubKey that matches this privKey

You really want to use the RC for 0.96.4. As for 0.96.3 you can operate it but you have to pick the signer manually, as the default signer detection is botched.

Yep.  Will try downgrading...

What version are you using? 0.96.3 has some signer issues.

Hmm, my vanity-address wallet problems continue

I selected a single UTXO and tried to send MAX with manully-set 135 sat/byte feerate:

Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
armoryengine.ArmoryUtils.SignatureError: Invalid signature while preparing final tx

 (ERROR) Transaction.py:1488 - Signature in USTXI is not valid
(ERROR) Transaction.py:2634 - Attempted to prepare final tx, but not all sigs available
(ERROR) TxFrames.py:876 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
SignatureError: Invalid signature while preparing final tx
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
SignatureError: Invalid signature while preparing final tx

Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
armoryengine.ArmoryUtils.SignatureError: Invalid signature while preparing final tx

It then (I think it was after this) started scanning.  After an hour or so, same error.

This was the encrypted wallet I removed then restored, trying to get it to see that those "Right click to RBF" txs had actually gone through.

I must've just been trying to fast while it was doing the initial sync, as it's now scanning for transactions and it's detected as I can select segwit now. Thanks for the quick reply.

It's not detecting your node.

I've just done a fresh install of Armory 0.96.3 on a fresh install of Windows 10 and when I go to change my default address type to segwit, like I previously had before I needed to reinstall windows, the option for P2SH-P2WPKH addresses is greyed out. I'm using this in expert mode as well as running armory as administrator, so I'm unsure what is preventing me from being able to select segwit. Any help to point me in the right direction to correct this would be greatly appreciated. I'm also using bitcoin core 0.15.1 if that helps.

https://imgur.com/a/FElM4

I realize that in this is fixed in 0.96.4, but I just want to confirm that my backups are ok.  I would rather not use a RC for an actual wallet.

I generated an M of N backup and then printed out the fragments.  When I test the backup, it gives the wrong fragment id.

To confirm, the way to verify the backup is

- enter all N fragments (rather than just M of them)
- say "Yes" when it asks if the fragment id matches (even though it doesn't)
- The actual check is to make sure that the Wallet id matches after reconstruction

You could help me debug this by writing some lines of Python in there, but this is harder to achieve with Windows than Linux. If you want to process further, email me. I'll be away this weekend btw, so that may take a while.

Ultimately, if you want to speed up that one tx regardless of figuring out what's going with RBF, you could CPFP it (assuming it has change).