Topic: Armory 0.95.1 is out - page 6. (Read 12843 times)

So, I just tried 93.3 app version and it loaded up fine.... tried the 95.1 again and it's still no dice... same error each time in the log file, this appears to be something to do with the locale not reporting back correctly which gives back a null value and python cannot concatenate a null value with the first part of the string for the logger function... so it breaks

tried it even on another mac that is 10.12.2; same issues... won't load...

out of pure curiosity, i went to the github releases and downloaded 95.0, verified the signature, and tried that one..... this one loads the application window, but hangs on the scanning transaction history... so now i have 3 apps in my applications dir, named: armory951 armory933 and armory95  -- only the latter 2 will load the app... the 951 version will not load at all... with 933 being the only one that actually works...

any ideas?

the 95.0 version in the dblog.txt file shows this as what i perceive to be the error:

Log file opened at 1483142525: /Users/[REDACTED]/Library/Application Support/Armory/dbLog.txt
-INFO  - 1483142525: (main.cpp:22) Running on 8 threads
-INFO  - 1483142525: (main.cpp:23) Ram usage level: 4
-INFO  - 1483142525: (BlockUtils.cpp:1325) blkfile dir: /Users/[REDACTED]/Library/Application Support/Bitcoin/blocks
-INFO  - 1483142525: (BlockUtils.cpp:1326) lmdb dir: /Users/[REDACTED]/Library/Application Support/Armory/databases
-INFO  - 1483142525: (lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 1483142525: (BlockUtils.cpp:1508) Executing: doInitialSyncOnLoad
-INFO  - 1483142525: (BitcoinP2P.cpp:783) Connected to Bitcoin node
-INFO  - 1483142525: (DatabaseBuilder.cpp:162) Reading headers from db
-ERROR - 1483142525: (StoredBlockObj.cpp:538) buffer is too small: 0 bytes. expected: 106
-ERROR - 1483142525: (BDM_mainthread.cpp:255) BDM thread failed: buffer is too small: 0 bytes. expected: 106
-INFO  - 1483142526: (BDM_Server.cpp:797) registered bdv: 5776646e8dbcfba46b0a
-INFO  - 1483142526: (BDM_supportClasses.cpp:366) Starting address registration process
-ERROR - 1483142526: (lmdb_wrapper.cpp:1205) Block height exceeds DupID lookup table
-ERROR - 1483142526: (lmdb_wrapper.cpp:1419) Headers DB has no block at height: 4294967295
-ERROR - 1483142526: (lmdb_wrapper.cpp:1399) No headers at height 4294967295
-ERROR - 1483142526: (BlockchainScanner.cpp:204) failed to grab block data starting height: 0
-ERROR - 1483142526: (BlockchainScanner.cpp:206) no block data was scanned

Ideally i'd like the 95.1 version to work which is the original problem with the python locale not working....
Is there something that got messed up in the osx build process that made the binaries maybe?

No. If you want an offline signer in x86, you can use all the way back to 0.92 to sign with 0.95. If you want to go online with an x86 system, you should reconsider that plan to begin with.

Any chance of a 32-bit version 0.95.1?

I personally debugged 0.95 on Mac. I believe it was on El Capitan.


Next version.

Ok I installed 0.95.1 and everything is cool, a few hiccups with installing but nothing that couldn't be solved.

I like that I (easily) can manage the sat/b without having to work around and calculate it myself, Thank You Goatpig for that.
Just a simple question, maybe i just missed a setting somewhere. Now I need to press sat/b for every transaction and put the right amount in (chosing between normal or fast on https://bitcoinfees.21.co/). Is there anyway to have sat/b per default selected with a given amount in the settings? Like we can fill in our own default fee per tx?

It works fine on my mac (0.95.1), but I am still on El Capitan.

 However, I know many Macs have problems with all kinds of Linux software because often they set one of the language environment variables wrong.  Try typing this in a terminal:
and look for any variables with a value of UTF-8 or the like.  They should be en_US.UTF-8 or something like that.  A bare value of utf8, UTF8, utf-8 or similar is incorrect and could potentially cause the problem you see.

I should note this same machine was running armory on 93.3 fine... using the new 95.1 binary is what no longer works...

Not particularly. IIRC goatpig does not have a mac to do testing with. There is really only one person who contributes mac stuff for Armory.

AFAIK, Armory does work on Macs. It could be an issue with mac versions, I don't remember what version Armory was last tested on.

Hello,

First off i'd like to thank goatpig for his continued effort & development on this piece of software! It's great that Alan open sourced it and capable minds are continuing the development.  Looking forward to getting this back up and running on a mac laptop here...


Question: is there anyone doing QA on the new 95.1 OSX binaries? I'm facing a string concatenation error when armory tries to load on this machine. Am unsure if it's my system or armory...

Here's the relevant redacted bits from the log file; it will die immediately upon trying to launch the app:


2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1137 - C++ block utilities loaded successfully
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:651 - Executing popen: sysctl hw.memsize
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:651 - Executing popen: sysctl -n machdep.cpu.brand_string
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1247 -
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1248 -
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1249 -
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1250 - ************************************************************
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1251 - Invoked: /Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ArmoryQt.py
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1252 - ************************************************************
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1253 - Loading Armory Engine:
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1254 -    Armory Version        : 0.95.1
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1255 -    Armory Build:         : None
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1256 -    PyBtcWallet  Version  : 1.35
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1257 - Detected Operating system: MacOSX
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1258 -    OS Variant            : 10.10.5
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1259 -    User home-directory   : [REDACTED]
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1260 -    Satoshi BTC directory : [REDACTED]/Bitcoin/
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1261 -    Armory home dir       : [REDACTED]/Armory/
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1262 - Detected System Specs    :
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1263 -    Total Available RAM   : 16.00 GB
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1264 -    CPU ID string         : Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz

2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1265 -    Number of CPU cores   : 8 cores
2016-12-29 08:22 (INFO) -- ArmoryUtils.py:1266 -    System is 64-bit      : True
2016-12-29 08:22 (ERROR) -- Traceback (most recent call last):
  File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ArmoryQt.py", line 44, in
    from armoryengine.ALL import *
  File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/ALL.py", line 8, in
    from armoryengine.ArmoryUtils import *
  File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/ArmoryUtils.py", line 1267, in
    LOGINFO('   Preferred Encoding    : ' + locale.getpreferredencoding())
TypeError: cannot concatenate 'str' and 'NoneType' objects


Which means the getpreferredencoding() method is returning null.... what gives?

This binary was shasum checked & verified


Doing some python sleuthing and tracing back from line 1267 in the utils file, i don't know why this is occurring... it should return back UTF-8 ... see below from a terminal prompt:

Last login: Thu Dec 29 08:17:47 on ttys007
Thu Dec 29 08:36:51 MacBook Pro:~/Desktop/$ python
Python 2.7.9 (default, Dec 19 2014, 21:06:47)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'UTF-8'
>>>

anyone have thoughts or ideas? is the armory app using some weird version of python that is not the supplied or system version? do i need to flag it to use a specific flavor in pyenv or similar? 

New procedure:


or just take a look at:   https://btcarmory.com/docs/verify

Thanks for the tip -- I didn't realize that goatpig had taken over when I posted my original thing.  But since then, I followed the directions on this page:

https://btcarmory.com/docs/verify

and even after importing the new key it doesn't work -- it appears the .95.1 binary is unsigned.  Here's the output now:


h00per@debian-vm:~/Downloads$ sha256sum -c sha256sum.asc armory_0.95.1_amd64.deb
armory_0.95.1_amd64.deb: OK
sha256sum: armory_0.95.1_osx.tar.gz: No such file or directory
armory_0.95.1_osx.tar.gz: FAILED open or read
sha256sum: armory_0.95.1_win64.exe: No such file or directory
armory_0.95.1_win64.exe: FAILED open or read
sha256sum: WARNING: 20 lines are improperly formatted
sha256sum: WARNING: 2 listed files could not be read
sha256sum: armory_0.95.1_amd64.deb: no properly formatted SHA256 checksum lines found


The earlier lines are reasonable -- I didn't download the files for those other versions.  But what's up with the .95.1 file?

Do you have the right key imported? You need to have goatpig's key, found at https://github.com/goatpig/BitcoinArmory/blob/master/PublicKeys/goatpig-signing-key.asc

Just tried to verify signatures for this new build on Debian (downloaded from main Armory site), and no dice.  I wondered if I had screwed something up, so I downloaded 93.3 from the same place and verified that without difficulty.  Both .deb files are in the same directory.  Here's the output of how I did it:


h00per@debian-vm:~/Downloads$ dpkg-sig --verify *.deb
Processing armory_0.93.3_ubuntu-64bit.deb...
GOODSIG _gpgbuilder 821F122936BDD565366AC36A4AB16AEA98832223 1447278319
Processing armory_0.95.1_amd64.deb...
h00per@debian-vm:~/Downloads$


Is .95.1 signed in the same way as the other versions?  If not, how do I verify the integrity of this file?

Thanks.

The address has everything he needs. If he uses that addresses, it will result in a nested SW output on the network.

Oh ok, then how would he send a segwit? Do I need to give him other info than a 3* address?

How would he be doing this?

You at least need to know the public keys of your recipient to craft the output yourself. Neither P2PKH nor P2SH output scripts give you that information. Same with the native SW outputs. The only way you got to do this is by lifting the public keys of your recipients known addresses from the blockchain.

There is no mechanic in the bitcoin protocol to prevent someone from spending coins to whatever script they want, but that's basically the same as black-holing coins at this point. If you are afraid your wallet will do this with your coins, that's not how it's supposed to work at all.

But what if he does send segwit and receiver isn't expecting it? Will you have to redeem it with another wallet to recover it?

You need to understand how bitcoin outputs are constructed and how they are redeemed, particularly P2SH. The whole point of P2SH is to let the recipient determine the redeem script.

A p2sh address specifies that it must always send normal p2sh outputs. There is no need to send a segwit output (and in fact impossible to with p2sh) to a p2sh address. The segwit output is nested as the script of the p2sh address and that is for the receiver to deal with.

how does the sender know whether to send std outputs or SW outputs to that p2sh address?