justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
December 30, 2012, 06:29:11 PM |
|
You could do some interesting things with blockchain.info wallet integration.
The most obvious is to allow private key import so that you can use Armory as a backup method for accessing your blockchain.info wallet.
Another thing you could do is have Armory automatically create blockchain.info wallets in order to programmatically use the mixing feature.
Privacy is improved if outputs from different addresses are never combined as inputs to the same transaction. If the user wants to spend a sum larger than any address currently has Armory could warn the user and give him the option to route the transaction through the mixer, incurring a slight delay and fees.
You can also use the mixing feature to help with dust collection in a way that doesn't compromise privacy. If any transaction will create a change output less than a configurable dust amount the change could be sent to an anonymous receiving address, and when the balance of the dust collection wallet reaches a useful amount it could be sent through the mixer back to the Armory wallet.
Of course all these operations can be performed manually, but it would be nice to automate them since that's what computers are for.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
December 30, 2012, 07:14:57 PM |
|
There's a lot of cool things that can be done with Armory. At the moment, I'm letting it fill its niche of trusting no one but yourself, as long as you have the patience to get it setup. There's clearly a high demand for that right now, and third-parties have no effect on Armory users.
I do want to improve dust management. My coin selection algorithm has a good start, but it only checks for how many unique addresses are on the input side, without regard for whether those addresses have been linked already. If I could get that implemented, it would make the dust cleanup problem much better. If you use one address a lot, right now, the dust cleanup should be pretty good. But it could be better.
Mixing is not really "my thing". I'll leave that to the third parties to do, and for users to manually execute through such third parties if they want it. I want to focus on the features that no one really has yet: multi-sig. I want to get two-factor auth via multi-sig implemented and usable, and sooner than later. I know there will be lots of hurdles and inconveniences with it, but the sooner we get going, the sooner we can learn and improve it. And the sooner people get to use their phone as a second-authenticator without actually needing a third-party.
On that note, I've been working on the new wallets, and decided I should just "start from scratch". By that, I mean, take everything I've learned since 12 months ago, and re-do it "The Right Way". It's not completely from scratch though, there's a lot of leftover, useful, tested code I am pulling in. But I think that the disruption right now is worth it in the long-run (like being able to encrypt the public keys/addresses in your watch-only wallet, so that theft of your online computer does not result in the thief knowing your net worth).
|
|
|
|
chrisrico
|
|
December 30, 2012, 07:52:53 PM Last edit: December 30, 2012, 08:07:01 PM by chrisrico |
|
Another thing you could do is have Armory automatically create blockchain.info wallets in order to programmatically use the mixing feature. Creating wallets isn't necessary, as the mixer has an API. If you pass $anonymous=true and $receiving_address=$YOUR_ADDRESS, then the funds received to $input_address (returned by the API) are routed through the mixer to your address. Privacy is improved if outputs from different addresses are never combined as inputs to the same transaction. If the user wants to spend a sum larger than any address currently has Armory could warn the user and give him the option to route the transaction through the mixer, incurring a slight delay and fees.
You can also use the mixing feature to help with dust collection in a way that doesn't compromise privacy. If any transaction will create a change output less than a configurable dust amount the change could be sent to an anonymous receiving address, and when the balance of the dust collection wallet reaches a useful amount it could be sent through the mixer back to the Armory wallet. I really don't think that this is a good feature for Armory to incorporate, for the reasons etotheipi mentioned. Instead, you could have two wallets, "clean" and "dirty". The clean wallet has a bunch of small, unconnected inputs. When you send a transaction, you do so from the clean wallet, selecting inputs with the coin control dialog. Instead of having change, you send whatever is left over to a new address in the dirty wallet. When you run out of funds in the clean wallet, you manually (or through the script I posted a while back) run the coins through the mixer, sending them back to the clean wallet in small chunks.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 03, 2013, 07:00:13 AM |
|
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 <meta> tag prefix to help the receiving app know what's up. In this case, it was <meta http-equiv="content-type" content="text/html; charset=utf-8">.
- 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...
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
January 03, 2013, 11:43:32 AM |
|
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)
|
Vires in numeris
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 03, 2013, 03:05:53 PM |
|
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)
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.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
January 03, 2013, 04:23:13 PM |
|
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)
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. 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).
|
Vires in numeris
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 03, 2013, 06:38:49 PM |
|
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)
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. 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). 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
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
January 03, 2013, 07:26:36 PM |
|
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!
|
Vires in numeris
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 04, 2013, 01:59:46 AM |
|
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 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])
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
January 04, 2013, 02:49:01 AM |
|
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 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'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... ) 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]) 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? )
|
Vires in numeris
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 04, 2013, 02:58:45 AM |
|
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 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'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... ) 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... 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])
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 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
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 04, 2013, 04:11:04 AM |
|
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.msihttps://s3.amazonaws.com/BitcoinArmoryReleases/0.86.6-testing/armory_0.86.6-testing_windows_all.msiLinux 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 <meta> tag in Ubuntu: <meta http-equiv="content-type" content="text/html; charset=utf-8"> <a href="link">Text</a> If this doesn't work in Windows, can anyone recommend how I might get it to work in Windows?
|
|
|
|
jim618
Legendary
Offline
Activity: 1708
Merit: 1066
|
|
January 04, 2013, 10:33:28 AM |
|
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.
|
|
|
|
katyhik
Newbie
Offline
Activity: 10
Merit: 0
|
|
January 04, 2013, 10:33:15 PM |
|
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.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 05, 2013, 12:25:45 AM |
|
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.
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.
|
|
|
|
BookLover
|
|
January 05, 2013, 01:04:58 AM |
|
Someone just asked me about how to run Armory over Tor. I realized that not only do I have no idea, but I've heard users claim they have done it, and I never paid attention. Can someone please explain how to do it? I will add the description to the webpage once I see a consensus.
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.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
January 05, 2013, 01:16:36 AM |
|
Someone just asked me about how to run Armory over Tor. I realized that not only do I have no idea, but I've heard users claim they have done it, and I never paid attention. Can someone please explain how to do it? I will add the description to the webpage once I see a consensus.
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. 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.
|
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
January 05, 2013, 01:23:21 AM |
|
Someone just asked me about how to run Armory over Tor. I realized that not only do I have no idea, but I've heard users claim they have done it, and I never paid attention. Can someone please explain how to do it? I will add the description to the webpage once I see a consensus.
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. 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. 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!
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
Red Emerald
|
|
January 05, 2013, 01:33:35 AM |
|
Someone just asked me about how to run Armory over Tor. I realized that not only do I have no idea, but I've heard users claim they have done it, and I never paid attention. Can someone please explain how to do it? I will add the description to the webpage once I see a consensus.
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. 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 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.
|
|
|
|
|