Pages:
Author

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

newbie
Activity: 7
Merit: 0
December 30, 2016, 07:06:46 PM
#89
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?
legendary
Activity: 3766
Merit: 1364
Armory Developer
December 30, 2016, 04:28:55 AM
#88
Any chance of a 32-bit version 0.95.1?

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.
member
Activity: 131
Merit: 29
December 30, 2016, 04:27:28 AM
#87
Any chance of a 32-bit version 0.95.1?
legendary
Activity: 3766
Merit: 1364
Armory Developer
December 29, 2016, 06:04:47 PM
#86
Question: is there anyone doing QA on the new 95.1 OSX binaries?
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.

I'm facing a string concatenation error when armory tries to load on this machine. Am unsure if it's my system or 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.

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

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?

Next version.
sr. member
Activity: 449
Merit: 251
December 29, 2016, 03:58:07 PM
#85
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?
full member
Activity: 159
Merit: 100
December 29, 2016, 02:20:56 PM
#84
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:
Code:
env | grep -i utf
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.
newbie
Activity: 7
Merit: 0
December 29, 2016, 01:24:57 PM
#83
I should note this same machine was running armory on 93.3 fine... using the new 95.1 binary is what no longer works...
staff
Activity: 3458
Merit: 6793
Just writing some code
December 29, 2016, 12:40:35 PM
#82
Question: is there anyone doing QA on the new 95.1 OSX binaries?
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.

I'm facing a string concatenation error when armory tries to load on this machine. Am unsure if it's my system or 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.
newbie
Activity: 7
Merit: 0
December 29, 2016, 08:51:10 AM
#81
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? 
legendary
Activity: 1932
Merit: 2077
December 27, 2016, 05:28:35 AM
#80
New procedure:

Code:
$ head -4 sha256sum.asc.txt | tail -1 | sha256sum -c     or    sha256sum  -c sha256sum.asc.txt armory_0.94.1_amd64.deb 2>&1 | grep OK

$ wget https://raw.githubusercontent.com/goatpig/BitcoinArmory/master/PublicKeys/goatpig-signing-key.asc

$ gpg --import goatpig-signing-key.asc

$ gpg --verify sha256sum.asc.txt
gpg: Firma eseguita dom 22 nov 2015 07:34:46 CET
gpg:                con RSA chiave 8C5211764922589A
gpg: Firma valida da "goatpig (Offline signing key for Armory releases) " [sconosciuto]
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata.
gpg:          Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale chiave primaria: 745D 707F BA53 968B DF63  AA8D 8C52 1176 4922 589A

or just take a look at:   https://btcarmory.com/docs/verify
newbie
Activity: 2
Merit: 0
December 26, 2016, 08:11:23 PM
#79
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

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?
staff
Activity: 3458
Merit: 6793
Just writing some code
December 25, 2016, 06:38:13 PM
#78
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
newbie
Activity: 2
Merit: 0
December 25, 2016, 06:23:44 PM
#77

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.
legendary
Activity: 3766
Merit: 1364
Armory Developer
December 16, 2016, 07:20:48 AM
#76
The address has everything he needs. If he uses that addresses, it will result in a nested SW output on the network.
legendary
Activity: 2912
Merit: 1060
December 16, 2016, 07:16:42 AM
#75
Quote
But what if he does send segwit and receiver isn't expecting it?

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.

Oh ok, then how would he send a segwit? Do I need to give him other info than a 3* address?
legendary
Activity: 3766
Merit: 1364
Armory Developer
December 16, 2016, 07:15:14 AM
#74
Quote
But what if he does send segwit and receiver isn't expecting it?

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.
legendary
Activity: 2912
Merit: 1060
December 16, 2016, 06:02:08 AM
#73
how does the sender know whether to send std outputs or SW outputs to that p2sh address?
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.

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?
legendary
Activity: 3766
Merit: 1364
Armory Developer
December 15, 2016, 07:27:27 PM
#72
how does the sender know whether to send std outputs or SW outputs to that p2sh address?

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.
staff
Activity: 3458
Merit: 6793
Just writing some code
December 15, 2016, 07:15:02 PM
#71
how does the sender know whether to send std outputs or SW outputs to that p2sh address?
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.
member
Activity: 178
Merit: 10
December 15, 2016, 06:38:05 PM
#70
So how do we tell senders?
You give the sender your p2sh address. That p2sh address will have as its "redeemscript" the segwit script. But the sender does not need to know, nor should they care, what the script of that p2sh address. For all they know, it could be a normal multisig; it does not matter to them. All the sender needs to know is that they are sending to a p2sh address and should send to it as normally done with p2sh addresses.

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