Armory 0.96.2 is out (SegWit enabled) - page 4.

naska21

hero member

Activity: 1358

Merit: 635

Quote from: RoadStress on September 01, 2017, 05:27:11 PM

Quote from: goatpig on August 30, 2017, 08:50:34 PM

Quote from: naska21 on August 30, 2017, 05:56:41 PM

0.96.1. RCA2.

You are fine

Quote

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.

homsts

newbie

Activity: 12

Merit: 0

Quote from: homsts on September 04, 2017, 01:09:16 AM

Quote from: homsts on August 30, 2017, 05:22:16 PM

Quote from: homsts on August 30, 2017, 02:38:40 AM

Quote from: achow101 on August 30, 2017, 02:07:23 AM

Quote from: homsts on August 30, 2017, 02:04:00 AM

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

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

homsts

newbie

Activity: 12

Merit: 0

Quote from: homsts on August 30, 2017, 05:22:16 PM

Quote from: homsts on August 30, 2017, 02:38:40 AM

Quote from: achow101 on August 30, 2017, 02:07:23 AM

Quote from: homsts on August 30, 2017, 02:04:00 AM

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

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.

bitpop

legendary

Activity: 2912

Merit: 1060

Quote from: alomar on September 02, 2017, 07:59:22 PM

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

markle

newbie

Activity: 9

Merit: 0

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(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::Reseed(unsigned char const*, unsigned long, unsigned char const*, unsigned char const*) + 196
3 _CppBlockUtils.so     0x00000001052361a2 CryptoPP::AutoSeededX917RNG::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

alomar

member

Activity: 178

Merit: 10

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

calibra

newbie

Activity: 5

Merit: 0

Quote from: skyhawk on September 01, 2017, 08:14:37 PM

Quote from: calibra on September 01, 2017, 05:50:40 PM

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.

skyhawk

member

Activity: 83

Merit: 10

Quote from: calibra on September 01, 2017, 05:50:40 PM

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.

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: Mr.Vice on September 01, 2017, 01:11:22 PM

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.

Quote

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.

Quote

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.

Quote

And why cant it fetch the fees from the node?

Your RPC is down.

bobbyfisher

newbie

Activity: 30

Merit: 0

Okay goatpig, thanks so much.

The scanning is so much quicker ! Truly amazing.

Best wishes

calibra

newbie

Activity: 5

Merit: 0

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
And why cant it fetch the fees from the node?

Thanks

RoadStress

legendary

Activity: 1904

Merit: 1007

Quote from: goatpig on August 30, 2017, 08:50:34 PM

Quote from: naska21 on August 30, 2017, 05:56:41 PM

0.96.1. RCA2.

You are fine

Quote

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?

Quote from: goatpig on August 30, 2017, 10:57:07 PM

Edit:
Ah, I see what you did wrong. You have to manually pick the C++ signer for it to work atm. Ugh, this is coming back to bite me in the ass, isn't it?

How about a more visible sign like "C++ Signer - SegWit Compatible" or something like that?

Mr.Vice

member

Activity: 96

Merit: 10

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

PRab

member

Activity: 98

Merit: 10

Upgraded, deleted old databases, and am now running without issue!

bitpop

legendary

Activity: 2912

Merit: 1060

Quote from: goatpig on August 31, 2017, 10:13:16 PM

Quote from: bitpop on August 31, 2017, 08:45:25 PM

When is the offline armory supposed to be used? I used to just use the same version in my offline machine. What's changed?

Offline packages just mean the archives contains all the relevant dependencies to setup Armory on a fresh install of the target OS. The Windows 32bit offline package has no DB binary, so people still using that platform don't get the impression that Armory is now a thing on such setup.

I get it now thanks.

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: bitpop on August 31, 2017, 08:45:25 PM

When is the offline armory supposed to be used? I used to just use the same version in my offline machine. What's changed?

Offline packages just mean the archives contains all the relevant dependencies to setup Armory on a fresh install of the target OS. The Windows 32bit offline package has no DB binary, so people still using that platform don't get the impression that Armory is now a thing on such setup.

bitpop

legendary

Activity: 2912

Merit: 1060

When is the offline armory supposed to be used? I used to just use the same version in my offline machine. What's changed?

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: endpoint on August 31, 2017, 08:46:05 AM

Thank you goatpig, I understand your answer now and everything is working as it should. I haven't used the Unity desktop except for this offline machine and am not finding it very intuitive. Sorry to bother you with a non-Armory problem.

You're not alone, everybody hates it afaik.

endpoint

newbie

Activity: 5

Merit: 0

Quote from: goatpig on August 30, 2017, 08:48:44 PM

They do not reveal anything pertaining to your issue.

Thank you goatpig, I understand your answer now and everything is working as it should. I haven't used the Unity desktop except for this offline machine and am not finding it very intuitive. Sorry to bother you with a non-Armory problem.

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: ?? on ??

Quote from: goatpig on August 30, 2017, 10:49:13 PM

What is the version of your signer?

I'm not sure https://imgur.com/MIFlocz

Your private keys are online? Get on freenode and pm me @goatpig, can't really have a chat on a forum.

Edit:

Ah, I see what you did wrong. You have to manually pick the C++ signer for it to work atm. Ugh, this is coming back to bite me in the ass, isn't it?

Topic: Armory 0.96.2 is out (SegWit enabled) - page 4. (Read 9231 times)