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

Yes, Bitcoin-Qt is  finished synchronizing with the network. After the transaction has passed  3 hours. Armory show: Connected (215194) -all blocks synchronized, but the wallet was empty. But now the coins reappear in my wallet. What was the problem before, I don't understand.
Thanks.

Adding that right now...

all you need is to add the -listen

I used to run bitcoin through tor as a hidden service.  I'll experiment more and write up some nice steps.  However, it should be really simple and nothing should really need to be done to armory since it uses bitcoind for all of it's networking anyway.

The proper way to get bitcoin to use tor is to add "proxy=localhost:9050" (assuming tor is listening locally on the default port) to bitcoin.conf.  No need to mess with tor's listen address.  You will also need "listen=1" so it will be able to communicate locally with armory.

When I had a tor hidden service running, I also had "discover=1" and "externalip=mylongstringofgibberish.onion"  I'm not sure if those options will need tweaking for Armory.

Then start armory with "--skip-online-check."  It would be nice if there was also a flag for "--skip-version-check" to stop that from leaking.

if you use a proxy (as u do with TOR) the -listen is being disabled, so bitcoind dosnt listen anymore to port 8333, therefore u have to put -listen in it too (u did enforce this with ur listen address), you shouldnt change it to port 9050 (default TOR port) since TOR is already listening on this port, bitcoind wont be able to listen then!

Port 8333 is the default listening port for Bitcoin-Qt.   I am not familiar with proxies at all, and never really used any custom CLI options with Bitcoin-Qt.  So I can't really comment any further on this.  But if someone can give me a short list of what needs to be done to get Bitcoin-Qt-already-connected-to-tor, to play nice with Armory, I'll happily post it on my website.

Also, Armory does a version check when it first opens, which can be disabled by going to "Help-->Armory Version..." and clicking "Never check for new versions".  Someone complained about that.  There's also an "online check" to determine if the user has an internet connection -- basically it just checks for google.com.  That can be disabled via --skip-online-check on the CLI.

I managed to get armory to connect to bitcoin-QT while on Tor by changing the default listening address in tor to 8333*, then simply running bitcoin-QT and Armory as usual.  I believe the command --listenaddress** allows you to change the default listening address to 9050 so it will work with the normal Tor/bitcoin-QT settup, but I never got this to work.

*Is this the right default SOCKS address for bitcoin-QT?
**I'm not sure this is the right startup command can you confirm/correct this etotheipi?

Hope this helps.  I typed in a hurry so if detail are missing let me know.

Is Bitcoin-Qt finished synchronizing with the network?  How long has it been since you sent it?  Does blockchain.info show it as having any confirmations (you can right-click on the address in your wallet and click "Show on Blockchain.info")? 

If it has confirmations in Blockchain.info but Armory doesn't show it, then it's likely that for some reason Bitcoin-Qt isn't up to date (still synchronizing?).  The current block (as of this writing) is 215,197.  What does it say in the bottom-right corner of Armory?  If everything is normal, it should say something close, like "Connected (215197 blocks)".  If that doesn't match the latest block on Blockchain.info or blockexplorer, please check Bitcoin-Qt.  In the bottom right you can mouse-over the green checkmark and it should say 215,197.

My Armory client doesn't see the coins in my wallet.
I sent the coins to the address on the Armory, Armory showed them on my balance. But after I closed the program (kill process) and opened it, the address is in my wallet, but coins it does not see. All blocks have synchronized. The client has connected to the network. Blockchain confirmed the coins on the adress. I restarted the client a lot of time. But the balance on wallet is zero.

Hi Alan,

Re: having a lite version of Armory.
Have you looked at the Bloom filter work that should be going into bitcoin-QT v0.8 ?

The Bloom filter is set on the server side so you only download the relevant tx.
Makes it O(size of your wallet). Mike Hearn and Matt Corallo have also been adding support into bitcoinj for it.

For mobile apps it should be good as it reduces the (expensive) data they consume. 

Of course there are several ways to do things.

Updated Windows installers for testing version 0.86.6.  I compiled it before that first round of QR code inclusion, but I will have a separate testing release for that when it's done.

https://s3.amazonaws.com/BitcoinArmoryReleases/0.86.6-testing/armory_0.86.6-testing_win64.msi
https://s3.amazonaws.com/BitcoinArmoryReleases/0.86.6-testing/armory_0.86.6-testing_windows_all.msi

Linux users can just checkout the "testing" branch.  Please test payment-request/clickable-link copy&paste in Windows.  The link copying works in Linux, but it didn't appear to work in my Windows VM, and I'm not sure if that's a VM-ism or real.   The original reason it didn't work was because I used:


And it turned out I needed this tag in Ubuntu:


If this doesn't work in Windows, can anyone recommend how I might get it to work in Windows?

It is, but also necessary.  I need to make an Android app eventually.  And a buddy of mine has already been able to put a wrapper around the Android-Bitcoinj libraries and wrapped my current (soon-to-be-outdated-but-easily-updateable) detereministic wallets algorithms.  I think my first goal will be the simplest:  try to make it possible to use an old Android phone as your offline signer -- though, I haven't quite figured out how to xfer the data yet.  At the very least it should be able to be able to serve as a second-signer and get the data via email and special URL format...





I definitely want to make a corporate version (and charge for it!).  It would probably have to be locked down a bit, though, to prevent employees from swapping their own addresses in for the customer payment addresses.  Actually, there's some other ways that would be fun to discuss right now, but I want to get back to putting all these QR codes in

I'm guessing that such a move would also go some way make an Android version of Armory possible (although I appreciate that recoding it in native Android may be slightly time consuming... )


That's looking pretty sweet! I've always thought since the very beginning of Armory that a watching wallet with QR code capabilities would make an excellent rudimentary till/cash collection box. The idea of a method for taking money whereby the proprietor of any business with a physical presence can trust anyone from their staff to operate it should be hugely appealing. Hell, you could send an employee out of your premises with such a device (charities maybe? bailiffs?  )

I'm starting to be swayed by the idea of having some kind of "lite" mode Armory that follows the Electrum model.  Hell, maybe I could even use the Electrum servers!?  I don't like the reduction in security and the centralization... but it's really not that bad.  It seems to be limited mostly to DoS issues/attacks, not loss of coins.  On the upside, having that as the default mode for a fresh install would bridge the interplanetary-sized gap between Armory and new users (and users with less resources).   I'm going to think about that one...

By the way, I finally spent the time to figure out how to make a custom QRCodeWidget:



I've got some work to do the clean these up and then I can start putting them all over the place.  Right now, the places I can think of are: get-new-addr window, address properties window (from wallet properties), payment-request/clickable-link URL, and menu-based address book [the one where you're just browsing instead of selecting])

Ah, sounds like a rational approach, and it's good to hear that you've already laid significant groundwork for blockchain-from-disk. User friendly Multi-sig sounds like a great security feature to add, bearing in mind that ultimate security is your focus for Armory. Well done on your appearance on AVTM too, who knows where else you might pop up now you've got broadcasting experience under your belt!

I'm under no illusions about the limitations imposed by the RAM usage.  At the moment, Armory is a power-users tool, and it is still serving its purpose even if less users can access it (I'd rather have a toll that provides unique capability to 60% than one that provides the same thing every other program provides, to 100%).  I definitely will get to the [final ] RAM-reduction step, but it turns out that my half-step between here and the full solution was more like a 95% step.  In that case, I might as well just do the full solution and skip the partial solution that would be obsoleted by the full solution anyway.

Besides things like QR codes, my top concern is making multi-sig useful.  With the new wallets, I will be able to setup linked wallets, and make interfaces for creating and storing complex transaction types.  Strictly speaking, the new wallets weren't necessary for this purpose, but there's about 20 things fixed at once with the new wallet design, and this feature is on that list.    Even if usage is limited by the RAM requirements, some people will use it and help me improve it... while I work on the RAM-reduction

Brilliant, pleased you recognise the value (and also interested to see how else you would apply QR codes...) Although, I don't think I'm alone in thinking that disk based blockchain storage would be my top issue; I run Armory in a VM and I'm going to run out of RAM for it altogether pretty soon! The vast majority of your potential user base will probably have less than 4 GB of RAM in their machine, and you could lose a little take-up if people have to dedicate an entire machine to just Armory (although there are of course many more positive reasons to do just that, aside from the single negative reason). I do appreciate that it's almost certainly the most involving/challenging work you have scheduled, and it's a total question of which issue you crack first (and which one you feel to crack first).

Yes!  On my whiteboard behind me (with my ToDo) list, I have a "QR Code Marathon".  Basically, I need to look something up before I can implement it, and that one thing is probably stupid easy, but it's been preventing me from feeling like dealing with it for the last couple months.  And there's like 10 places I wanted to use them....

I'll bump that up on my priority list.  It definitely needs to be done.

I'd like to make a feature suggestion: could you perhaps borrow/adapt the code from Bitcoin-Qt for creating on-screen QR codes to represent a given public key? I've found this feature very useful for transferring coins from a mobile wallet into desktop client wallets. Sadly I can't do it so easily with Armory (massive congrats on the rest of it though, I'm very pleased overall)

OKAY!  I think the bounty system is working.  I have paid out about 21 bounties of 0.1 BTC each, and another slightly bigger bounties for helping me fix things.  A special thanks to subSTRATA who went on a marathon clicking spree and vacuumed up most of those bounties.  AND I got around to fixing some other things I've been meaning to fix for a while!  Most importantly:

• Changed the "Imported" column in addr list to show order-created (or "Imported", as appropriate).  Includes sorting.
• Create Clickable Link / Request Payment to Address now has a working "Copy to Clipboard" button.  It turns out that when you copy HTML to the clipboard, you need a tag prefix to help the receiving app know what's up.  In this case, it was .
• 19 other bugs/suboptimal features!  Mostly:  more descriptive errors/warnings, catching empty entry boxes, strange behaviors with some sequences of events (like changing wallet labels and then backing up individual keys resulted in unprintable 0x00 bytes in the output), etc.  Should be a smoother experience overall.

It's super late, so I'll compile windows versions tomorrow.  But I might as well let the non-Windows users get cracking at the "testing" branch and let me know if anything strange pops up.  Especially look at the two new features above.

---

I've also been tackling the new wallets at full speed (before this bug-fix marathon tonight).  It's turning into a massive effort, but it's also turning into something pretty cool -- the new wallets are going to be highly flexible, extensible, and hopefully somehow not overly complicated at the same time (is that possible?).  I don't know, but at least Armory will be able to use it for some cool features!  But it's probably still a few weeks away before I can get a unit-tested version safe for public testing, and will probably be missing some more advanced features (like chain-code encrypted label/P2SH files that can be safely put in dropbox for persistent backup).   Most importantly, it's setting up everything I need for linked wallets, so I can do two-factor auth with desktop and phone.   Just don't hold your breath for it...