Thanks for the quick response, Alan! Signature and hash verify fine.
Thanks again
roy
Topic: Armory - Discussion Thread - page 58. (Read 521829 times)
Could someone tell me where to get the signed hash for the Mac version of 0.91? It seems to be missing from the download page.
Thanks
roy
Thanks
roy
Sorry, my new release script forgot to pull it from the offline computer. It will be posted to the website shortly. Until then:
https://s3.amazonaws.com/bitcoinarmory-media/armory_0.91-beta_sha256.txt.asc
Could someone tell me where to get the signed hash for the Mac version of 0.91? It seems to be missing from the download page.
Thanks
roy
Thanks
roy
I am using the dev-branch 0.91 since february. (and 0.90 was not really in testing mode never on my envoirement)
As now I am not sure if it ocurred since 0.90.99.5, the previous version which was deployed was 0.90.99.2
Next time I will note better this small details.
As now I am not sure if it ocurred since 0.90.99.5, the previous version which was deployed was 0.90.99.2
Next time I will note better this small details.
Yes it is in 0.90.99.5
But ocurred before (some days ago as far as I can remember)
But ocurred before (some days ago as far as I can remember)
Did it ever happen with 0.90? The same ledger snafu in .5 is present in .4
Yes it is in 0.90.99.5
But ocurred before (some days ago as far as I can remember)
But ocurred before (some days ago as far as I can remember)
Another strange thing with armoryd:
We are importing to SQL the Ledger entries.
And we have detected that getledger... returns some entries duplicated.
we identify the entries by "ledger_i" which is the i variable of the loop. We added it to the json
so for further requests we know from which to which to ask for.
example entries which are getting duplicated:
and this is the more readable version:
For us there is no problem as we can identify the duplicated entries and just ignore them when importing them.
The question is:
Is there some other impact / risk with duplicated entries internally?
Like SelectCoins, Balance stuff, etc?
I dont want to be hateful with that bug reports, I just want to help to identify errors.
Best regards!
We are importing to SQL the Ledger entries.
And we have detected that getledger... returns some entries duplicated.
we identify the entries by "ledger_i" which is the i variable of the loop. We added it to the json
so for further requests we know from which to which to ask for.
example entries which are getting duplicated:
Code:
...
and this is the more readable version:
Code:
...
For us there is no problem as we can identify the duplicated entries and just ignore them when importing them.
The question is:
Is there some other impact / risk with duplicated entries internally?
Like SelectCoins, Balance stuff, etc?
I dont want to be hateful with that bug reports, I just want to help to identify errors.
Best regards!
Is this with 0.90.99.5? We had a bug-fix snafu to make 0.90.99.5 and actually broke some ledger code that was leading to some missing, and some duplicated ledger entries. That might be what you're seeing. This should be fixed in .6+
Another strange thing with armoryd:
We are importing to SQL the Ledger entries.
And we have detected that getledger... returns some entries duplicated.
we identify the entries by "ledger_i" which is the i variable of the loop. We added it to the json
so for further requests we know from which to which to ask for.
example entries which are getting duplicated:
and this is the more readable version:
For us there is no problem as we can identify the duplicated entries and just ignore them when importing them.
The question is:
Is there some other impact / risk with duplicated entries internally?
Like SelectCoins, Balance stuff, etc?
I dont want to be hateful with that bug reports, I just want to help to identify errors.
Best regards!
We are importing to SQL the Ledger entries.
And we have detected that getledger... returns some entries duplicated.
we identify the entries by "ledger_i" which is the i variable of the loop. We added it to the json
so for further requests we know from which to which to ask for.
example entries which are getting duplicated:
Code:
{
"comment": "",
"direction": "send",
"blockhash": "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa",
"txtime": 1396375900,
"txsize": 471,
"firstrecip": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34",
"confirmations": 5,
"netdiff": -0.0026,
"senderme": [
{
"amount": 0.72,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
},
{
"amount": 1.3,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"fee": 0.0001,
"recipme": [
{
"amount": 0.4975,
"address": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
},
{
"amount": 1.5199,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"blocktime": 1396375900,
"txid": "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb",
"wallet": "2pEQ4Bqu8",
"amount": 0.0025,
"recipother": [
{
"amount": 0.0025,
"address": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
}
],
"changerecip": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq",
"senderother": [],
"ledger_i": 47
},
{
"comment": "",
"direction": "send",
"blockhash": "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa",
"txtime": 1396375900,
"txsize": 471,
"firstrecip": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34",
"confirmations": 5,
"netdiff": -0.0026,
"senderme": [
{
"amount": 0.72,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
},
{
"amount": 1.3,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"fee": 0.0001,
"recipme": [
{
"amount": 0.4975,
"address": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
},
{
"amount": 1.5199,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"blocktime": 1396375900,
"txid": "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb",
"wallet": "2pEQ4Bqu8",
"amount": 0.0025,
"recipother": [
{
"amount": 0.0025,
"address": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
}
],
"changerecip": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq",
"senderother": [],
"ledger_i": 48
}
"comment": "",
"direction": "send",
"blockhash": "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa",
"txtime": 1396375900,
"txsize": 471,
"firstrecip": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34",
"confirmations": 5,
"netdiff": -0.0026,
"senderme": [
{
"amount": 0.72,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
},
{
"amount": 1.3,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"fee": 0.0001,
"recipme": [
{
"amount": 0.4975,
"address": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
},
{
"amount": 1.5199,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"blocktime": 1396375900,
"txid": "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb",
"wallet": "2pEQ4Bqu8",
"amount": 0.0025,
"recipother": [
{
"amount": 0.0025,
"address": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
}
],
"changerecip": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq",
"senderother": [],
"ledger_i": 47
},
{
"comment": "",
"direction": "send",
"blockhash": "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa",
"txtime": 1396375900,
"txsize": 471,
"firstrecip": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34",
"confirmations": 5,
"netdiff": -0.0026,
"senderme": [
{
"amount": 0.72,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
},
{
"amount": 1.3,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"fee": 0.0001,
"recipme": [
{
"amount": 0.4975,
"address": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
},
{
"amount": 1.5199,
"address": "n3xPuVEjXswDZYGxTUXq9BKxSYt72DjHKo"
}
],
"blocktime": 1396375900,
"txid": "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb",
"wallet": "2pEQ4Bqu8",
"amount": 0.0025,
"recipother": [
{
"amount": 0.0025,
"address": "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
}
],
"changerecip": "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq",
"senderother": [],
"ledger_i": 48
}
and this is the more readable version:
Code:
amount: 0.0025
blockDateTime: {01/04/2014 20:11:40}
blockhash: "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa"
blocktime: 1396375900
changerecip: "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
comment: ""
confirmations: 5
direction: "send"
fee: 0.0001
firstrecip: "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
ledger_i: 47
netdiff: -0.0026
recipme: Count = 2
recipother: Count = 1
senderme: Count = 2
senderother: Count = 0
txDateTime: {01/04/2014 20:11:40}
txid: "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb"
txsize: 471
txtime: 1396375900
wallet: "2pEQ4Bqu8"
amount: 0.0025
blockDateTime: {01/04/2014 20:11:40}
blockhash: "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa"
blocktime: 1396375900
changerecip: "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
comment: ""
confirmations: 5
direction: "send"
fee: 0.0001
firstrecip: "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
ledger_i: 48
netdiff: -0.0026
recipme: Count = 2
recipother: Count = 1
senderme: Count = 2
senderother: Count = 0
txDateTime: {01/04/2014 20:11:40}
txid: "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb"
txsize: 471
txtime: 1396375900
wallet: "2pEQ4Bqu8"
blockDateTime: {01/04/2014 20:11:40}
blockhash: "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa"
blocktime: 1396375900
changerecip: "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
comment: ""
confirmations: 5
direction: "send"
fee: 0.0001
firstrecip: "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
ledger_i: 47
netdiff: -0.0026
recipme: Count = 2
recipother: Count = 1
senderme: Count = 2
senderother: Count = 0
txDateTime: {01/04/2014 20:11:40}
txid: "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb"
txsize: 471
txtime: 1396375900
wallet: "2pEQ4Bqu8"
amount: 0.0025
blockDateTime: {01/04/2014 20:11:40}
blockhash: "000000007a11632e1040b5c69a67540afab6a128a42e679431952c22a650dcaa"
blocktime: 1396375900
changerecip: "mwdHoRamUYDT1r3wq5mXCXqYfqpSKoifrq"
comment: ""
confirmations: 5
direction: "send"
fee: 0.0001
firstrecip: "mzWQrn4wAtNRZ1fycxHEFJ3wpMb4NbAa34"
ledger_i: 48
netdiff: -0.0026
recipme: Count = 2
recipother: Count = 1
senderme: Count = 2
senderother: Count = 0
txDateTime: {01/04/2014 20:11:40}
txid: "3d7b98a70a9ef1f87d4c95a4fdd25e324a75d399e321f5b138858a03416869cb"
txsize: 471
txtime: 1396375900
wallet: "2pEQ4Bqu8"
For us there is no problem as we can identify the duplicated entries and just ignore them when importing them.
The question is:
Is there some other impact / risk with duplicated entries internally?
Like SelectCoins, Balance stuff, etc?
I dont want to be hateful with that bug reports, I just want to help to identify errors.
Best regards!
The "Address Key Information" dialog box that shows private keys in various formats is missing QR code format.
In armoryd all is working fine.
Its just this "small" problem about the header ptr bug.
@goatpig:
Its not a problem of 0.90.99.5
I reported this problem already on 0.90 version.
@etothepi
I know some problems are not on priority list (maybe this one isnt), as the impact on users is small.
Thats why I asked for the "maybe possibility" for "how to determine healthy state", if there is any possibility.
Best regards
Its just this "small" problem about the header ptr bug.
@goatpig:
Its not a problem of 0.90.99.5
I reported this problem already on 0.90 version.
@etothepi
I know some problems are not on priority list (maybe this one isnt), as the impact on users is small.
Thats why I asked for the "maybe possibility" for "how to determine healthy state", if there is any possibility.
Best regards
It is entirely possible the latest fixed in 0.90.99.5 broke some stuff in armoryd
Indeed, we haven't been keeping up with our changes to armoryd.py as much as we should. We're in the process of piecing together some testnet-in-a-box tests which will automate the process of testing on-blockchain functionality in both the GUI and armoryd.py. If you are an armoryd.py user, I recommend you hold out for 0.91.1, in which armoryd.py will get some more rigorous testing (though it doesn't mean we won't entertain bug reports and fix small things before the 0.91 release
Hi to all!
Question:
Referencing back to "error" about the cpp header is not initialized after broadcasting over armoryd.
As already commented, it get stuck somewhere (well stuck maybe is not the correct definition,
it get stuck of the state, it returns inputs / outputs which are already spend etc..)
Is there a way to determine in the Heartbeat or somewhere else that the service state is not "healthy" ?
So a if we can determine that the service state is unhealthy a possible workaround would be just restarting the Service.
(Btw: Current deployed version: 0.90.99.5)
Some ideas how to determine it?
Best regards!
Question:
Referencing back to "error" about the cpp header is not initialized after broadcasting over armoryd.
As already commented, it get stuck somewhere (well stuck maybe is not the correct definition,
it get stuck of the state, it returns inputs / outputs which are already spend etc..)
Is there a way to determine in the Heartbeat or somewhere else that the service state is not "healthy" ?
So a if we can determine that the service state is unhealthy a possible workaround would be just restarting the Service.
(Btw: Current deployed version: 0.90.99.5)
Some ideas how to determine it?
Best regards!
It is entirely possible the latest fixed in 0.90.99.5 broke some stuff in armoryd
Hi to all!
Question:
Referencing back to "error" about the cpp header is not initialized after broadcasting over armoryd.
As already commented, it get stuck somewhere (well stuck maybe is not the correct definition,
it get stuck of the state, it returns inputs / outputs which are already spend etc..)
Is there a way to determine in the Heartbeat or somewhere else that the service state is not "healthy" ?
So a if we can determine that the service state is unhealthy a possible workaround would be just restarting the Service.
(Btw: Current deployed version: 0.90.99.5)
Some ideas how to determine it?
Best regards!
Question:
Referencing back to "error" about the cpp header is not initialized after broadcasting over armoryd.
As already commented, it get stuck somewhere (well stuck maybe is not the correct definition,
it get stuck of the state, it returns inputs / outputs which are already spend etc..)
Is there a way to determine in the Heartbeat or somewhere else that the service state is not "healthy" ?
So a if we can determine that the service state is unhealthy a possible workaround would be just restarting the Service.
(Btw: Current deployed version: 0.90.99.5)
Some ideas how to determine it?
Best regards!
The .5 version fixes a missing QtNetwork framework on the Mac. Seems consistent.
Not sure. 0.90.99.3 had some quirks and ungraceful handling of malformed/unexpected announcement data. It's possible that the latest announcements weren't compatible. Try 0.90.99.5 and let me know if it doesn't work.
This is from the logs of 0.90.99.3, I'll upgrade to .5 now.
Code:
2014-03-31 11:18 (ERROR) -- Traceback (most recent call last):
File "qtdialogs.pyc", line 9461, in openUpgrader
File "ArmoryQt.py", line 4262, in openDLArmory
File "ui\UpgradeDownloader.pyc", line 196, in __init__
File "ui\UpgradeDownloader.pyc", line 18, in __init__
NameError: global name 'QNetworkAccessManager' is not defined
File "qtdialogs.pyc", line 9461, in openUpgrader
File "ArmoryQt.py", line 4262, in openDLArmory
File "ui\UpgradeDownloader.pyc", line 196, in __init__
File "ui\UpgradeDownloader.pyc", line 18, in __init__
NameError: global name 'QNetworkAccessManager' is not defined
Just updated the downloads and announcements, with 0.90.99.5-testing!
Testing version thread
Bug bounty thread
Please post in the bug-bounty thread if you want to claim a bounty for your bug reports.
I really think this one will work with 10.9.1 and 10.9.2!
Testing version thread
Bug bounty thread
Please post in the bug-bounty thread if you want to claim a bounty for your bug reports.
I really think this one will work with 10.9.1 and 10.9.2!
The secure updater in 0.90.99.3 does nothing for me, it's that known behavior?
Not sure. 0.90.99.3 had some quirks and ungraceful handling of malformed/unexpected announcement data. It's possible that the latest announcements weren't compatible. Try 0.90.99.5 and let me know if it doesn't work.
Just updated the downloads and announcements, with 0.90.99.5-testing!
Testing version thread
Bug bounty thread
Please post in the bug-bounty thread if you want to claim a bounty for your bug reports.
I really think this one will work with 10.9.1 and 10.9.2!
Testing version thread
Bug bounty thread
Please post in the bug-bounty thread if you want to claim a bounty for your bug reports.
I really think this one will work with 10.9.1 and 10.9.2!
The secure updater in 0.90.99.3 does nothing for me, it's that known behavior?
Hi, Im using Armory version .90 and Im trying to change the default folder where it stores the DB (I have an SSD drive and dont want the huge DB there).
I am doing exactly as it says on the Armory trouble shooting page and have changed the target on my short cut to
"I:\Program Files (x86)\Armory\ArmoryQt.exe" –dbdir=I:\armoryDB"
yet it still keeps creating the DB in
c:\users\user\appdata\roaming\armory
wtf am I doing wrong?
thanks for any help
I am doing exactly as it says on the Armory trouble shooting page and have changed the target on my short cut to
"I:\Program Files (x86)\Armory\ArmoryQt.exe" –dbdir=I:\armoryDB"
yet it still keeps creating the DB in
c:\users\user\appdata\roaming\armory
wtf am I doing wrong?
thanks for any help
Make sure it's "--dbdir" with two dashes. I'm super irritated by Wordpress which keeps replacing the double-dashes with single-long-dashes on the webpage, trying to be useful... but screwing it up for people like you!
Also, I recommend, if possible, to just move the whole --datadir, not just the --dbdir: it's simpler if everything is kept in one place (--datadir moves the databases and all wallets and settings)
omg, thank you so much!! ill use --datadir as well. cheers!
Hi, Im using Armory version .90 and Im trying to change the default folder where it stores the DB (I have an SSD drive and dont want the huge DB there).
I am doing exactly as it says on the Armory trouble shooting page and have changed the target on my short cut to
"I:\Program Files (x86)\Armory\ArmoryQt.exe" –dbdir=I:\armoryDB"
yet it still keeps creating the DB in
c:\users\user\appdata\roaming\armory
wtf am I doing wrong?
thanks for any help
I am doing exactly as it says on the Armory trouble shooting page and have changed the target on my short cut to
"I:\Program Files (x86)\Armory\ArmoryQt.exe" –dbdir=I:\armoryDB"
yet it still keeps creating the DB in
c:\users\user\appdata\roaming\armory
wtf am I doing wrong?
thanks for any help
Make sure it's "--dbdir" with two dashes. I'm super irritated by Wordpress which keeps replacing the double-dashes with single-long-dashes on the webpage, trying to be useful... but screwing it up for people like you!
Also, I recommend, if possible, to just move the whole --datadir, not just the --dbdir: it's simpler if everything is kept in one place (--datadir moves the databases and all wallets and settings)
Hi, Im using Armory version .90 and Im trying to change the default folder where it stores the DB (I have an SSD drive and dont want the huge DB there).
I am doing exactly as it says on the Armory trouble shooting page and have changed the target on my short cut to
"I:\Program Files (x86)\Armory\ArmoryQt.exe" –dbdir="I:\armoryDB"
yet it still keeps creating the DB in
c:\users\user\appdata\roaming\armory
same thing if I try and use -datadir, it just ignores it and stays with the same default folder
wtf am I doing wrong?
thanks for any help
I am doing exactly as it says on the Armory trouble shooting page and have changed the target on my short cut to
"I:\Program Files (x86)\Armory\ArmoryQt.exe" –dbdir="I:\armoryDB"
yet it still keeps creating the DB in
c:\users\user\appdata\roaming\armory
same thing if I try and use -datadir, it just ignores it and stays with the same default folder
wtf am I doing wrong?
thanks for any help
Jump to: