3rd testing build has the fix for the txsigcollet issue. I was assuming you were using that.
You can get the gcc4.7 build in the usual place:
https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.99.3-testing
Topic: Armory 0.96 third testing builds - page 2. (Read 4651 times)
1) What is the signer's version?
2) The .deb packages work, I got no idea what kind of Ubuntu you are using that it can't get them to run. Try the gcc4.7 I made just in case you are using some weird distro.
2) The .deb packages work, I got no idea what kind of Ubuntu you are using that it can't get them to run. Try the gcc4.7 I made just in case you are using some weird distro.
1. Where do I find it?
2. Armory is running fine in offline mode on Ubuntu. It was the one built from source as you instructed me to do (0.95.99.2 on both systems). Testing branch. gcc4.7???
I assume versions should be compatible as the are the same testing version.
I am seriously considering importing the encrypted wallets to my online system and moving to another wallet. However, I love armory for its M/N backups and of course I would have to re-setup backup schedules for me and some other people that I manage their wallets for.
1) What is the signer's version?
2) The .deb packages work, I got no idea what kind of Ubuntu you are using that it can't get them to run. Try the gcc4.7 I made just in case you are using some weird distro.
2) The .deb packages work, I got no idea what kind of Ubuntu you are using that it can't get them to run. Try the gcc4.7 I made just in case you are using some weird distro.
Oh boy, just realized I am still on 0.91 on my offline win 32 PC. Can't sign the transaction as the format changed. I was under the impression I was on 0.93 or something.
I was just thinking about installing Ubuntu on that machine and creating the Offline PC from scratch. However, this will be the same HW as the online Ubuntu PC so I fear that I cant't install from .deb and installing all the dependencies to build from source will be a major pain without plugging it into the network.
I'll probably try to find a Win x64 installation disk somehow and try it that way.
Any other ideas?
Edit: What if I downgrade my bitcoin node to 0.13 and use 0.96 Armory? Kind of don't want to change a running system since I just got it all online.
Edit2: Or I use the last 0.95 deb and hope it will work that way?
Edit3: I now disconnected my Ubuntu PC from the network and have set it up as offline machine. Now the next problem haunts me: It tells me my unsigned transaction I want to sign is unrecognized. Tried to export it as unsigned tx file and as text only. It tells me it is unrecognized. Could there be a problem with the language settings.
Edit4: Just tried it from a different wallet and it also tells me unrecognized. Both versions of Armory are the newest testing build. The log just tells me the file was loaded. why it was unrecognized it doesn't tell me.
Edit5: My online wallet can successfully import the unsigned TX and recognizes everything as expected. It must be some kind of language, date format or ASCI Table problem. Any advice mostly appreciated.
Terminal Output:
I was just thinking about installing Ubuntu on that machine and creating the Offline PC from scratch. However, this will be the same HW as the online Ubuntu PC so I fear that I cant't install from .deb and installing all the dependencies to build from source will be a major pain without plugging it into the network.
I'll probably try to find a Win x64 installation disk somehow and try it that way.
Any other ideas?
Edit: What if I downgrade my bitcoin node to 0.13 and use 0.96 Armory? Kind of don't want to change a running system since I just got it all online.
Edit2: Or I use the last 0.95 deb and hope it will work that way?
Edit3: I now disconnected my Ubuntu PC from the network and have set it up as offline machine. Now the next problem haunts me: It tells me my unsigned transaction I want to sign is unrecognized. Tried to export it as unsigned tx file and as text only. It tells me it is unrecognized. Could there be a problem with the language settings.
Edit4: Just tried it from a different wallet and it also tells me unrecognized. Both versions of Armory are the newest testing build. The log just tells me the file was loaded. why it was unrecognized it doesn't tell me.
Edit5: My online wallet can successfully import the unsigned TX and recognizes everything as expected. It must be some kind of language, date format or ASCI Table problem. Any advice mostly appreciated.
Terminal Output:
Code:
Traceback (most recent call last):
File "/usr/local/bin/../lib/armory/ArmoryQt.py", line 646, in
execAbout = lambda: DlgHelpAbout(self).exec_()
File "/usr/local/lib/armory/qtdialogs.py", line 8228, in __init__
lblHead = QRichLabel(self.tr('Armory Bitcoin Wallet : Version %1-beta-%2').arg(getVersionString(BTCARMORY_VERSION), BTCARMORY_BUILD), doWrap=False)
TypeError: arguments did not match any overloaded call:
QString.arg(int, int fieldWidth=0, int base=10, QChar fillChar=QLatin1Char(' ')): argument 1 has unexpected type 'str'
QString.arg(float, int fieldWidth=0, str format='g', int precision=-1, QChar fillChar=QLatin1Char(' ')): argument 1 has unexpected type 'str'
QString.arg(int, int fieldWidth=0, int base=10, QChar fillChar=QLatin1Char(' ')): argument 1 has unexpected type 'str'
QString.arg(int, int fieldWidth=0, int base=10, QChar fillChar=QLatin1Char(' ')): argument 1 has unexpected type 'str'
QString.arg(QString, int fieldWidth=0, QChar fillChar=QLatin1Char(' ')): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString, QString): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
QString.arg(QString, QString, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
(ERROR) ArmoryUtils.py:1412 - Attempting to unserialize something not an ASCII block
(ERROR) AsciiSerialize.py:74 - Expected str "TXSIGCOLLECT", got "2017-04-23"
(ERROR) ArmoryUtils.py:1412 - Attempting to unserialize something not an ASCII block
(ERROR) AsciiSerialize.py:74 - Expected str "TXSIGCOLLECT", got "AAAAABl2qRSWT5uRjyWH/G6M6BH1J4QiTJJdcIisoxUAAAAAAAAZdqkUIuz4d8vN"
(ERROR) ArmoryUtils.py:1412 - Attempting to unserialize something not an ASCII block
(ERROR) AsciiSerialize.py:74 - Expected str "TXSIGCOLLECT", got "tXsVR2076guIrC9sAAAAAAAAGXapFB4VBiz4+5qD2eHAstbeg/ma9Tq7iKxfKwMA"
(ERROR) ArmoryUtils.py:1412 - Attempting to unserialize something not an ASCII block
(ERROR) AsciiSerialize.py:74 - Expected str "TXSIGCOLLECT", got "iCTUR4nIb36IrB8oDgAAAAAAGXapFG/NbQCufwJlnZ0TZDtVua1ITRHciKzUOQQA"
(ERROR) ArmoryUtils.py:1412 - Attempting to unserialize something not an ASCII block
(ERROR) AsciiSerialize.py:74 - Expected str "TXSIGCOLLECT", got "jKnHF6pv7B6IrPMKBAAAAAAAGXapFDgxh01N8qYL4w1XhEZZi/195I6iiKwXNgAA"
It worked, thank you so much! I am online! 
Regarding the ram usage, on this machine I have 16gb, and I switched over from the Ubuntu PC which only has 4gb. In the long run I would prefer the Ubuntu PC as I can leave it online 24/7. Do you think with the settings you recommended to me now, it might also work on the Ubuntu PC where it always got stuck building the DB?
Regarding the ram usage, on this machine I have 16gb, and I switched over from the Ubuntu PC which only has 4gb. In the long run I would prefer the Ubuntu PC as I can leave it online 24/7. Do you think with the settings you recommended to me now, it might also work on the Ubuntu PC where it always got stuck building the DB?
On your low RAM machine, you should use:
Code:
db-type=DB_BARE
ram-usage=1
On your other machine, you shouldn't need any of these extra settings at all. If it's still failing to build & scan, use DB_BARE. DB_BARE is an initialization setting, you can't swap it around after the DB has been created. Once you create a DB_BARE db, that setting will stick for the db's lifetime, so manage it accordingly.
The fact that your machines require DB_BARE suggests some sort of system instability (by default the build phase will max out your CPU).
Quote
@goatpig, did you change the location of the Armory installation for 0.96? I've tried the 0.95.99.3 .deb package, but I'm getting an absence of installation at /usr/lib/ (even the directory /usr/lib/armory isn't created, /usr/local/armory & /usr/local/armorydb are created). Installation is suspiciously quick also, is there some error in the install package?
Plenty changed, courtesy of autotools. All binaries now go to /usr/local/bin, libs and python code files go to /usr/local/lib/armory. Desktop files still go to /usr/share/applications. The .deb does not distribute CPP code files anymore.
@Simon Belmond
The settings goatpig recommended are tailored for low-RAM low-CPU machines, but there are no guarantees. Try it, and you will see. Glad to hear you have a working Armory setup now regardless.
@goatpig, did you change the location of the Armory installation for 0.96? I've tried the 0.95.99.3 .deb package, but I'm getting an absence of installation at /usr/lib/ (even the directory /usr/lib/armory isn't created, /usr/local/armory & /usr/local/armorydb are created). Installation is suspiciously quick also, is there some error in the install package?
The settings goatpig recommended are tailored for low-RAM low-CPU machines, but there are no guarantees. Try it, and you will see. Glad to hear you have a working Armory setup now regardless.
@goatpig, did you change the location of the Armory installation for 0.96? I've tried the 0.95.99.3 .deb package, but I'm getting an absence of installation at /usr/lib/ (even the directory /usr/lib/armory isn't created, /usr/local/armory & /usr/local/armorydb are created). Installation is suspiciously quick also, is there some error in the install package?
It worked, thank you so much! I am online!
Regarding the ram usage, on this machine I have 16gb, and I switched over from the Ubuntu PC which only has 4gb. In the long run I would prefer the Ubuntu PC as I can leave it online 24/7. Do you think with the settings you recommended to me now, it might also work on the Ubuntu PC where it always got stuck building the DB?
Regarding the ram usage, on this machine I have 16gb, and I switched over from the Ubuntu PC which only has 4gb. In the long run I would prefer the Ubuntu PC as I can leave it online 24/7. Do you think with the settings you recommended to me now, it might also work on the Ubuntu PC where it always got stuck building the DB?
Add this line to the .conf:
Then start from the top.
How much RAM do you have? If you have less than 8GB, also add ram-usage=1
Code:
db-type=DB_BARE
Then start from the top.
How much RAM do you have? If you have less than 8GB, also add ram-usage=1
Try using a different external disk. And/or be extra careful not to knock the USB cable connecting your disk to your machine. The issue you're having might be disk failure, or cable failure. Certainly, Armory isn't happy with what it's reading from the Bitcoin blockchain when it scans your wallet transactions.
I think Armory Wants to drive me crazy.... ;-) At 99% of scanning my wallets I get this:
Edit: Just reproduced it. It happens at the exact same spot just after height #461932. Any advice for this?
Edit: Just reproduced it. It happens at the exact same spot just after height #461932. Any advice for this?
It seems to have worked out. Only on the bottom it still tells me Armory is offline. I import my watch only wallets now and see if the balances show up correctly.
Edit: Wallet balances are shown as 0 for all wallets. It also tells me that the Bitcoin node is offline. I set Armory to manage Bitcoin and gave it the correct directories.
Edit2: I think it looks good now. Had to stop ArmoryDB and let everything run by ArmoryQt and have it rund the ArmoryDB itself. I am now at scanning transaction history but database seems built and all. I report again as soon as I can see my balances. History scan seems to take another 30min or so.
Edit: Wallet balances are shown as 0 for all wallets. It also tells me that the Bitcoin node is offline. I set Armory to manage Bitcoin and gave it the correct directories.
Edit2: I think it looks good now. Had to stop ArmoryDB and let everything run by ArmoryQt and have it rund the ArmoryDB itself. I am now at scanning transaction history but database seems built and all. I report again as soon as I can see my balances. History scan seems to take another 30min or so.
Quote
Without that option the behavior seems the same, a console with ArmoryDB.exe appears with a ton of -INFO and Armory starts making its things. Currently at 14% of building database and also initializing Bitcoin engine. I changed and let armory handle bitcoin in the background. Who knows, maybe works better that way without starting BitcoinQt first. I'll update.
Don't run ArmoryQt with the arg. Just run ArmoryDB with the arg, then run the client on its own. It will find the db.
First, delete the databases folder again. Then, in F:\Armory, create a armorydb.conf text file. Fill it with this:
Code:
satoshi-datadir=F:\Bitcoin
thread-count=1
Save and close, then run:
Code:
> ArmoryDB.exe --datadir=F:\Armory
Then in another cmd prompt, run the client (while the DB is still running):
Code:
> ArmoryQt.exe --datadir=F:\Armory
Quote
Is there an ArmoryDB log somewhere?
dbLog.txt in your datadir.
OK with that option I get this:
Without that option the behavior seems the same, a console with ArmoryDB.exe appears with a ton of -INFO and Armory starts making its things. Currently at 14% of building database and also initializing Bitcoin engine. I changed and let armory handle bitcoin in the background. Who knows, maybe works better that way without starting BitcoinQt first. I'll update.
Edit: Nope stuck at block file 220 this time. Is there an ArmoryDB log somewhere?
Without that option the behavior seems the same, a console with ArmoryDB.exe appears with a ton of -INFO and Armory starts making its things. Currently at 14% of building database and also initializing Bitcoin engine. I changed and let armory handle bitcoin in the background. Who knows, maybe works better that way without starting BitcoinQt first. I'll update.
Edit: Nope stuck at block file 220 this time. Is there an ArmoryDB log somewhere?
Quote
Delete the database and try again from the top with --thread-count=1. Does it always fail at the same spot now?
That's what I hope to reveal
Quote
Do you recommend to re-download the whole chain again?
Not yet, I wanna see what's messed with it.
Are you using the same block file data on the Windows machine than on the Ubuntu one?
Quote
So far always happended between maybe 18 an 28 % progress.
Yes I copied it over. Bitcoin QT workes fine and is synched. I do not use the default datadir, neither for Armory nor Bitcoin-QT. However it starts to build the DB in the correct place?
Do you recommend to re-download the whole chain again?
Delete the database and try again from the top with --thread-count=1. Does it always fail at the same spot now?
Are you using the same block file data on the Windows machine than on the Ubuntu one?
Delete the database and try again from the top with --thread-count=1. Does it always fail at the same spot now?
Quote
So far always happended between maybe 18 an 28 % progress.
Delete the database and try again from the top with --thread-count=1. Does it always fail at the same spot now?
I moved to a Windows 7 x64 system with 16 gb ram as the ubuntu pc just din't handle the DB build ever. Now I constantly get this. Sorry for the ugly screenshot but as soon as I press cancle ArmorDB and the CMD vanish.
So far always happended between maybe 18 an 28 % progress.
any idea?
So far always happended between maybe 18 an 28 % progress.
any idea?
1) P2PKH is Armory's legacy type script type. Uses uncompressed keys. Any 0.92+ signer can sign these outputs even if they are created by 0.96 and later.
Output scripts are 23 bytes large, input scripts are [72~74 + 65] bytes long (sig + uncompressed pub key)
2) (nested) P2SH-P2PK is a single sig compressed key script.
a) The smallest single sig construct is raw P2PK, where you put the compressed public key as is in the output. This is a loss of security over P2PKH because your public key is exposed before redeeming its content (you don't get the extra protection afforded by the hash). This results in the smallest single input at redemption, which would be only the signature. A 1-of-1 raw multisig would give you the same result for the same downfall.
This path gives you a 34 byte output script and 72~74 byte input script.
b) The most common way to use compressed public keys is with regular P2PKH. You hash the compressed public key instead of the uncompressed one, the rest is plain P2PKH.
This yields a 23 bytes output and [72~74 + 33] bytes input (sig + compressed key)
c) Then there's P2SH-P2PK, which is being introduced in Armory. This nests the P2PK script from a) in a P2SH. You get the hash protection and about the same size as b.
You would have 22 bytes outputs and [72~74 + 34] bytes input (sig + compressed P2PK script).
I decided to use the P2SH path instead of compressed keys over P2PKH for 2 reasons:
- The original wallets were built with no P2SH in. When lockboxes were introduced, etotheipi made a point of distinguishing lockboxes from wallets by P2SH vs P2PKH. By doing this, it makes it easier to deliver compressed key support as an opt-in feature. The whole development processed was tailored to keep all that new code opt-in.
- This opens up a path for privacy improvement: Currently Armory can only create P2PKH change. When paying to a P2SH address (a lot of services use those now), your change becomes obvious. By introducing a P2SH script type, it allows Armory to match the script type for the change output if you allow it to. You need to pick the auto change option in the settings for that to happen, but the GUI will warn you from now on if your change type differs from the spend type.
3) (nested) P2SH-P2WPKH. This is a straight forward nested SegWit single sig output. As per SegWit convention, it uses compressed keys. Since it's P2SH, non SegWit wallets can pay to this script type, so you can pass it around to make sure you receive a SW output.
This will net you a 22 bytes output, 22 bytes input (version 0 p2wpkh script) and [72~74 + 33] bytes witness program (sig + compressed pub key).
-----------
EDIT: there is no significant difference in performance between any of these script types.
Output scripts are 23 bytes large, input scripts are [72~74 + 65] bytes long (sig + uncompressed pub key)
2) (nested) P2SH-P2PK is a single sig compressed key script.
a) The smallest single sig construct is raw P2PK, where you put the compressed public key as is in the output. This is a loss of security over P2PKH because your public key is exposed before redeeming its content (you don't get the extra protection afforded by the hash). This results in the smallest single input at redemption, which would be only the signature. A 1-of-1 raw multisig would give you the same result for the same downfall.
This path gives you a 34 byte output script and 72~74 byte input script.
b) The most common way to use compressed public keys is with regular P2PKH. You hash the compressed public key instead of the uncompressed one, the rest is plain P2PKH.
This yields a 23 bytes output and [72~74 + 33] bytes input (sig + compressed key)
c) Then there's P2SH-P2PK, which is being introduced in Armory. This nests the P2PK script from a) in a P2SH. You get the hash protection and about the same size as b.
You would have 22 bytes outputs and [72~74 + 34] bytes input (sig + compressed P2PK script).
I decided to use the P2SH path instead of compressed keys over P2PKH for 2 reasons:
- The original wallets were built with no P2SH in. When lockboxes were introduced, etotheipi made a point of distinguishing lockboxes from wallets by P2SH vs P2PKH. By doing this, it makes it easier to deliver compressed key support as an opt-in feature. The whole development processed was tailored to keep all that new code opt-in.
- This opens up a path for privacy improvement: Currently Armory can only create P2PKH change. When paying to a P2SH address (a lot of services use those now), your change becomes obvious. By introducing a P2SH script type, it allows Armory to match the script type for the change output if you allow it to. You need to pick the auto change option in the settings for that to happen, but the GUI will warn you from now on if your change type differs from the spend type.
3) (nested) P2SH-P2WPKH. This is a straight forward nested SegWit single sig output. As per SegWit convention, it uses compressed keys. Since it's P2SH, non SegWit wallets can pay to this script type, so you can pass it around to make sure you receive a SW output.
This will net you a 22 bytes output, 22 bytes input (version 0 p2wpkh script) and [72~74 + 33] bytes witness program (sig + compressed pub key).
-----------
EDIT: there is no significant difference in performance between any of these script types.
Okay thank you they do now. What are the differences between the 3 address generation methods from a performance and security standpoint?
Was maybe one of the dependencies missing for running it from the .deb file?
dpkg would fail to install the package if the dependencies aren't satisfied.
Quote
Even though I kept the blocks, it is taking ages to synch the block headers. Could I have prevented this in any way?
Did it get past that step? Post your logs otherwise.
Quote
Windows 7 x64 SP1 - the wallet properties transaction list looks weird with a bunch of dropdowns and blank options with no addresses listed.
The address column (leftmost) is tiny by default (Qt4, go figure). Just expand it, it will make sense right away.
Jump to: