I'm guessing it is. Out of my 3 wallets, the one that is only P2Pool mined inputs is the one that won't load.
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 tried .84.5 almost beta and failed.
I tried .82.4 alpha and that worked.
So it looks like it has something to do with the switch between the old splash screen versions to the new instant client versions.
...
I will work on upgrading the Armory version on the offline computer now.
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... |
|
|
|
I made new copies of the watch only wallet from the offline computer. The offline Armory version is .56 alpha. Same problem.
I don't know how to run Armory with the "--debug" flag.
I tried .74 alpha and that worked. I tried .82.2 beta and that worked.
I tried .86 and that failed with the same result.
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... |
|
|
|
Nice initiative!
Not sure if this can be called a bug, but the Armory installer refuses to proceed on a non-admin user account (on Windows.) Could this possibly be changed, or are there good reasons for that? The Bitcoin-Qt installer happily proceeds on a standard account, by the way.
I assume you tried to install it in a non-admin-required directory? Even the "bitcoin:" URL-registration should happen at the user-level, so I'm not sure what would require admin privileges. I just tried installing it in a non-admin directory and I got a UAC dialog asking if I want to allow this program from the internet to make changes to my hard drive. Is that an Admin-required dialog? I even have unchecked the box in my .msi builder that says "Must be admin to install"... hmmm. I wonder if it's something to do with code-signing? Admittedly, I'd prefer users to install it via admin, so it's slightly harder for someone to manipulate the installed files -- but maybe that's pointless with all the root exploits in Windows. Users should have the option to install it as non-admins... I'll add you to the list of 0.1 BTC recipients  |
|
|
|
BTW, I couldn't find where sipa originally posted the test vectors; is this somewhere public? (I took the test vectors from the Armory code.)
Sipa didn't want to release them yet until BIP 32 was final. But after I setup and passed the test vectors, I asked if I could post the code, and he gave approval as long as there was a bold caveat (which I have at the top of that post). I don't know how long it will be before it's final, so don't get too attached yet (or create production code with it). It's being reviewed by a real cryptographer, and should be final afterwards, barring any issues with it. P.S. -- The first CKD test was actually my own test that I came up with before Sipa even had his own implementation. I meant to remove it, because sipa later came up with his own test vectors and made that previous test kind of pointless. The outputs that *are* verified are the 17 public keys and the chain of pow(2,i)-1 children. |
|
|
|
Ever since I upgraded bitcoin-qt to a pre-0.8 test version. Armory will not leave offline mode.
Yes, there is no 0.8 support yet. The Bitcoin-Qt devs left out some important details about the way 0.8+ works, because they didn't think it mattered. It does matter, and I haven't had the time to revamp the low-level blockchain utilities to accommodate it. Figuring that out is near the top of my list, though. On the upside, I think I figured out what has been causing Armory to crash after being open for a long time. And the code needed to fix that, is closely related to the updates I need to work with 0.8. I might be able to do both at the same time. |
|
|
|
I've been having issues with the latest versions of Armory.
Unfortunately I do not remember which was the last working version. I skipped quite a few versions simply because I was busy.
When I updated to any of the last 3 versions, Armory seems to start fine, but after a minute or two of offline mode, it crashes. I'm assuming whenever it's about to switch to online mode.
I'm running Windows 8, latest version of BitcoinQt.
On a hunch, I emptied the Armory folder in roaming and Armory loads fine. When I copied my watch only wallets back into the folder, I experience the crash again.
I've sent a pm.
Unfortunately, the log shows nothing is wrong. Can you do it again with the "--debug" flag? It sounds like the watching-only wallet is corrupted. Can you try re-forking it from the offline computer? What offline version was it created from? I know it won't have all the comments, but I can make you a very quick script to move all your comments/labels over, if it works. |
|
|
|
Bug Bounty Test Drive!Recommendations welcome. Bug reports welcome. Let's find out if this works... If you find bugs, please report them in that thread. If you don't, I'll post a link to this thread from there... I want to make sure there's a clear timeline of bug reports so that duplicate reports are avoided (and multiple payouts for the same bug). |
|
|
|
My last post got me to thinking about what is the very least amount of code to generate private keys completely transparently - where you could see in one glance that nothing is possibly amiss.
And so I took that keyconv program and hacked it into a very simple single text that anyone can paste into a file and compile. Just the math and here it is:
This is the best solution I've seen so far. There's nothing wrong with bitaddress.org but it will take ages to go through the code. Especially the ECDSA math. If you have the skill & patience & background to go through code to verify an implementation, then I suppose this works for you. But seriously, I made Armory specifically to make cold storage accessible to the users that don't want to dig through code, write their own, etc. It has been in user for a year now, without anyone ever losing coins. Put Armory on your offline computer, generate a wallet, print a paper backup (or copy by hand if you don't have an acceptable printer). This is the best kind of "paper wallet" because it is a single code that protects all addresses ever created by the wallet. If you ever need to restore the wallet, you only type in that code, instead of 300 individual private keys. "Create Watching-Only Copy" from the wallet properties window and import it into Armory on your online computer. You can still generate millions of receiving addresses and verify incoming payments with this wallet, yet an attacker cannot compromise it without physically gaining access to the offline computer -- because your private keys are not even touching the internet. And if that's not enough, you can use a USB key to move tx data over to the offline computer, sign it, bring it back and hit "broadcast." It takes about 60 seconds once you get the hang of it. You don't have to like Armory, I just don't know why you wouldn't try it first, since it was designed for precisely what the OP requested. |
|
|
|
There is a bounty of 0.1 BTC per new bug found in Armory 0.86.3-beta, up to a maximum of 3 BTC. This test drive ends on Jan 1, 2013. (at my discretion, I may pay more than 0.1 BTC, depending on the scope/impact/subtleness of the bug) Armory doesn't have enough testers. And the current testers are mostly Armory veterans that have been using it for a while and not doing new-user operations like creating new wallets, printing their one-time backups, etc. So I'm hoping that this post will get some fresh eyes on the app, and also give current testers some incentive to really try to break things. So, I'm going to test bug bounties for a short period of time, to see what kind of response I get. I may extend it in the future, if it turns out to be an efficient way to get testers and find bugs without too much dispute. And I do expect some dispute, but I'm going to try to be lenient about it. That's also why I've set an upper limit of 3 BTC, to limit the impact of this going terribly wrong... What qualifies as a "bug" is anything that impacts usability: I don't really want to give out bounties for grammatical improvements or missing punctuation in dialogs. Though maybe some would argue that I should. What I'm really looking for is things like checkboxes that should be disabled but aren't when using a watching-only wallet, selection dialogs with zero things to choose from, buttons that do nothing when clicked, etc. And obviously crashes, too. Here's a list of well-known bugs that don't count, because I already know about them and there's nothing I can do at the moment: - (1) Armory uses a lot of RAM
- (2) Loading Armory before Bitcoin-Qt is sync'd causes rapid connect-disconnect flickering
- (3) Lack of unicode support (coming soon, actually, just not in 0.86.3).
- (4) Windows systems always detect memory pool corruption and delete it.
- (5) Anything to do with the message-signing dialog -- it's queued to be revamped soon to be more useful (and match Bitcoin-Qt)
- (6) *.deb package is of "bad quality" according to newer versions of Ubuntu
- (7) Armory sometimes crashes after 0.5-6 days (it's not a memory leak, for sure)
- (8 ) Paper backup printing doesn't work in OSX. Please copy the data by hand or copy to another program where printing does work.
- (9) System tray icon does not disappear when Armory is closed (Windows only).
- (10) Unclickable link in version-check window
Here's what you need to do to collect the bounty: - (1) Be the first to post about a particular bug for the current testing version
- (2) If you don't include a payment address in your post, I will assume that I should send the 0.1 BTC to donation address in your signature
- (3) Either post relevant portions of the log file, or send me the log via email or PM (File-->Export Log File)
- (4) Have some patience -- I need to figure out the best way to run this operation. Also, I will send out payments in batches. If 4 people find 3 bugs each, I'll be sending out one tx paying 0.3 BTC to all four people at the end of the day or the next morning (you can request sooner if you're super anxious for some reason).
If you're interested please download the absolute latest: Armory 0.86.3-beta. It's not a testing version, but there won't be another testing version for a while, and I'm sure there's still plenty of bugs to be found here. UPDATE: Also, I've decided that anything in the testing branch is fair game. That is probably more bug-dense, but this little bounty drive will encourage me to do more internal testing before merging anything into that branch (for 0.86.5-testing, I compiled and posted Windows-testing versions above).
Bugs reported (and thus, don't expect a bounty if you just found it): (1) UAC/admin needed even for local installation of Armory on Windows. (2) Wallets with P2Pool payouts crash Armory! (reported here). (3) Missing string replacement on dashboard when user is missing blk*.dat files.
|
|
|
|
This is an interesting concept. The "house" should require a fee to become a member with bet creating abilities. This way the house makes money and the bet creator's history and reputation can be viewed by potential participants.
If I had more time, I'd try to flesh out this idea further. I just wanted to point out that I suspect this is possible for the purposes of the operator of the particular event to assist with bets being placed, without having to actually get a license to operate a gambling operation. Maybe that's wishful thinking. Also, due to multi-signature transactions, credit and reputation would be irrelevant. Both bettors would be committing actual bitcoins to the transaction ... the only way to release them is using the released secret. No trust would have to be involved. It wouldn't surprise me if this was possible, but I haven't thought through the details yet. This would create a lot of work for the house. The site operator(s) would have to verify the winner of every bet. Let's take the OP's example: if the winners weren't instantly published online, how long might it take for the winner to receive their BTC and how much could one expect from the site operator in tracking down any relevant info? To clarify, the idea was that the house simply releases one code publicly before the event that bettors would somehow make part of their betting transactions on that particular event. When the event is over, the house publicly releases one of two secret codes publicly, which cryptographically allows the winner to sign the transaction to himself. Obviously, if the house has to verify each individual bet that kind of defeats the purpose -- this would be one operation per event for the house. I was just saying it wouldn't surprise me if there was a crypto trick that made this possible. You can also use pure multi-signature transactions to do this, but if the loser is a sore loser, there may not be any incentive for him to help you release the coins in your direction. This starts going down the buyer-seller-escrow route, where you could solve this by having each side submit 20% deposit on top of the bet, that they get back when the bet is over, and that way both sides have an incentive for the bet to be completed. It's possible, but may be too complicated without an app specifically designed to facilitate it. |
|
|
|
Please Sanity Check v0.86.3-beta!I just posted a v0.86.3-beta to the new AmazonS3 "bucket." The Get Armory! page now references the new download location, and I need to make sure everyone has access, and that there's no other stupid bugs that will require further fixes before I trigger version notifications. I haven't merged it into master yet, because I don't want to trigger any notifications until I get this sanity check. But I did create a signed tag and pushed it to github: "v0.86.3-beta". You can check that out right now and play with it. ("git tag -v v0.86.3-beta" to verify the signature)
I want to start bug-bounties. Something like 0.1 BTC per new bug you discover. If you report a significant bug, and there's no one else has mentioned it since the last release, I'll send you 0.1 BTC. Of course, this won't be so clean, because what is a "significant" bug? What qualifies as a bug vs. a missing feature? I don't want to be stingy about it, but I also don't want people to start expecting payment for pointing out missing punctuation in a warning box.... or maybe I should be paying for such tiny things...? Please feel free to discuss how I might do execute this idea with the best efficiency. I'm thinking I'll start by doing it for 2 weeks only, and with a maximum of 3 BTC paid out (30 bugs) in that two weeks. That will limit my risk of unexpected abuses. Also, I probably won't send out the 0.1 right away, unless someone requests it. If the bug reports are coming in quickly, I will aggregate multiple payouts into one transaction. I am considering posting it in the main discussion forum, but I might get too much attention.
|
|
|
|
I always make a new wallet to check new functionality with, so you have this approach covered That is not a subtle bug at all! I just tested creating a new wallet and it really fails! I probably didn't notice it because it doesn't trigger if you create the wallet after the blockchain is loaded. It only triggers if the wallet has never been used at the time the initial blockchain scan finishes. I'm currently very busy (writing my master thesis), but have been looking for a way to contribute to the bitcoin comunity (with a degree in computer science and mathematics I think I might have something to give), and after that I'd be happy to help you with anything you might need (I guess code reviews never hurt). I don't think I've ever been as impressed with any piece of software as I am with armory.
Well, thanks! And I'm always happy to have people help out. Dig into the code, maybe even develop new features. If you want to get involved, please email me and I'll give you little homework assignments that will get you acquainted with the code and might be useful, too!
I just fixed the bug in my local copy of the github repo, but github is down for maintenance, so I can't sync any of my other virtual machines in order to compile the new version. Gah! As soon as it's back up, I'll be releasing it officially as 0.86. 3-beta. |
|
|
|
I ran the new version, it said that armory is offline but none of the transactions appeared. Might be because I created a new wallet while it was synching, and got a bunch of these errors: TypeError: Non-hexadecimal digit found
2012-12-22 22:15 (INFO) -- ArmoryQt.py:3199 - Dashboard switched to fully-online mode
2012-12-22 22:15 (INFO) -- ArmoryQt.py:1632 - Syncing wallet: 32h6U5vjR
2012-12-22 22:15 (ERROR) -- ArmoryQt.py:3442 - Error in heartbeat function
Traceback (most recent call last):
File "ArmoryQt.py", line 3300, in Heartbeat
File "ArmoryQt.py", line 1635, in finishLoadBlockchain
File "armoryengine.pyc", line 6835, in detectHighestUsedIndex
File "armoryengine.pyc", line 939, in int_to_binary
File "armoryengine.pyc", line 917, in hex_to_binary
File "encodings\hex_codec.pyc", line 42, in hex_decode all these errors are only linked to the newly created wallet. edit: tried it again, this time didn't do anything at all, the result is still the same, no transactions show up. edit 2: permanently deleted the wallet in question and all transactions suddenly showed up. Crap! As usual, what seemed like an arbitrarily small update to fix something small, resulted in breaking something subtle. I can see how it is possible to have negative values for a number that is encoded as a positive number and would throw that error. Fixed a bug, made another one. I really need to start bug bounties or something. This bug is really only triggered on new wallets, which would be a disaster for new users, but very few users on this thread are creating new wallets. I think I'll start a 0.1 BTC/bug bounty, for a month. If someone has ideas for how to run this in a sane way that won't result in lots of disputes, I'm all for it. I think it could also be a good marketing ploy -- some users would probably start using Armory just to try to get bounties! Looks like I have to fix that bug, and recompile and re-sign everything. Ugh! But thanks, prezbo, you actually saved me a lot of heartache from new users having bad experiences! |
|
|
|
This is an interesting concept. The "house" should require a fee to become a member with bet creating abilities. This way the house makes money and the bet creator's history and reputation can be viewed by potential participants.
If I had more time, I'd try to flesh out this idea further. I just wanted to point out that I suspect this is possible for the purposes of the operator of the particular event to assist with bets being placed, without having to actually get a license to operate a gambling operation. Maybe that's wishful thinking. Also, due to multi-signature transactions, credit and reputation would be irrelevant. Both bettors would be committing actual bitcoins to the transaction ... the only way to release them is using the released secret. No trust would have to be involved. It wouldn't surprise me if this was possible, but I haven't thought through the details yet. |
|
|
|
I like the idea where it's anywhere, anytime for the "moment" . Heck you could be down at Santa Monica Pier and if there is a guy who is throwing up bowling pins and you place a bet if will drop them! Good thinking. Kind of the snapchat of betting where it be for a little bit and dissolve.
I bet there's a cool cryptographic way that this could be assisted by the house, without the house actually taking part in the gambling itself (it would really just be a courtesy). They publish some secret material, and that material is somehow folded into an escrow transaction. When the fight is over, the house would release one of two secrets, depending on the outcome, and that secret is sufficient for the winner to claim the funds. |
|
|
|
Btw, I have a BIP 32 implementation in the "newwallet" branch of Armory.
Perfect, I'll take a look! Sipa created some test vectors for latest BIP 32 revision, and I was able to match them in my code. He's waiting for a response from a real cryptographer before he finalizes it, but at least we've ironed out the intention for BIP 32 and matched our test implementations. I'm posting here just so anyone else that wants to get a headstart on it can see my unit-tested code, and the test vectors that sipa supplied. Just don't go implementing this into production software yet!Here is the unit-test itself, with hard-coded public keys to compare against. Here is the implementation of ConvertSeedToMasterKey() function, and the ChildKeyDeriv() function implemented in the Armory C++ utilities, matching the latest revision of BIP 32 (as of Dec 22, 2012). And Here is the output of my test. It is the same chain displayed twice, all the way up to M/0/1/3/7/15/31/63/127/255/511/1023/2047/4095/8191/16383/32767. One chain is derived strictly from private keys, the other derived strictly from public keys. Anyone using this for their own test only needs to look at the first half. |
|
|
|
Why not just install Armory on an offline computer, and print off your paper backup? You can even print off the first 100 keys by clicking on "Backup Individual Keys", if you so desire. I essentially made Armory just for this purpose... so people don't have to go through crazy command-line, messy compiling operations to get keys offline. If you're willing to keep a computer offline for this purpose, then you can use Armory exactly as it was intended: in addition to printing a paper backup, you "Create a watching-only copy", put it on your online computer, and then you can manage all your BTC without risk of an attacker getting them (the watching-only wallet holds no private keys). Generate addresses for your offline wallet, watch your balance, confirm incoming transactions... If you do the paper backup alone, you're going to have a hell of a time spending or moving those coins. If you do it the Armory way, you use the online computer to create the unsigned transaction, take the tx to the offline computer (or reboot into the offline OS), sign the tx, and then take it back to the online computer to broadcast. It takes about 60 seconds to execute the whole process. http://bitcoinarmory.com/ |
|
|
|
I've been trying to use Armory on netbook (EeePC 1005HAB), and I've run into a couple problems:
1. When I start Armory in online-mode, it hangs at scanning the blockchain. The program says "Connected (0 blocks)" and endlessly scans. I've let it run overnight to no avail.
2. Armory randomly drops the connection to bitcoin-qt and reconnects a second later. This tends to happen a number of times consecutively.
You mentioned that Armory is fairly RAM intensive - could this be the cause? It's running Windows 7 32-bit and Armory 0.86.2-beta.
Thanks,
--winter
If you have 2GB or less, I'm guessing Armory won't work very well (perhaps like what you said). Before SatoshiDice came along, it was fine, but even just indexing pointers to data on disk is over 1 GB now. I started upgrading Armory to switch to disk-based indexing (which really needed to be done eventually, but I didn't realize it was going to be so soon!), but it's turning out to be a pretty substantial upgrade for Armory. It will happen in the next month or two, though ... The bitcoin-qt disconnect-reconnect cycle is a side effect of your system thrashing. It can happen when bitcoin-qt isn't fully sync'ed with the network yet and Armory is struggling to keep up with the blocks, or when you don't have enough RAM to build the blockchain index. I wish I had better news for you... |
|
|
|
|
Show Posts
