Here are the bounty awards:
jammers - 5
TimS - 15
Helgabutters - 27
zombieslayer9099 - 4
japerry - 1
Bitpeep - 1
oneoctet - 1
Carlton Banks - 1
jouke - 2
justusranvier - 1
STRML - 1
Jammers, TimS and Helgabutters each received 2 bounties for all of their text formatting reports that were caused by internationalization.
Zombieslayer won 2 bounties for best suggestion for the paging control.
Please send me a PM if you think you are owed more bounties than you received.
So far only one of the above people has sent me the information that we need to pay you your bounties. PM that info to me if you are on this list and wish to be paid.
Topic: Armory 0.93 testing release! (with 0.05 BTC bug bounty) - page 7. (Read 35724 times)
Armory's Day of Bug Reckoning is at hand. This is where we tally up and pay the debt of our programming sins (just some of them).
If you want to be paid for any of the bugs that you've submitted to this thread please send me a PM with the following information:
1. Contact Information
2. Name (or alias)
3. Bitcoin Address
4. Date and Time of your most recent bug submission
Later today I will post the tallies (using bitcointalk names). Please review them and let me know in a PM if we've overlooked any of your bugs.
If you want to be paid for any of the bugs that you've submitted to this thread please send me a PM with the following information:
1. Contact Information
2. Name (or alias)
3. Bitcoin Address
4. Date and Time of your most recent bug submission
Later today I will post the tallies (using bitcointalk names). Please review them and let me know in a PM if we've overlooked any of your bugs.
and for anyone who's interested, etotheipi did an interview with me at http://bitcoinsinireland.com/an-interview-with-armory-technologies-ceo-alan-reiner/ and/or https://bitcointalksearch.org/topic/m.10522595 which talks about the release cycle for this build. thanks so much, and to goatpig too for making the database load so quick 
So this happened today...
http://i.imgur.com/7AMFY3j.png
http://i.imgur.com/A5ehPng.png
I'm running core .10 and armory 0.92.99.6. I have it set so that I manually run bitcoin core, and then start armory. This occured after I opened bitcoiin core, then opened armory before bitcoin core had finished its sync.
http://i.imgur.com/7AMFY3j.png
http://i.imgur.com/A5ehPng.png
I'm running core .10 and armory 0.92.99.6. I have it set so that I manually run bitcoin core, and then start armory. This occured after I opened bitcoiin core, then opened armory before bitcoin core had finished its sync.
If I upgrade my cold storage setup to 0.93, would I need to upgrade both the online and offline computer Armorys, or can I just update Armory on the online computer and let Armory on the offline computer stay on 0.92 and still be able to do a cold storage transaction using the two?
AFAIK, you don't have to upgrade your offline copy.
If I upgrade my cold storage setup to 0.93, would I need to upgrade both the online and offline computer Armorys, or can I just update Armory on the online computer and let Armory on the offline computer stay on 0.92 and still be able to do a cold storage transaction using the two?
thanks, will pass along logs. how shall i do that? email them to you? put them here in a forum post?
A support ticket is the best option.
Quote
You should probably be sure to point this out the download page (and in future download links here) so that people stuck on 32-bit machines do not inadvertently overwrite their 32-bit versions with non-working 64-bit versions... just a suggestion.
That's for Windows only, and something we should do at installer level really. We won't remove the link to 0.92.3 till we got a x86 Windows build for 0.93.1.
Yup, I meant only for the future. And if you've never done it in NSIS before, it's as easy as "!include x64.nsh" and then "${IfNot} ${RunningX64}" to check...
You meant no x86 releases for online Armory, correct? (otherwise I'm confused)
Yeah my bad, I derped -_-"
Quote
You should probably be sure to point this out the download page (and in future download links here) so that people stuck on 32-bit machines do not inadvertently overwrite their 32-bit versions with non-working 64-bit versions... just a suggestion.
That's for Windows only, and something we should do at installer level really. We won't remove the link to 0.92.3 till we got a x86 Windows build for 0.93.1.
I notice that this version is 64-bit only (I haven't checked earlier 0.92.99 releases though). Was that intentional? Historically the installs have been 32-bit executables, even on 64-bit Windows. Do you plan to drop support for pre-built Win32 binaries? Just wondering...
(also, an extremely minor nitpick: the installer installs this 64-bit executable into the x86 Program Files directory, probably because the installer itself is a 32-bit app and its directories are being virtualized by Windows)
(also, an extremely minor nitpick: the installer installs this 64-bit executable into the x86 Program Files directory, probably because the installer itself is a 32-bit app and its directories are being virtualized by Windows)
LMDB maps the entire underlying dataset in RAM. Can't address 30GB of data in x86. And that's just fullnode, supernode requires 3x that currently. For 0.93.1, fullnode should be around 120MB so it could function in x86, but we still do not plan on releasing x64 Windows builds for online Armory. There will be a x86 Windows build to support people using Windows on their offline signer (hopefully I'll manage something for WinXP), but it won't be able to sync due to LMDB's RAM requirement.
Thanks for the detailed response.
...but we still do not plan on releasing x64 Windows builds for online Armory.
You meant no x86 releases for online Armory, correct? (otherwise I'm confused)
You should probably be sure to point this out the download page (and in future download links here) so that people stuck on 32-bit machines do not inadvertently overwrite their 32-bit versions with non-working 64-bit versions... just a suggestion.
im trying to test the mac version and it crashes within seconds of being started (every time). (Yosemite 10.10.2)
do you already know about this or do you want any crash logs?
thanks
do you already know about this or do you want any crash logs?
thanks
Sorry. Just now saw this. Can you pass along the logs and, if possible, the stack trace that shows where Armory is crashing? Before doing this, though, can you delete your database? (I had a similar issue long ago, albeit while the new DB was under heavy development.) Go under /Users/*username*/Library/Application Support/Armory/databases/ and delete the contents.
Thanks.
thanks, will pass along logs. how shall i do that? email them to you? put them here in a forum post?
OK, have done that (deleted all the files in the databases folder)... and it still crashes a few seconds after startup.. during the Wallet consistency check.
I have sent you the log from before i deleted the databases, and i will also send you the crash log from after i tried again (deleted databases).
im trying to test the mac version and it crashes within seconds of being started (every time). (Yosemite 10.10.2)
do you already know about this or do you want any crash logs?
thanks
do you already know about this or do you want any crash logs?
thanks
Sorry. Just now saw this. Can you pass along the logs and, if possible, the stack trace that shows where Armory is crashing? Before doing this, though, can you delete your database? (I had a similar issue long ago, albeit while the new DB was under heavy development.) Go under /Users/*username*/Library/Application Support/Armory/databases/ and delete the contents.
Thanks.
thanks, will pass along logs. how shall i do that? email them to you? put them here in a forum post?
My questions:
1.) Would it be possible to import a supernode DB someone else built?
2.) If yes, would the ram requirements be signifficantly lower just to run and maintain the DB after?
3.) Are there any UI changes when running --supernode? Is there a simple way to e.g. check address balances? Or would I basically have to create a new watch only wallet, import the address and the advantage would be instant showing of balance without rescan?
1.) Would it be possible to import a supernode DB someone else built?
2.) If yes, would the ram requirements be signifficantly lower just to run and maintain the DB after?
3.) Are there any UI changes when running --supernode? Is there a simple way to e.g. check address balances? Or would I basically have to create a new watch only wallet, import the address and the advantage would be instant showing of balance without rescan?
1) Yes. It will need to be using the page size as your machine's native page size, so there may be some limitation from one OS to another.
2) Yes and no. The DB will access less data to update the last few blocks, but a lot of that data is spread randomly around the DB, so unless you have a SSD or tons of RAM, expect extreme updating times regardless.
3) No changes in UI yet. Any wallet or private key you import will render quasi instantly (time to compute the paged history). We had planned on adding a plugin to quick look at any address, but that was put on hold. Maybe for 0.93.1
Anyone care to torrent a supernode db? I would love to try. I am not so sure what page size means exactly but i am on x64 Ubuntu 14.04 shall it matter.
I'm probably too late for 0.93, but on the Announcemnts tab, I believe it should only show Notifications relevant to the running version. Right now I see 2 notifications that don't apply to 0.93 (One is all the way back from 0.90).
That did fix it. Wow, is it not a bug in Bitcoin Core that the user's copy of the blockchain can be corrupted like that and not be self-corrected/act as if everything is good?
Armory depends on the blkxxxxx.dat files, which are raw bitmaps of the block data. Core flushes the raw data to disk but doesn't verify the committed data, nor does it bother to delete corrupt data and just appends valid data to it. This will trip Armory on occasions. Eventually we plan on moving to block over p2p, at which point I expect Core will realize the block data it's being asked to produce is corrupt (and maybe do something about it?).
One thing I'm afraid to test: does the new Db build deterministically? Can I run Core 0.9.3 and 0.10.0 with the same 0.93 Armory database?
I expect the current one is "agnostic" (it keeps all block data in DB and resolves last known position in file by header hash). The new format in 0.93.1 won't be "agnostic", but the building will also be a lot faster, and is fully isolated from scanning. If it turns out people will want to match their DB against different blockchain folders, I may just add an option to rebuild the DB (takes about 45sec on my SSD setup) but salvage the scan data.
im trying to test the mac version and it crashes within seconds of being started (every time). (Yosemite 10.10.2)
do you already know about this or do you want any crash logs?
thanks
do you already know about this or do you want any crash logs?
thanks
Sorry. Just now saw this. Can you pass along the logs and, if possible, the stack trace that shows where Armory is crashing? Before doing this, though, can you delete your database? (I had a similar issue long ago, albeit while the new DB was under heavy development.) Go under /Users/*username*/Library/Application Support/Armory/databases/ and delete the contents.
Thanks.
One thing I'm afraid to test: does the new Db build deterministically? Can I run Core 0.9.3 and 0.10.0 with the same 0.93 Armory database?
Is this common or something? Are you suggesting that I delete the Bitcoin Core blockchain and let the entire thing re-download?
Yes
That did fix it. Wow, is it not a bug in Bitcoin Core that the user's copy of the blockchain can be corrupted like that and not be self-corrected/act as if everything is good?
Jump to: