Armory 0.96.3 released

[skyhawk]

I've anonymized this log output -- let me know if you need the un-anonymized output, or if you need to see the entire logfile rather than the output from the troubled period.  I'd want a confidential way of getting that to you.

https://pastebin.com/AEtpcSHM

The transaction had 3 Segwit inputs, and one Segwit output (change) and one legacy address output.

Ignore the errors at the top -- I had an issue with the flashdrive, after I realized this and used a different drive I was able to save/sign/broadcast the transaction normally.  I was never able to make RBF work -- no errors or crashes, Armory just didn't do anything when I clicked on "Bump fee" on the context menu.

[goatpig]

I'd want a confidential way of getting that to you.

You can GPG me the thing at the email of my github repo.

This is the pubkey for emails (don't use the offline signing key registered to the same email. This is for offline release signing only):

Code:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQINBFXrA7sBEACyM7MpPE9+H+7YJ94kAu/JZMajOjJaWnw4pb4oiKBu2yMqQQpv
EnRG0t7Qpx/xw+/5bkvyszs9c/Rf9jnSFn7bMEjOwk+cVRIIkhtOG2p2/ZV0d8mw
v5bGTMBIxAhTDY371PzcW42aT+CNEGxeLThHuDauHWVkWxLnYlVabs3oZIBZR2y0
YtVTPSYgI5/XYEQLDze4uwpQuZsvnsCa5doCmX+iJURyUJtFTY3GW/Dx/XqWtQfu
PzRJSGZgxaO40+zOskmbjMerVSjXjEQZlMwzwjB0TR/8Zhu94f1Q98E8W4F4gRXo
X+gcLe0U+zD8rLb7lP99auEw3z8O7Nmxi9sjRN4PoeHB2isshM02j/iL+7qeKpvG
fqZg1yU3Pi4hPqictQGhEpekk/3FxuGWNX5V/PUTeqjfc0aHaYrfRG9ESW59OYnf
QOswdLzrnxyAlmX3cYWOQp4c6vsdbmCMAE4SMhGhIZL4NhxeSoOARR4eB2PNlvIs
u0dCoA6TJLUVVryp0SqnOV5UfUtxCIfyqquYiE5HUFwz418HAVWg+oPEBWp83pp7
kroDgvGF55Q58ZV9Jcx4vHLNFrlo1bVlCY7IZDdFfVJ6scAgiZGcTY+/M5skcaTo
ean9bER4QZ3F6eE+7P9j1p3dPa4Swwy5GQ89+EE3BUYH3kO3F7vXK/pDDQARAQAB
tCJKb2huIERvZSA8bW9vdGhlY293bG9yZEBnbWFpbC5jb20+iQI5BBMBAgAjBQJV
6wO7AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQIvAz3luFh6JFHw/9
FjT9r2ifgQKbVCoKUzzWGBJ6J5iUTqBClcUXg0DEXa4kCZf9zfCjVL/Cfc5vxPus
WK4f1PT/0Hr0mJBbxTz1yhiePd8zwOfoDVvc8OCPR1FgJRZSItGKl4x3KDWPan76
hrWQyRQTsJ8YLgyzFvkvXhnhsLyY4eTuE3dqlKzWL5Mez+pkvOuYkn+eK2vpC4nK
RzqnN2Okyuu0k6mbnFqxsMevu/IaK6KN9fO5MqIJSLbzqNogUMetyuuXCv80Hw5g
BwrZKQQYhSXZTDAXYBZQ5QdDkcl3ALR+qMBN4ttoQaihJpLPBfdYo2CxgAD+tBjr
/F2YOlZvCCPZFxomncFGXANOQop2h/pRjR88KhLZEYPgob4OsZbbujsZdPJmTwx1
rBvrdEj72Y8PLqtCXM7pze6NtOUbz9qwJc0CXoODHQE7n9ZIkyAp15kzGNEDuN+9
a2aavzJU8KsbRhJ4OMokN6lgsyxfwIqeAZg95dz5fSDg7mSJjBoArlo5kX5s3KDl
QyFkq7pTuVuGer7v2XxATbXt95HrIQzUP8YO0j8Z78xNbHsvwTafmWD9SEyl/Vdu
aECpvXkJ80DPnHsC7L98Dx7snrhABlFqe1hRYThN/5k0Dp7EUI4ETG336QhbmKDN
72XH0gz78x+0RzgFXN5h1wndeyV6SbRM1jpv5Jvfw3e5Ag0EVesDuwEQAMEuHi4f
OdE5dOD9Nb91ftiVrblySbHGjkWrJRgJiUo+jWLsJR1ykPoprNrsvJmbRXs7+tNl
mvDXc9Rd45qbdzpL9Qwsjvhinnw9BGzawivJ08RfrYv86QW6ABu7TJVEy1qKMuK9
Y/yhMe7+DkYn+xACL2alHefdpGYJbCIq1YbAV2hU8+bS52rr5dQyvsvv4NArqKmE
GJiVN+mXksnVtgXvYfhO5Jn/i72WVWYLKpA1JxcluVXDGC6ptn/lJERG9oZsACdU
+t043Poitcrz9jimQD/RRWk9N6X372ys4aeVuVrTl51chOkuyJec/D7PCyxN35P+
I8FSgdtCL3iDl+UdEm3IDXvr4+KXYnJgzCZu3+bV9xwVj6adHf8tOnbAM4yEwnWz
ihZLQu8RTXAGpx0KKVkyFdhdaGTLXntXmLSJSEnmhGYuNKmM9B5d3cklmQ8y9Rqs
ZI1QDD+K74RWeKYlxRDJj29Aezu+W53m5Ol3CkXkEC6ClzAV2JHcFn1kgBaZyc1+
p/XSoSgInwGB+X/aD64dxEgeEuK6uTv/sQMXnWbJLT8XlyHozUO4E23OPU3b9Ssg
keS4ZiPBNXrZPKyqHMxW1J/4HP4jI5aR18jopMO7VTyH8uIt6WYeR540LCSnFCaP
wQv8V4k+Ga3uj0ITEEjCU4IQqt4ByLj5ajkfABEBAAGJAh8EGAECAAkFAlXrA7sC
GwwACgkQIvAz3luFh6Kt5hAAqi+B8Ae1rZOP5SR/ZyjXbB42DUan/R5gmHdi7AIt
3vTKWXJQwFT6Jxy5rS22vwJVd/azi0OxdHSpasqCV45I9oq1ES3//8yOvzhb3d02
7cuh8LTN2iOQgcqjKI8MYMFzP2z7cu4CGYj1wJ2X4L8QbZXA2irzlVT2C6SJ5/Ow
zHJyBCSG3ZkRYUkuIAadK/gZ7hJaDMlkiuvoR1s2SaYm4hTeC0viTDGJFJ9+ReM3
jzEfP8wn0k/95SqFRgMv+38aem6Y1XdU4LHtBGf+3TGrjwPrw2xPmpUXX7tl+6vw
s+60wem8B/8+WCq+11ZLPRdFvqePAQVQolbEVaH8BGHTsQ/wX+L1W8myimkYF4Iq
OTf9wRnfCn/yYZYWwN1UqFsfsRoPKmcY5frIYVV/TnZn9DVfUPE5OKHvR61HglaH
E9aQONQe3u1ZGMmOnvFhFiKTvKRVQgpp4/QoQdptNscU7jB0F2VMOWsfU59u1vWo
phmWZ68P1h/0VgAtqZHcNLmqbrqIn9V9mbPc91yVWhYyoBBlUm9fgXR0pqSi+gGe
5LZTNGd4VhyfETbSAGrKJB7JblIj+dfjcCU2wE87nQAycP569h9dvTPt7huSUFIy
E0Kp1V93yAEr4+UiiheJuNNEPz0rPIDBDVfdP9JH95G2ADLbEUYQ7fxU5gTBMs4+
QdU=
=fgZn
-----END PGP PUBLIC KEY BLOCK-----

[goatpig]

DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x00000000074EE1B0> >

Is your DB running? Do you have any Python in you and what OS do you use?

[skyhawk]

Armory is running on Windows.  It's connected via http to ArmoryDB running on an Ubuntu machine.

This Windows install does have a functioning install of Python 2.7.14

[goatpig]

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).

[TierNolan]

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

[sconklinbtc]

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

[goatpig]

It's not detecting your node.

[sconklinbtc]

It's not detecting your node.

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.

[RustyRussell]

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.

[goatpig]

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

[RustyRussell]

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

Yep.  Will try downgrading...

[goatpig]

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.

[RustyRussell]

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

Yep.  Will try downgrading...

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

[goatpig]

Yeah you want .2 or RC1

[RustyRussell]

Yeah you want .2 or RC1

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

[jojo69]

Greetings goatpig

I recently read in the bitcoin wiki

Armory deterministic wallet

Armory has its own Type-2 deterministic wallet format based on a "root key" and a "chain code." Earlier versions of Armory required backing up both the "root key" and "chaincode," while newer versions start deriving the chaincode from the private key in a non-reversible way. These newer Armory wallets (0.89+) only require the single, 256-bit root key. This older format is intended to be phased out in favor of the standard BIP0032 format. [3]

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

[goatpig]

Nothing is ever getting phased out.

[Armory non geek]

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.

[jojo69]

Nothing is ever getting phased out.

Unequivocal and to the point, thank you.

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