0.96 preliminary testing

[Ente]

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-submodules

Otherwise, 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

[1715509937]

1715509937

[1715509937]

1715509937

[1715509937]

1715509937

[droark]

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.

Code:

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]

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.

Code:

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]

I expect you're aware of this goatpig;  Wallet Properties -> Receive Coins button produces

Code:

(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]

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]

- 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]

I expect you're aware of this goatpig;  Wallet Properties -> Receive Coins button produces

Code:

 (...)

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)

[droark]

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.

Code:

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]

I expect you're aware of this goatpig;  Wallet Properties -> Receive Coins button produces

Code:

 (...)

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.

Code:

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]

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]

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]

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]

Having some trouble getting the OSX build going. I'm getting the following on the command line.

Code:

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.

Code:

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

Code:

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]

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?

[goatpig]

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]

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

[achow101]

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]

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]

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?

[droark]

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.