Armory 0.96.2 is out (SegWit enabled)

[bobbyfisher]

Okay goatpig, thanks so much.

The scanning is so much quicker !  Truly amazing.

Best wishes

[goatpig]

Thanks for your hard work, Armory is running very smooth and efficient, but I'm still getting into a RPC connection loop with Armory 0.96.2 when bitcoind is too many blocks behind. Armory can't display via GUI the current state and every 5 sec. a connection established notification is thrown. As a work around I'm letting Core fully sync and start Armory afterwards.

Kind regards,
Mr.Vice

I'm aware of this, will look at it for .3, maybe.

Would 8000 be "enough" for now or would you recommend more?

I'm not familiar with fine tuning this metric, I just know more is better. If you're concerned about optimal values and diminish returns, ask Core directly.

I am checking the new segwit feature, but something seems to be wrong.
If I try to send from a segwit address to a segwit address, the fees are higher than normal.  I set the fees for example to 80 S/B, and the calculated value will be 111 S/B.  With normal transactions this does not happen.  Why?
I made a screenshot.
(https://i.imgur.com/xyp8UUq.png) (FORUM: disabled on this page for security.)

What matters is the final fee, not the s/B rate, which does not reflect the discount. In your case, check that your SW tx has change or not. Then play with the adjust fee checkbox.

And why cant it fetch the fees from the node?

Your RPC is down.

[skyhawk]

I am checking the new segwit feature, but something seems to be wrong.
If I try to send from a segwit address to a segwit address, the fees are higher than normal.  I set the fees for example to 80 S/B, and the calculated value will be 111 S/B.  With normal transactions this does not happen.  Why?

Transaction fees are calculated differently for SegWit transactions. I'm not going to get into all the details, but look up "Block Weight". I presume Armory will receive a UI update in the future to properly reflect this, but there is currently a disconnection between "Satoshis/Byte" and "Satoshis/Effective Byte"

Specifically, you are specifying the actual Satoshi/Byte with your fee, but with the SegWit discount your "effective" fee is the larger value.

[calibra]

I am checking the new segwit feature, but something seems to be wrong.
If I try to send from a segwit address to a segwit address, the fees are higher than normal.  I set the fees for example to 80 S/B, and the calculated value will be 111 S/B.  With normal transactions this does not happen.  Why?

Transaction fees are calculated differently for SegWit transactions. I'm not going to get into all the details, but look up "Block Weight". I presume Armory will receive a UI update in the future to properly reflect this, but there is currently a disconnection between "Satoshis/Byte" and "Satoshis/Effective Byte"

Specifically, you are specifying the actual Satoshi/Byte with your fee, but with the SegWit discount your "effective" fee is the larger value.

Thanks for the explanation.  For me it was confusing, because I set it for 80 and I see actually 111, which let me think this transaction will be more expensive.  It would be great, if the block weight was displayed, and it would actually say, you save x S/B this way. 

[alomar]

upon sending of a successful tx, what does this comment mean?:  ***Chained ZC***

[markle]

First time Poster !
As 0.96.2 is not yet available for Mac I upgraded to 0.96.1 on OSX 10.11.6. (Core 0.14.2) .Originally it gave an error about the versioning but I fixed that with droark's 'brew' suggestion but now it will not open the Thread and is indicating 'closing unexpectedly'. The Security is unlocked in System Preferences and it does not seem to be writing to the armorylog file. Any advise would be appreciated, Thank you!


System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _CppBlockUtils.so                0x000000010520d562 void CryptoPP::GetUserKey<unsigned int>(CryptoPP::ByteOrder, unsigned int*, unsigned long, unsigned char const*, unsigned long) + 450
1   _CppBlockUtils.so                0x00000001052811e5 CryptoPP::Rijndael::Base::UncheckedSetKey(unsigned char const*, unsigned int, CryptoPP::NameValuePairs const&) + 197
2   _CppBlockUtils.so                0x00000001052363a4 CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(unsigned char const*, unsigned long, unsigned char const*, unsigned char const*) + 196
3   _CppBlockUtils.so                0x00000001052361a2 CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(bool, unsigned char const*, unsigned long) + 450
4   _CppBlockUtils.so                0x0000000104fc7690 SecureBinaryData::GenerateRandom(unsigned int, SecureBinaryData) + 80
5   _CppBlockUtils.so                0x00000001050089d3 BlockDataManagerConfig::BlockDataManagerConfig() + 467
6   _CppBlockUtils.so                0x000000010516c984 _wrap_new_BlockDataManagerConfig(_object*, _object*) + 68
7   org.python.python                0x00000001002febd0 PyEval_EvalFrameEx + 30112
8   org.python.python                0x00000001002f72a4 PyEval_EvalCodeEx + 2100
9   org.python.python                0x000000010027f78b function_call + 363
10  org.python.python                0x00000001002586f3 PyObject_Call + 99
11  org.python.python                0x0000000100266848 instancemethod_call + 232
12  org.python.python                0x00000001002586f3 PyObject_Call + 99
13  org.python.python                0x00000001002b886f slot_tp_init + 175
14  org.python.python                0x00000001002b4a2b type_call + 347
15  org.python.python                0x00000001002586f3 PyObject_Call + 99
16  org.python.python                0x00000001002fed10 PyEval_EvalFrameEx + 30432
17  org.python.python                0x00000001002f72a4 PyEval_EvalCodeEx + 2100
18  org.python.python                0x00000001002f6a66 PyEval_EvalCode + 54
19  org.python.python                0x0000000100317721 PyImport_ExecCodeModuleEx + 241
20  org.python.python                0x000000010031a7eb load_source_module + 1051
21  org.python.python                0x000000010031a26f import_submodule + 271
22  org.python.python                0x0000000100319cf8 load_next + 280
23  org.python.python                0x0000000100318d0e PyImport_ImportModuleLevel + 1214
24  org.python.python                0x00000001002f1fd7 builtin___import__ + 135
25  org.python.python                0x00000001002586f3 PyObject_Call + 99
26  org.python.python                0x00000001002fcfc1 PyEval_EvalFrameEx + 22929
27  org.python.python                0x00000001002f72a4 PyEval_EvalCodeEx + 2100
28  org.python.python                0x00000001002f6a66 PyEval_EvalCode + 54
29  org.python.python                0x0000000100317721 PyImport_ExecCodeModuleEx + 241
30  org.python.python                0x000000010031a7eb load_source_module + 1051
31  org.python.python                0x000000010031a26f import_submodule + 271
32  org.python.python                0x0000000100319cf8 load_next + 280
33  org.python.python                0x0000000100318d0e PyImport_ImportModuleLevel + 1214
34  org.python.python                0x00000001002f1fd7 builtin___import__ + 135
35  org.python.python                0x00000001002586f3 PyObject_Call + 99
36  org.python.python                0x00000001002fcfc1 PyEval_EvalFrameEx + 22929
37  org.python.python                0x00000001002f72a4 PyEval_EvalCodeEx + 2100
38  org.python.python                0x00000001002f6a66 PyEval_EvalCode + 54
39  org.python.python                0x0000000100325064 PyRun_FileExFlags + 164
40  org.python.python                0x0000000100324b9e PyRun_SimpleFileExFlags + 702
41  org.python.python                0x000000010033c48f Py_Main + 3135
42  Python                           0x0000000100000e58 0x100000000 + 3672
43  Python                           0x0000000100000d71 0x100000000 + 3441

[bitpop]

upon sending of a successful tx, what does this comment mean?:  ***Chained ZC***

It means you're using unconfirmed inputs but I get even when I'm not sometimes

[homsts]

Any ideas?  Can't access my bitcoin since segwit.   

You are missing several build steps. Follow the instructions at https://btcarmory.com/docs/building/

Thanks mate, that did it.
 
(My problem was that I was following the build steps at https://github.com/goatpig/BitcoinArmory/blob/master/linuxbuild/Linux_build_notes.md which seem to be missing pretty much all those other steps...)

It's up and running now.   

Actually, I think I spoke too soon...  Armory's been sitting with no progress on Preparing Databases and Scan Transaction History progress indicators for over 12 hours!

That can't be right...does anyone know if this is a known issue?  Thx!!

Hi Everyone...  I don't want to keep nagging about this, but I still cannot access my Amory wallet -- not since the segwit thing!  I've done all the steps to build successfully as I've indicated above, but Armory just sits forever on Preparing Databases and Scan Transaction History without making any headway.

It would be most useful to be able to get at my bitcoins...

Please help someone if you've seen this before.

[homsts]

Any ideas?  Can't access my bitcoin since segwit.   

You are missing several build steps. Follow the instructions at https://btcarmory.com/docs/building/

Thanks mate, that did it.
 
(My problem was that I was following the build steps at https://github.com/goatpig/BitcoinArmory/blob/master/linuxbuild/Linux_build_notes.md which seem to be missing pretty much all those other steps...)

It's up and running now.   

Actually, I think I spoke too soon...  Armory's been sitting with no progress on Preparing Databases and Scan Transaction History progress indicators for over 12 hours!

That can't be right...does anyone know if this is a known issue?  Thx!!

Hi Everyone...  I don't want to keep nagging about this, but I still cannot access my Amory wallet -- not since the segwit thing!  I've done all the steps to build successfully as I've indicated above, but Armory just sits forever on Preparing Databases and Scan Transaction History without making any headway.

It would be most useful to be able to get at my bitcoins...

Please help someone if you've seen this before.

UPDATE: I think I found the issue...  a tail of the exported log file under /root/.armory/ had

-ERROR - ...DB version mismatch. Use another dbdir!

According to google this seems to be due to having moved past the version 0.95 level from an earlier version.  As per someone else's experience with this I renamed the .../databases folder out of the way and on the next start Armory seems to be making headway.  I don't know if this is documented somewhere, but I didn't happen to see it...perhaps it would be better for the Armory startup to simply rename incompatible db folders out of the way itself and rebuild when necessary instead of having the interface silently failing with no apparent reason...?

[naska21]

0.96.1. RCA2.

You are fine

And one more question. Should  dbcache be set in bitcoin.conf to speed up synchronization? I have 16 Gb RAM. so arguably I can set dbcache=4000. Will it help?

If can afford to feed your node more RAM, you are better off. dbcache goes in bitcoin.conf indeed.

Would 8000 be "enough" for now or would you recommend more?

I set down dbcache=4000 into bitcoin.conf and got a bit faster sync. You may experiment yourself with the settings for this parameter.

[johnlu]

What do I need to do to start generating SW addresses to receive payments?

I'm using Bitcoin-0.14.2 UASF SegWit 1.0 until Bitcoin Core 0.15 is released.

[johnlu]

What do I need to do to start generating SW addresses to receive payments?

I'm using Bitcoin-0.14.2 UASF SegWit 1.0 until Bitcoin Core 0.15 is released.

I just figure out how to do it. It was easy :-)

[markle]

Can someone tell me when 0.96.2 for mac may be coming out. I am hoping this will fix my issues with 0.96.1, Thanks for any reply

[johnlu]

Are you going support sweeping from compressed addresses?

[goatpig]

Can someone tell me when 0.96.2 for mac may be coming out. I am hoping this will fix my issues with 0.96.1, Thanks for any reply

Will probably just be one for 0.96.3

[goatpig]

Are you going support sweeping from compressed addresses?

For the new wallets, not the legacy stuff.

[markle]

Good news, Thank you for the news on 0.96.3 for mac

[johnlu]

For the new wallets, not the legacy stuff.

So, if I create a new wallet right now with 0.96.2, I will be able to sweep compressed privkeys. Won't I?

Will this also work with import compressed privkeys?

Thanks goatpig!! :-)

[goatpig]

For the new wallets, not the legacy stuff.

So, if I create a new wallet right now with 0.96.2, I will be able to sweep compressed privkeys. Won't I?

Will this also work with import compressed privkeys?

Thanks goatpig!! :-)

No, this stuff only acts as a proxy to interface the python wallets with the new signer. It does not touch private assets. What you want is for 0.97.

[Rothbart]

I'm totally new to Linux, and have no idea how to install the offline version of Armory 0.96.2 on my signing laptop.

I'm running Ubuntu 16.04, and have downloaded the 64bit Offline Ubuntu/Debian files from the Armory website - could someone please guide me through the installation process (total newb on Linux!)

Thanks!