Ente
Legendary
Offline
Activity: 2126
Merit: 1001
|
|
March 04, 2017, 10:22:18 PM |
|
Should the git submodule update command not produce some delta feedback in respect of the changes ? I got a new prompt with nothing. Do I need to make clean first?
It should. I'm not an expert with submodules though, first time trying it. There are other ways to get the submodules to update with a command from the top most repo: http://stackoverflow.com/questions/1030169/easy-way-pull-latest-of-all-submodulesOtherwise, the "brute force" method is to git pull in the submodule repo. Once I'll more familiar with it I'll update the readme with the most convenient method. No idea why the DB would be already running, I only see that one process running. Anything I can do on my side?
No idea why the DB would be already running, I only see that one process running.
That line just means the client successfully probed the ip:port you gave it for a listening socket and won't start a local DB. Anything I can do on my side?
Do you have some python or C++ in you? EDIT: also please detail your setup. If you dont have any coding in you, I'll make you a separate branch with extra verbose in there for you to paste back here. Sorry for the late reply. Unfortunately no, no developer here. I might identify simple typos after staring half an hour at the code, but that's about it. I'll gladly paste extra-verbose output here. I am running Armory on Debian 8, kernel 4.4.38-11, in a Qubes/Xen VM. Ente
|
|
|
|
droark
|
|
March 04, 2017, 11:37:32 PM |
|
Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees. Your transaction comes with a fee rate of 0.00 satoshi/Byte. This is much lower than the median fee rate of 50 satoshi/Byte.
Are you absolutely sure that you want to send with this fee? If you do not want to proceed with this fee rate, click "No".
Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee.
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 04, 2017, 11:43:36 PM |
|
Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees. Your transaction comes with a fee rate of 0.00 satoshi/Byte. This is much lower than the median fee rate of 50 satoshi/Byte.
Are you absolutely sure that you want to send with this fee? If you do not want to proceed with this fee rate, click "No".
Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee. Can you give me a step by step of how you get to that?
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 05, 2017, 01:38:12 AM |
|
I expect you're aware of this goatpig; Wallet Properties -> Receive Coins button produces (ERROR) Traceback (most recent call last): File "/home/user/BitcoinArmory/qtdialogs.py", line 1550, in getNewAddress if DlgNewAddressDisp(self.wlt, self, self.main, loading).exec_(): File "/home/user/BitcoinArmory/qtdialogs.py", line 2242, in __init__ addrStr = self.addr.getAddrStr() File "/home/user/BitcoinArmory/armoryengine/PyBtcAddress.py", line 161, in getAddrStr raise Exception("Deprecated, get address from mirror wallet instead") Exception: Deprecated, get address from mirror wallet instead
Traceback (most recent call last): File "/home/user/BitcoinArmory/qtdialogs.py", line 1550, in getNewAddress if DlgNewAddressDisp(self.wlt, self, self.main, loading).exec_(): File "/home/user/BitcoinArmory/qtdialogs.py", line 2242, in __init__ addrStr = self.addr.getAddrStr() File "/home/user/BitcoinArmory/armoryengine/PyBtcAddress.py", line 161, in getAddrStr raise Exception("Deprecated, get address from mirror wallet instead") Exception: Deprecated, get address from mirror wallet instead
Fixed
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 05, 2017, 01:39:04 AM |
|
Sorry for the late reply. Unfortunately no, no developer here. I might identify simple typos after staring half an hour at the code, but that's about it. I'll gladly paste extra-verbose output here. I am running Armory on Debian 8, kernel 4.4.38-11, in a Qubes/Xen VM.
Ente
I'll be looking into this soon, sit tight.
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 05, 2017, 09:59:50 AM |
|
- After ~7-8 blocks come in, Armory seems to stop picking up new blocks even though Core keeps chugging along. No messages on the command line. When I close, I have to force quit. The blocks seem to be picked up upon restart.
I've pushed some code that should fix this at least on the db side. Can you observe both client and db, and in particular if the client drops the connection with the db, is the db still fine?
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
March 05, 2017, 12:53:37 PM Last edit: March 05, 2017, 02:30:37 PM by Carlton Banks |
|
I expect you're aware of this goatpig; Wallet Properties -> Receive Coins button produces Fixed Possibly this issue is known/WIP also.... - Click Receive Coins
- Click Address Type
- Select and apply Compressed nested P2SH key
QR code & text remains the P2PKH address. Instead of generating one P2PKH, 100 addresses are generated/displayed, and no compressed P2SH addresses at all. Edit(Edit): A 2nd attempt at creating a compressed nested P2SH worked The compressed P2SH nested keys only appear in Wallet Properties after closing and reopening it (Wallet Properties dialog)
|
Vires in numeris
|
|
|
droark
|
|
March 05, 2017, 06:30:02 PM |
|
Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees. Your transaction comes with a fee rate of 0.00 satoshi/Byte. This is much lower than the median fee rate of 50 satoshi/Byte.
Are you absolutely sure that you want to send with this fee? If you do not want to proceed with this fee rate, click "No".
Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee. Can you give me a step by step of how you get to that? Okay, now that I've played around with it, the real bug is if the amount being sent is really low. If it's >= 0.1 BTC, you're good. If it's <0.1 BTC, the fee is calculated at times but not at others. Here are examples. I'm not sure there's a pattern to this. Some may work at times but not at others, especially once you start putting in values and then trying new values. 0.09 - No fee 0.001 - Fee 0.01 - No fee 0.011 - No fee 0.0111 - Fee 0.021 - Fee 0.02 - No fee 0.020 - Fee
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 06, 2017, 01:24:50 AM |
|
I expect you're aware of this goatpig; Wallet Properties -> Receive Coins button produces Fixed Possibly this issue is known/WIP also.... - Click Receive Coins
- Click Address Type
- Select and apply Compressed nested P2SH key
QR code & text remains the P2PKH address. Instead of generating one P2PKH, 100 addresses are generated/displayed, and no compressed P2SH addresses at all. Edit(Edit): A 2nd attempt at creating a compressed nested P2SH worked The compressed P2SH nested keys only appear in Wallet Properties after closing and reopening it (Wallet Properties dialog) Fixed Update: The fee bug I mentioned earlier (ask for 0.0001 BTC fee, get 0.00011576 BTC) is gone. Still, the Coin Control bug is present. I have to explicitly choose UTXOs, otherwise no fee is selected and Armory warns me that I'm trying to send a Tx with no fees. Your transaction comes with a fee rate of 0.00 satoshi/Byte. This is much lower than the median fee rate of 50 satoshi/Byte.
Are you absolutely sure that you want to send with this fee? If you do not want to proceed with this fee rate, click "No".
Nothing seems to be in the Python (armorylog.txt) or C++/DB (dbLog.txt) logs. If I futz around enough with the UTXO set, I can reset it to the entire set and get a fee. Can you give me a step by step of how you get to that? Okay, now that I've played around with it, the real bug is if the amount being sent is really low. If it's >= 0.1 BTC, you're good. If it's <0.1 BTC, the fee is calculated at times but not at others. Here are examples. I'm not sure there's a pattern to this. Some may work at times but not at others, especially once you start putting in values and then trying new values. 0.09 - No fee 0.001 - Fee 0.01 - No fee 0.011 - No fee 0.0111 - Fee 0.021 - Fee 0.02 - No fee 0.020 - Fee Can't reproduce. This has to do with your utxo mix. Try singling it out with coin selection.
|
|
|
|
droark
|
|
March 06, 2017, 01:48:36 AM |
|
Can't reproduce. This has to do with your utxo mix. Try singling it out with coin selection.
As best I can tell, this happens when a wallet's unspent outputs include P2PKH and P2SH-P2PK. (I'm still playing with P2SH-P2WPKH.) If I choose between P2PKH or P2SH-P2PK, the fee code seems to work fine. Regarding the spend dialog, I have noticed something a bit confusing. The dialog, when showing where the coins will go (including the fee), says it'll spend X BTC from the wallet. This includes change sent back into the wallet. I guess this is technically accurate, since the UTXOs are being spent. I think it'd make more sense if it was just the coins leaving the wallet altogether (i.e., everything but the change address and any wallet addresses receiving coins).
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 06, 2017, 11:44:48 AM |
|
Sorry for the late reply. Unfortunately no, no developer here. I might identify simple typos after staring half an hour at the code, but that's about it. I'll gladly paste extra-verbose output here. I am running Armory on Debian 8, kernel 4.4.38-11, in a Qubes/Xen VM.
Ente
My test worked right away. I'm using a Win8 guest with a Ubuntu 16.04 guest through VBox. As soon as I managed to get nginx through, the client on the host found the server on the guest. For now I'm going to assume something is off in your configuration. For starters, run sanity checks on your server. Next, post your config file and let's go over it.
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3486
Merit: 6824
Just writing some code
|
|
March 08, 2017, 04:41:32 AM |
|
We have managed to get Armory fully translated into another language, German. Please help use test that the translations are working properly by switching to the other languages and by using the German translations to find any missing strings or bugs with displaying the strings or dialog boxes.
Note that some Usermode strings are not translated. That has been fixed and the translations will be applied once the translation resources are updated later.
|
|
|
|
droark
|
|
March 08, 2017, 08:31:34 AM |
|
Having some trouble getting the OSX build going. I'm getting the following on the command line. Doug-Armory:MacOS droark$ ./Armory Traceback (most recent call last): File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ArmoryQt.py", line 43, in <module> import CppBlockUtils as Cpp File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 17, in <module> _CppBlockUtils = swig_import_helper() File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 16, in swig_import_helper return importlib.import_module('_CppBlockUtils') File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module ImportError: dlopen(/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/_CppBlockUtils.so, 2): Symbol not found: __ZTVN8CryptoPP6SHA256E Referenced from: /Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/_CppBlockUtils.so Expected in: flat namespace in /Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/_CppBlockUtils.so
Poking around online, somebody mentioned that otool -l was a good thing to look at when analyzing libraries. Here's what I see for the version of _CppBlockUtils.so I'm building, then the one for a functioning 0.95.1 library. As best I can tell, the new Make system is installing some code and telling the system to look for it in a given location. This won't work for redistribution of generated binaries. The new version also seems to want to load libc++ instead of libstdc++. (This isn't necessarily bad. It's just a possible sign that wires are getting crossed somewhere.) If anybody has any suggestions, I'd appreciate hearing them. Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 6 15 1968 0x00118085 Load command 0 cmd LC_SEGMENT_64 cmdsize 712 segname __TEXT vmaddr 0x0000000000000000 vmsize 0x000000000026d000 fileoff 0 filesize 2543616 maxprot 0x00000007 initprot 0x00000005 nsects 8 flags 0x0 Section sectname __text segname __TEXT addr 0x00000000000008c0 size 0x00000000001b3a60 offset 2240 align 2^4 (16) reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0 Section sectname __stubs segname __TEXT addr 0x00000000001b4320 size 0x0000000000000876 offset 1786656 align 2^1 (2) reloff 0 nreloc 0 flags 0x80000408 reserved1 0 (index into indirect symbol table) reserved2 6 (size of stubs) Section sectname __stub_helper segname __TEXT addr 0x00000000001b4b98 size 0x0000000000000ddc offset 1788824 align 2^2 (4) reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0 Section sectname __const segname __TEXT addr 0x00000000001b5980 size 0x0000000000006329 offset 1792384 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __gcc_except_tab segname __TEXT addr 0x00000000001bbcac size 0x0000000000066c98 offset 1817772 align 2^2 (4) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __cstring segname __TEXT addr 0x0000000000222950 size 0x0000000000040a3c offset 2238800 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000002 reserved1 0 reserved2 0 Section sectname text_env segname __TEXT addr 0x0000000000263390 size 0x0000000000002f9f offset 2503568 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __unwind_info segname __TEXT addr 0x0000000000266330 size 0x0000000000006cd0 offset 2515760 align 2^2 (4) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Load command 1 cmd LC_SEGMENT_64 cmdsize 712 segname __DATA vmaddr 0x000000000026d000 vmsize 0x0000000000015000 fileoff 2543616 filesize 86016 maxprot 0x00000007 initprot 0x00000003 nsects 8 flags 0x0 Section sectname __got segname __DATA addr 0x000000000026d000 size 0x0000000000000df0 offset 2543616 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000006 reserved1 361 (index into indirect symbol table) reserved2 0 Section sectname __nl_symbol_ptr segname __DATA addr 0x000000000026ddf0 size 0x0000000000000010 offset 2547184 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000006 reserved1 807 (index into indirect symbol table) reserved2 0 Section sectname __la_symbol_ptr segname __DATA addr 0x000000000026de00 size 0x0000000000000b48 offset 2547200 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000007 reserved1 809 (index into indirect symbol table) reserved2 0 Section sectname __mod_init_func segname __DATA addr 0x000000000026e948 size 0x0000000000000020 offset 2550088 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000009 reserved1 0 reserved2 0 Section sectname __const segname __DATA addr 0x000000000026e970 size 0x0000000000001480 offset 2550128 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __data segname __DATA addr 0x000000000026fdf0 size 0x0000000000011368 offset 2555376 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __common segname __DATA addr 0x0000000000281158 size 0x0000000000000148 offset 0 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000001 reserved1 0 reserved2 0 Section sectname __bss segname __DATA addr 0x00000000002812a0 size 0x00000000000009f1 offset 0 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000001 reserved1 0 reserved2 0 Load command 2 cmd LC_SEGMENT_64 cmdsize 72 segname __LINKEDIT vmaddr 0x0000000000282000 vmsize 0x00000000000b0000 fileoff 2629632 filesize 719392 maxprot 0x00000007 initprot 0x00000001 nsects 0 flags 0x0 Load command 3 cmd LC_ID_DYLIB cmdsize 64 name /usr/local/lib/libCppBlockUtils.0.dylib (offset 24) time stamp 1 Wed Dec 31 16:00:01 1969 current version 1.0.0 compatibility version 1.0.0 Load command 4 cmd LC_DYLD_INFO_ONLY cmdsize 48 rebase_off 2629632 rebase_size 3872 bind_off 2633504 bind_size 19216 weak_bind_off 2652720 weak_bind_size 58856 lazy_bind_off 2711576 lazy_bind_size 13000 export_off 2724576 export_size 69880 Load command 5 cmd LC_SYMTAB cmdsize 24 symoff 2800024 nsyms 7581 stroff 2926000 strsize 423024 Load command 6 cmd LC_DYSYMTAB cmdsize 80 ilocalsym 0 nlocalsym 5546 iextdefsym 5546 nextdefsym 1418 iundefsym 6964 nundefsym 617 tocoff 0 ntoc 0 modtaboff 0 nmodtab 0 extrefsymoff 0 nextrefsyms 0 indirectsymoff 2921320 nindirectsyms 1170 extreloff 0 nextrel 0 locreloff 0 nlocrel 0 Load command 7 cmd LC_UUID cmdsize 24 uuid 1C707878-1774-3DF0-AF9E-069AD838387D Load command 8 cmd LC_VERSION_MIN_MACOSX cmdsize 16 version 10.12 sdk 10.12 Load command 9 cmd LC_SOURCE_VERSION cmdsize 16 version 0.0 Load command 10 cmd LC_LOAD_DYLIB cmdsize 64 name /usr/local/lib/libcryptopp.0.dylib (offset 24) time stamp 2 Wed Dec 31 16:00:02 1969 current version 1.0.0 compatibility version 1.0.0 Load command 11 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib (offset 24) time stamp 2 Wed Dec 31 16:00:02 1969 current version 1238.0.0 compatibility version 1.0.0 Load command 12 cmd LC_LOAD_DYLIB cmdsize 48 name /usr/lib/libc++.1.dylib (offset 24) time stamp 2 Wed Dec 31 16:00:02 1969 current version 307.4.0 compatibility version 1.0.0 Load command 13 cmd LC_FUNCTION_STARTS cmdsize 16 dataoff 2794456 datasize 5568 Load command 14 cmd LC_DATA_IN_CODE cmdsize 16 dataoff 2800024 datasize 0
Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 6 13 1880 0x00118085 Load command 0 cmd LC_SEGMENT_64 cmdsize 712 segname __TEXT vmaddr 0x0000000000000000 vmsize 0x0000000000304000 fileoff 0 filesize 3162112 maxprot 0x00000007 initprot 0x00000005 nsects 8 flags 0x0 Section sectname __text segname __TEXT addr 0x0000000000001710 size 0x0000000000207ab2 offset 5904 align 2^4 (16) reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0 Section sectname __stubs segname __TEXT addr 0x00000000002091c2 size 0x0000000000000810 offset 2134466 align 2^1 (2) reloff 0 nreloc 0 flags 0x80000408 reserved1 0 (index into indirect symbol table) reserved2 6 (size of stubs) Section sectname __stub_helper segname __TEXT addr 0x00000000002099d4 size 0x00000000000009c0 offset 2136532 align 2^2 (4) reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0 Section sectname __const segname __TEXT addr 0x000000000020a3a0 size 0x000000000000d396 offset 2139040 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __gcc_except_tab segname __TEXT addr 0x0000000000217738 size 0x000000000006be8c offset 2193208 align 2^2 (4) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __cstring segname __TEXT addr 0x00000000002835d0 size 0x0000000000037464 offset 2635216 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000002 reserved1 0 reserved2 0 Section sectname __unwind_info segname __TEXT addr 0x00000000002baa34 size 0x0000000000009628 offset 2861620 align 2^2 (4) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __eh_frame segname __TEXT addr 0x00000000002c4060 size 0x000000000003ff98 offset 2900064 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Load command 1 cmd LC_SEGMENT_64 cmdsize 712 segname __DATA vmaddr 0x0000000000304000 vmsize 0x0000000000039000 fileoff 3162112 filesize 221184 maxprot 0x00000007 initprot 0x00000003 nsects 8 flags 0x0 Section sectname __got segname __DATA addr 0x0000000000304000 size 0x0000000000001410 offset 3162112 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000006 reserved1 344 (index into indirect symbol table) reserved2 0 Section sectname __nl_symbol_ptr segname __DATA addr 0x0000000000305410 size 0x0000000000000010 offset 3167248 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000006 reserved1 986 (index into indirect symbol table) reserved2 0 Section sectname __la_symbol_ptr segname __DATA addr 0x0000000000305420 size 0x0000000000000ac0 offset 3167264 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000007 reserved1 988 (index into indirect symbol table) reserved2 0 Section sectname __mod_init_func segname __DATA addr 0x0000000000305ee0 size 0x0000000000000020 offset 3170016 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000009 reserved1 0 reserved2 0 Section sectname __const segname __DATA addr 0x0000000000305f00 size 0x000000000000aa98 offset 3170048 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __data segname __DATA addr 0x00000000003109a0 size 0x0000000000028c60 offset 3213728 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __bss segname __DATA addr 0x0000000000339600 size 0x0000000000002c11 offset 0 align 2^4 (16) reloff 0 nreloc 0 flags 0x00000001 reserved1 0 reserved2 0 Section sectname __common segname __DATA addr 0x000000000033c218 size 0x00000000000000e8 offset 0 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000001 reserved1 0 reserved2 0 Load command 2 cmd LC_SEGMENT_64 cmdsize 72 segname __LINKEDIT vmaddr 0x000000000033d000 vmsize 0x00000000001f1000 fileoff 3383296 filesize 2033464 maxprot 0x00000007 initprot 0x00000001 nsects 0 flags 0x0 Load command 3 cmd LC_ID_DYLIB cmdsize 48 name ../_CppBlockUtils.so (offset 24) time stamp 1 Wed Dec 31 16:00:01 1969 current version 0.0.0 compatibility version 0.0.0 Load command 4 cmd LC_DYLD_INFO_ONLY cmdsize 48 rebase_off 3383296 rebase_size 6336 bind_off 3389632 bind_size 7520 weak_bind_off 3397152 weak_bind_size 191560 lazy_bind_off 3588712 lazy_bind_size 8592 export_off 3597304 export_size 177440 Load command 5 cmd LC_SYMTAB cmdsize 24 symoff 3783528 nsyms 27180 stroff 4223736 strsize 1193024 Load command 6 cmd LC_DYSYMTAB cmdsize 80 ilocalsym 0 nlocalsym 23534 iextdefsym 23534 nextdefsym 3300 iundefsym 26834 nundefsym 346 tocoff 0 ntoc 0 modtaboff 0 nmodtab 0 extrefsymoff 0 nextrefsyms 0 indirectsymoff 4218408 nindirectsyms 1332 extreloff 0 nextrel 0 locreloff 0 nlocrel 0 Load command 7 cmd LC_UUID cmdsize 24 uuid DED14546-5296-33D8-9291-939C52F55583 Load command 8 cmd LC_VERSION_MIN_MACOSX cmdsize 16 version 10.7 sdk 10.11 Load command 9 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libstdc++.6.dylib (offset 24) time stamp 2 Wed Dec 31 16:00:02 1969 current version 104.1.0 compatibility version 7.0.0 Load command 10 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib (offset 24) time stamp 2 Wed Dec 31 16:00:02 1969 current version 1226.10.1 compatibility version 1.0.0 Load command 11 cmd LC_FUNCTION_STARTS cmdsize 16 dataoff 3774744 datasize 8784 Load command 12 cmd LC_DATA_IN_CODE cmdsize 16 dataoff 3783528 datasize 0
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
March 11, 2017, 07:14:34 PM |
|
I'm not quite sure what the status is with the wallet format. It's obviously changed, but which changes are working now? (even on testnet in the case of PSWPKH) It's very much a nit, but the format version string still reads 1.35 when I create a new wallet, and it seems rather like the old wallet format has it's address chain folded into the new format somehow? I WANT A NUMBER (even if it's 1.35.0.0.0.1 ) Can I delete the old wallet files, or are they the file system representation of the address chain for the new format?
|
Vires in numeris
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 11, 2017, 07:57:01 PM |
|
I'm not quite sure what the status is with the wallet format. It's obviously changed, but which changes are working now? (even on testnet in the case of PSWPKH) It's very much a nit, but the format version string still reads 1.35 when I create a new wallet, and it seems rather like the old wallet format has it's address chain folded into the new format somehow? I WANT A NUMBER (even if it's 1.35.0.0.0.1 ) Can I delete the old wallet files, or are they the file system representation of the address chain for the new format? The mirror wallets use the stub for the new wallets. The stub doesn't have support for encryption, comments nor BIP32/39/44. Completing the wallet format will be the focus of 0.97 The C++ mirror wallets are only a watching only copy of the 1.35 Python wallets. Mirror wallets are necessary to manage the nested P2SH address types. They also serve as the interface to the DB. The Python wallets are only used by the GUI (which does not understand C++ wallets yet) from now on. The Python wallets still hold your private keys, that currently never hit the C++ wallet code. The private keys are exposed to the new C++ signer when spending from a nested P2SH output. P2PKH signing only uses the old code path. Both paths share the same underlying crypto code under the hood, that part has not changed. The tx messaging format is still the same, so P2PKH outputs created by 0.96 can still be signed by older versions all the way down to 0.92. Older signers won't be able to make sense of any nested address type however. Coin selection and tx composition has been rewritten in C++ to accommodate for satoshi/byte fees and tx size prediction. It should also provide improved privacy and leverage the witness data weighting discount. This is the only part of the code path that was forcibly changed from previous versions. You can opt out of the other changes by just sticking to P2PKH outputs, in which case the new wallet code will not be involved at all in signing nor verification. You cannot delete the old files, these still are your wallets, even the WO versions. The GUI still operates on those. Since the new code only serves as an interface to augment the Python wallets, it does not call for a new version number. Also, while this may be confusing, wallet versioning in Armory actually refers to the address derivation scheme iteration, not the wallet design as a whole. That sheme part has not changed. As a matter of fact, the Python wallet code has not changed, you can verify this by browsing the commit history. Only new conditional code paths have been added to handle nested address types in the GUI. None of that data is written to the Python wallets, it is saved with the C++ wallet container intsead. While you cannot delete your old wallet files, you can delete any .lmdb file at no risk of data loss. These are generated on when missing on every start. The fully fledged new wallets will use another extension.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
March 11, 2017, 09:12:10 PM |
|
The mirror wallets use the stub for the new wallets. The stub doesn't have support for encryption, comments nor BIP32/39/44.
But the mirror spec does support BIP32/39/44? I received my Trezor recently, and would like it working with Armory ASAP The C++ mirror wallets are only a watching only copy of the 1.35 Python wallets. Mirror wallets are necessary to manage the nested P2SH address types. They also serve as the interface to the DB. The Python wallets are only used by the GUI (which does not understand C++ wallets yet) from now on.
The Python wallets still hold your private keys, that currently never hit the C++ wallet code. The private keys are exposed to the new C++ signer when spending from a nested P2SH output. P2PKH signing only uses the old code path. Both paths share the same underlying crypto code under the hood, that part has not changed.
The tx messaging format is still the same, so P2PKH outputs created by 0.96 can still be signed by older versions all the way down to 0.92. Older signers won't be able to make sense of any nested address type however.
So 0.96 signing will be recommended for compatibility from now on? And the recommended signing version should freeze at 0.97 assuming the wallet format is finalised in that version? Coin selection and tx composition has been rewritten in C++ to accommodate for satoshi/byte fees and tx size prediction. It should also provide improved privacy and leverage the witness data weighting discount. This is the only part of the code path that was forcibly changed from previous versions. You can opt out of the other changes by just sticking to P2PKH outputs, in which case the new wallet code will not be involved at all in signing nor verification.
How does the rewrite improve privacy? You cannot delete the old files, these still are your wallets, even the WO versions. The GUI still operates on those. Since the new code only serves as an interface to augment the Python wallets, it does not call for a new version number. Also, while this may be confusing, wallet versioning in Armory actually refers to the address derivation scheme iteration, not the wallet design as a whole. That sheme part has not changed.
What exactly does the scheme comprise, in comparison to the overall format? It sounds like the scheme is simply a component of the format. As a matter of fact, the Python wallet code has not changed, you can verify this by browsing the commit history. Only new conditional code paths have been added to handle nested address types in the GUI. None of that data is written to the Python wallets, it is saved with the C++ wallet container intsead. While you cannot delete your old wallet files, you can delete any .lmdb file at no risk of data loss. These are generated on when missing on every start. The fully fledged new wallets will use another extension.
I have to say I like that you've done it this way, it provides flexibility and hence options to the user, allowing each user to use their own judgement of the possible risks of the changes to the code and act accordingly (which you no doubt intended).
|
Vires in numeris
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3486
Merit: 6824
Just writing some code
|
|
March 12, 2017, 12:35:28 AM |
|
But the mirror spec does support BIP32/39/44?
The C++ wallets will support BIP 32/44 at some point, as the goal is to move off of the python wallets over to the C++ wallets which will be the entirely new format. The plan is for that to support BIP 32/44, Segwit, and compressed keys. I think it may also support BIP 39 and P2SH, but I'm not sure about that as it's up to goatpig. I received my Trezor recently, and would like it working with Armory ASAP
Armory would need to have hardware wallet support for that to work, and that is something I am planning on doing after the new wallet stuff is finished. So 0.96 signing will be recommended for compatibility from now on? And the recommended signing version should freeze at 0.97 assuming the wallet format is finalised in that version?
Yes. 0.96 is the new recommended offline signer version as it will have support for segwit and the other output types. How does the rewrite improve privacy?
There were changes to coin selection which optimize for privacy, i.e. sticking to inputs from the same address instead of any input in the wallet.
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3724
Merit: 1360
Armory Developer
|
|
March 12, 2017, 06:35:45 AM |
|
But the mirror spec does support BIP32/39/44? I received my Trezor recently, and would like it working with Armory ASAP
No, there is support for that yet. So 0.96 signing will be recommended for compatibility from now on? And the recommended signing version should freeze at 0.97 assuming the wallet format is finalised in that version?
If you use anything but P2PKH, you will have to use 0.96. After 0.97 will come out, the signer shouldn't change for the foreseeable future How does the rewrite improve privacy?
The main change is that the former coin selection code had to run on a flat fee. The new code is built to operate on just a fee/byte hint, so it outperforms the original code just by design alone (had to add a lot of code to predict tx size). It performs better with flat fee inputs as well since it evaluates its fee/byte effect. The coin-age mechanic does not reflect tx priority anymore, its impact on the coin selection calculation has been greatly reduced. This was the primary metric that allowed the former code to consolidate utxos. The conditions for that consolidation were very restrictive too. Since the new code can predict tx size and adjust fee/byte if necessary, the conditions for consolidations are much laxer. Basically, as long as it can maintain the best privacy score, the code will actively try to consume more utxos than it creates. Utxo consolidation is a long term improvement on privacy. You won't see a benefit from it unless you wallet is highly fragmented. The other changes are around change output obfuscation. The rework around fee/byte support and size prediction is more flexible than the previous code. While the previous code did try to pick outputs that obfuscated the change value, this code has an option ("Adjust Fee") that will pick outputs and adapt the fee to align the decimal point between spend value and change value when using fee/byte. While this change has no effect on flat fees, it is particularly efficient with fee/byte. Since the mirror wallets can handle 2 new P2SH types, it can also match change script type with spend script type. The previous code forced all outputs to P2PKH (the only type it could make sense of). With the new code, in auto change mode (you can modify that in the settings dialog), it will match the change script type with the spend script type. If you don't set it on auto (you can choose to force a specific change script type, say if you want all change to be SW), it will warn you when it differs from the spend script type. Lastly, all these changes properly apply to explicit utxo sets created through coin control. Some of the new code may inflate your fee to improve privacy. The fee inflation is currently hard coded to not increase your fee/byte by more than 10%. I may add an option in the future to modify that margin. What exactly does the scheme comprise, in comparison to the overall format? It sounds like the scheme is simply a component of the format.
The format defines how the wallet is handled on disk, error checking and encryption parameters, as well as which cryptographic asset it manages and how. The derivation scheme only defines how cryptographic assets are derived from the seed. In this particular case, Armory 1.35c should be compared to BIP32/44, and the Python wallets (which are unversioned) should be compared to the C++ wallets. I have to say I like that you've done it this way, it provides flexibility and hence options to the user, allowing each user to use their own judgement of the possible risks of the changes to the code and act accordingly (which you no doubt intended).
Don't want to potentially split the user base by forcing a new wallet code on the community. There are people out there still using 0.93 for whatever reason. At any rate, SegWit is opt-in, so the code around it should be opt-in too. This doesn't apply to coin selection though, that stuff needed reworked around fee/byte.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
March 12, 2017, 09:32:02 PM |
|
Something that just occurred to me
Is it not the case that "native" (i.e. not nested P2SH) P2WPKH and P2WSH address formats will appear subsequent to Segwit activation? And I say "appear", as they're AFAIA unspecified at this point.
Any reasonable expectation that the un-nested Witness address specifications will be available to implement before 0.97? Surely the wallet format needs to be change to incorporate them, although presumably not the signer? Will the wallet format actually stabilise at 97.1 or 0.98, in other words?
|
Vires in numeris
|
|
|
droark
|
|
March 12, 2017, 10:30:59 PM |
|
Hello. If anybody out there can compile Armory on Macs, I'd appreciate a little backup. goatpig checked in a fix today that seems to have gotten Armory going again on Macs. (It had been broken since the Autotools stuff got checked in.) There are still some compilation issues, though, and probably some runtime issues. I'll PR some changes I had baking before goatpig's fix. More eyeballs and testers would be appreciated, especially once I check in the changes I'd like to make. Thanks.
|
|
|
|
|