Topic: Armory - Discussion Thread - page 127. (Read 521829 times)

Works like a charm now! Thanks!

Yesterday So maybe i did missed your updated versions...Ill try again

When did you download it?  I updated the offline bundles last night space because I mixed up the architectures.

Hi,

Just followed the exact instructions on the website to make an offline wallet wit ubuntu.
Used the offline module (.sh) installer. But it gives me 2 broken packages/dependencies.
Armory wont start.

Fresh install and second thing i did was running the installer, nothing more/nothing less..

Ubuntu 10.04-32bit was used.

Hope you can help me out.

etotheipi, what version of Armory do you recommend getting from the git repository for installation on an offline Raspberry Pi wallet?

I see only tags with either a -beta or -alpha suffix. Should I just get the version tagged v0.88-beta, or is there a stable version somewhere that would be more suitable?

Thinking about it, I guess it's possible to upgrade in the future, although I'd like to avoid that, so no new program code is introduced to the system after the offline wallet has been created on the device. But as long as it's signed by your offline signing key (which I presume you keep on an offline device so it's really hard to steal), I guess it's pretty safe to just git clone on an online computer, bring the source code over to the offline wallet and verify its signature there (assuming this can be done without an Internet connection), and then just build it on the offline device.

Just uninstall your current Armory and install the new version, 0.88.1.  That error you originally reported has been fixed.

https://bitcoinarmory.com/get-armory/

So my Armory install is broke? I was the OP of the error that was coming up. I'm not really sure what I'm suppose to do. I didn't do any upgrades or make any changes. And I still have bitcoin in my Armory wallet. I don't know what you mean when you say run it with this argument or whatever. Can you be a bit more detailed?

Thanks

I have got a maybe silly idea, and this is not strictly related to Armory, but since I consider it silly and you are possibly the only one I knew here who is both knowledgeable and friendly enough to help a noob, I think maybe I can post it here to get some advices from you before I decide to make a thread or not....I am sorry.

The idea is to spend bitcoins in a way similar to physical coins to prevent the "race attack". So we know traditionally the currency datas are represented in a special kind of currency data type, as they are not infinitely divisible, when we spend the fiats the smallest denomination is usually one cent/one penny, and any amount can be splitted into a relatively small number of fixed denominations(1 cent, 5 cents, 1 dollar, 5 dollars, 10 dollars....). What if we apply the same way of thinking to Bitcoin, and implement the following feature in the client: create multiple addresses(like hundreds) in a batch, and charge each with a fixed amount of bitcoins(5 BTCs, 2 BTCs, 1BTC, 500mBTCs, 200mBTCs, etc), the amount charged must be a number from a set of "denominations", and the number of addresses should be enough for multiple purchases in a relatively long period of time as each will be only used once during this period. Now whenever the user wants to make a purchase, his bitcoin client will pick a number of addresses with the right combined balance and completely spend them to send transactions to the merchant(no more than 12 are needed to be used for anything cheaper than 10BTCs ATM I guess), then the merchant can simply perform a check of all addresses used by the customer, and refuse to deliver the goods if any of these addresses containing unconfirmed/less than X confirmations transactions, so that the merchant can effectively prevent a race attack, without giving the customer too much inconvenience, what do you think?

Argh!  Just found that there is a real bug here, not user error.  The issue is that i'm not casting the "rpcport" in the bitcoin.conf file to an integer, so it's failing to produce the correct URL when you have any rpcport argument in the bitcoin.conf file.  And for Windows users, there's not a convenient way around this bug.

I can't believe no testers ran into this!  Man, I need more testers...

The only solution I know for working around this with 0.88-beta is to remove rpcport from your bitcoin.conf file, and run bitcoin-qt/bitcoind with the -rpcport command-line argument.  Then run Armory with the -satoshi-port argument that matches.

I hate releasing a bugfix version right after a regular release and triggering notifications again (effectively spamming users).  I guess, I could accumulate these bugs into a v0.88.1-beta version, and silently update it, without triggering notifications.  But still change all the links to point to the new version.  I guess that works...

Did you uninstall the previous version before installing the new one?  At least, you can rerun the installer and choose "Repair Installation".

My Armory just stopped working. It crashes when trying to sync up. Before I start messing around with things, I would like which direction to go in? I do have bitcoin in my wallet. Please advise.



Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: MSVCR90.dll, version: 9.0.30729.6871, time stamp: 0x4fee6073
Exception code: 0x40000015
Fault offset: 0x0005beae
Faulting process id: 0x1f84
Faulting application start time: 0x01ce3cad710e53a1
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\MSVCR90.dll
Report Id: 0edbb14d-a8a1-11e2-be93-180373e36d96
Faulting package full name:
Faulting package-relative application ID:

Thanks! It works now I`ll be back if found any new bugs

Gah!  I missed something!  I fixed the unicode path names, but not if your default datetime format has unicode characters.  That's unfortunate.  You can manually modify qtdefines.py:215 to say "unicode(text)" instead of "str(text)".  I know that doesn't solve it for everyone else...

That's also what happens when I don't have a lot of people testing.  I have conceded that certain bugs will only be found after major releases, and that there will be a v0.XX.1 that will have to happen 1-2 weeks later.  Oh well, there's no real way around it (I don't blame people for being hesitant about testing new versions with their primary wallet).

etotheipi, just for you to know, latest v0.88-beta from github still has issue with unicode when trying to enter settings

Yes, I remember creating the file myself. fixed it, works now! thanks!

Apparently you have a non-numeric port number in your bitcoin.conf file?  Did you create that file yourself?  What's the port number?

I run Windows 8. Every time I try to run Armory, I get this:

Thanks to my googlecode-upload script, I uploaded all the new installers and made these pretty links at the same time!

Windows (32- and 64-bit)
Version 0.88-beta for Windows 32- and 64-bit

Linux (Ubuntu/Debian)
Version 0.88-beta for Ubuntu/Debian 64-bit
Version 0.88-beta for Ubuntu/Debian 32-bit

Mac/OSX (doesn't work for everyone!)
Version 0.88-beta for Mac/OSX

Signed SHA256 hashes (mainly for the OSX installer, which I can't sign, yet)
Version 0.88-beta SHA256 hashes of installers

Well, I'll be damned.  I actually linked both the Win64 and Windows_all versions to the Windows_all download link.  That explains a lot!

I think, for now, I will only post the Windows_all version, and link users to the 64-bit version if they have difficulties.  

OH!  I bet this is the reinstall problem so many people had!  Armory can't start after a fresh install:  because they thought they had the 64-bit version installed previously, and installed the new 64-bit version.  But they actually had the 32-bit version installed.  It doesn't change the fact that the installer should do a full overwrite anyway, but it does make more sense, now.

Is there anything in Armory that takes advantage of the 64bit arch, for performance reasons for example?
If the answer is no, 32bits only releases are enough I would say.