Code:
-INFO - 1489439887: (SocketObject.cpp:516) POLLIN recv return 0
Topic: 0.96 preliminary testing - page 3. (Read 6363 times)
Just submitted a PR that should squash the final-ish bug keeping the OSX build from getting off the ground. It's still not quite working, though. While the DB is being populated after the initial block/Tx scan, Armory seems to get confused and never gets past the scan stage, despite Armory appearing to still be scanning. I really don't see anything else in the logs, unfortunately.
Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now.
Both nested script types have been tested on the testnet. I cross compiled 0.96 for my RPi yesterday and will test the nested compressed key script on the mainnet with my own coins sometimes before I post the first testing builds.
Ah, so there is at least a proposal for a spec (I seem to remember there was an old one that was withdrawn)
Last wallet question
Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now.
Last wallet question
Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now.
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?
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?
sipa has a proposal:
https://gist.github.com/sipa/c291da162f6ef8cc770bfc7f015c6c49
It will be discussed at the s3nd meet among other topics:
https://s3nd.org/berlin2017
I can't tell whether this will be ready for 0.97, but I expect it will be by 0.98.
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.
(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.
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?
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?
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.
Quote
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
Quote
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.
Quote
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.
Quote
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.
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. 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.
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).
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?
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.
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?
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?
Having some trouble getting the OSX build going. I'm getting the following on the command line.
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:
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
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
_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
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.
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.
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
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.
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).
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):
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.
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.
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.
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.
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.
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
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):
- 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?
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
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.
Jump to: