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

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.


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.

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).

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.

And I sent you 0.1 BTC for your help.  You and Holliday saved me quite a bit of time I would've spent debugging the P2Pool problem.  Thanks!

My old wallet is loading fine now that I'm on the testing branch!  Thanks a bunch!

I got my OSX brew tap working for the testing branch, too.

https://bitcointalksearch.org/topic/wysenynjas-homebrew-tap-for-all-your-osx-bitcoin-needs-133097

Random update: 

I keep getting some questions about how to get started using Armory and setting up offline wallets, etc.  So I made a Armory Quick Start page.  It's essentially a first draft, but seemed to be useful even in its current form, so I published it already.

Please give me feedback about that too.

Finally chased down the P2Pool issue (actually in 0.86.4) and it appears I fixed the problems with bitcoind/-qt 0.8+.   Not only that, but I got lucky and ran into a bug that only occurs when multiple blocks are received during blockchain scanning.  

Armory 0.86.5-testing for Win64
Armory 0.86.5-testing for Win32&64

If you find bugs, you can report them here or in the bounty thread.  You'll get your 0.1 BTC regardless.  

It works perfectly. The original Pi model B only has 256 MB of memory, though the newer ones have 512. Wallet unlocking takes an order of magnitude more time, but that's to be expected on a low powered chip.

Armory is definitely too RAM-heavy for that.  It was probably swapping like crazy all night.  

This is exactly why I already started a disk-based blockchain utilities in a separate Armory branch, and will eventually transition all of what is used in RAM, to disk (but in a way that is efficient for disk).  It would also improve load times.  I've got a few other priorities first, but I hope to get to that in the next month or two.  Until then, I don't think a system with less than 2GB of RAM will handle online Armory -- and even that may be too small, soon.

However, 1GB of RAM is luxurious for offline Armory!  Offline Armory probably would work on a system with 256 MB.

However, when I do the upgrade, I can't imagine it taking any more than 100 MB, and that would be essentially constant, no matter how big the blockchain is (hence, scalable, unlike the current solution).

---

And I thought I was just about to post about a testing version of bitcoind-0.8+-friendly version of Armory, but I just hit a seg fault in my last test.  Gah!   Back to my cave...

Hi etotheipi,

I have bought an old IBM T41 laptop which has DDR 333 1G RAM and a single core CPU. I planned to make it serve as the online computer in the armory online-offline set.  I installed the Ubuntu10.04 on it. Then installed the Armory newest version and bitcoin-qt.

However, the Armory scanned the blockchain for a whole night and cannot finish it. This is quite weird for me, as I have successfully build an online client in VM with 1G RAM. Do you think it is because that the computer is too old? Do you think I upgrade the RAM to 2G will help?

Holliday:  If I remember, you are in Windows, 64-bit... correct?  I just built a P2Pool-fixed version for Win64 and posted it on S3 with everything else.  It's labeled 0.86.4, though it's not an official release.  It really should be like 0.86.3.002 since I only commented out two lines of code...

Anyways, here's the link:  https://s3.amazonaws.com/BitcoinArmoryReleases/0.86.4-beta/armory_0.86.4-beta_win64.msi

If anyone wants any other version built, I can do it.  I just didn't want to go through the effort if no one else really needed it -- and a lot of such users are linux and compile themselves, anyway.  If you are one of those users, just switch to the testing branch.

I was confused because I thought it was a real release. I won't make an ebuild for it then until there's a real release.

I can make the armory-9999 ebuild always point at the testing branch.

Yes, that is the correct commit.

It's not a real version.  It's more just a way to remind yourself that you're on the testing branch (if your version number is higher than the latest release).  Can you just attach to the that particular branch (testing) instead of the tag?  Or do you need the tag?  I expect a "final" 0.86.4 release would have more than just these two lines of code changed.  It's more like 0.86.4 will accumulate these changes until it's ready.  I have been meaning to setup auto-incrementing super-minor version numbers (so this would be 0.86.4.123), but I haven't decided the best way to do it. 

I'm definitely open to recommendations for how to make this fit into other users' use cases.  It sounds like I'm missing something...

Since there is no tag for 0.86.4, can I assume this version refers to commit be2485ff1d893b5f1bc4ef840b70326e438e58a8?

Well, that was easy!  I commented out exactly two lines of code, and it works!  Those two lines of code were completely unnecessary anyway (trying to catch non-standard transactions, even though Armory doesn't know what to do with non-standard tx).  I guess I should keep a P2Pool wallet around so I catch it next time I break it...

I just started the "testing" branch, and merged this tiny change into it (along with changing the version number to 0.86.4).  @RedEmerald, can you please checkout that branch and test it with your wallet that was failing?  From now on, the "testing" branch will be the place for pseudo-stable updates that I need help testing.  I guess, if people are going to help test, they shouldn't have to keep chasing whatever my current development branch is.  That branch will be merged into "testing" when it's ready for testing.  Imagine that...

Excellent pattern recognition skills!  That does seem like something that might break if I revamped the C++ scanning utilities for multi-threaded support.  And I would expect the symptoms you reported.

Can you point me to a P2Pool-mined tx that I can examine to make sure I know what they look like?  I remember someone complaining about this like 6 months ago, and I figured out how to fix it... I guess I broke it since then.


P.S. - You both get 0.1 BTC bounty!  Mainly because you saved me a lot of heartache trying to figure this out on my own!

I think it does. They come from p2pool and possibly a few from eligius.  I just remembered an old issue where viewing the p2pool payout transactions caused armory to hiccup because of the one non-standard payout.  I wonder if that's related.

I just found a watching-only wallet RedEmerald sent me forever ago because of an eerily similar problem.   I never got around to digging into it, but I will now, if the offline upgrade doesn't work (i.e. upgrade offline, re-create watching-only wallet, re-import online).  I say that, because I could spend a lot of time hex-diving into that wallet for a problem that doesn't exist anymore.  I'm hoping this all just goes away, because of some stupid backwards compatibility issue I introduced in the 9 months since 0.56 was released...

Ack...  not much has changed that I can think of, since 0.56, but that is pretty ancient.  Would you be willing to upgrade the offline version and re-create the watcher wallet?  I just tested making a new offline wallet and importing it from 0.86.3 to 0.86.3 and it works.

I don't suppose you:  (1) used an exceptionally long wallet name or description (there was a bug I fixed many months ago that could cause corruption in this case)? or (2) Tried importing a private key 'ff'*32 (or something very close to that)?

If you are in windows, right-click on the shortcut that is on your desktop, then select "Create Shortcut".  Right click on that shortcut and go to "Properties".  Add " --debug" (with a space) to the end of the "Target" line.  If you are in linux, you can start armory using "python /usr/share/armory/ArmoryQt.py --debug".

This sounds eerily similar to a problem reported by Red Emerald a month ago.  I think he sent me material to help investigate...

I've had a similar problem. I'm going to do some more digging and see if I can figure out what exactly the problem is.