I need both versions tested.  The stable version is perhaps more important for finding bugs, since a significant bug there will require a re-release.  The testing version is expected to have some bugs, and is updated more easily.  I added a link in that first post at the bottom (yesterday) that the "testing" version is now fair-game.  Bugs reported in either one are valid, but not repeatable (if the same bug is in both, I will only give the bounty for the first report).

---

@OpenYourEyes -- I'll toss you 0.1 for that.  Those are both errors that have been there for a while, and on a high-traffic page.  For grammer, send it to me via PM if you think it's warranted.  But I'm not going to really focus on the webpage too much, since it's constantly under construction.

---

@subSTRATA:  Okay, so now onto your plethora of reports.  This is where it gets fuzzy, because I can't give out 36 bounties for closely-related bugs.  And also, some of these are very minor or due to a misunderstanding about the software.  I have to use my judgment here, and say that anything that is exceptionally minor, but still warrants changing something in the code is worth half the bounty.  Also, things that are more of a "clarification needed" than a bug will get half a bounty.

(Each star* is a half-bounty)
(8*)  It sounds like you have never run bitcoin-qt on this particular computer?  Or it's in a non-standard location?  Armory most definitely detects when Bitcoin-Qt is started later, but if it's never been started, ever, it can't re-check for blkfiles.  Thus it only hits this condition when Bitcoin-Qt has never been started before.  Please tell me if this does not match your experience.  *But I have to give this to you, because it does warrant adding "...you may have to restart Armory" to catch this condition.
(9)  This is not an Armory bug as much as a PyQt bug.  And it's not something I can fix.
(10*)  That's actually a very intelligent dialog, which gives you only the options available for your current state (the button text and enabled/unabled changes depending on what wallets you have and your online/offline state).  Since you are offline, there is no way to create new transactions (hence disabled top button).  Additionally, if you were online, the bottom button would say "Sign or Broadcast Transaction".  If you actually have an offline/cold wallet, this makes more sense.  I will modify the text slightly.
(11**)  This is pretty much as-planned, except for the ability to save an empty transaction.  I'll modify it.  (either transaction type can be saved here, depending on whether what is in the box is signed or unsigned).
(12*)  Meh.  It's an OS-specific behavior that is sub-optimal.  But I'm not quite sure how to fix it, nor do I know how to fix it.  I'll give a 0.1 bounty for someone who does figure out how to fix it (it's Windows-only).
(13)  That was an explicit decision due to space constraints.  In expert usermode there is just no space to add those buttons, and the user can still escape with the X or by hitting ESC.
(14***)   I'll count this as 4 half bugs:  The red box should be reset after the error goes away.  The Send-Bitcoins window should not even be accessible in offline mode (it is disabled in when scanning, but apparently not when simply offline).  The -0.00000001 spendable balance obviously is in error.  The "Create Unsigned Tx" button should be disabled in offline mode.
(15)  This was intentional as the truncated version is all that is needed given the space constraints.
(16*)  I suppose the address list could use a refresh here...
(17)  "Empty" and "Unused" can only be evaluated when you are online.  Armory doesn't know whether the addresses are empty or unused.
(18*)  A clarification window may be warranted, but the overall behavior is as-intended.
(19)  Does Notepad++ show links?  It definitely creates links for me when I copy it into a word processor or email.
(20**)  Okay, that's a real bug!  I'll look into that
(21**)  More-intelligent warning is warranted.
(22)  Not all wallets have passwords.  Wallet file could be deleted from the user's app directory without the password.  I chose to use 31 consecutive warning dialogs instead.  That's by design (especially if someone is deleting the wallet because they forgot their password)
(23)  Wallet name standardization is a good idea, but Armory was designed not to care.  And the user rarely ever sees the filename or cares... as long as the word "watch" is in there.  In my own testing, I don't see any behavior warranting code modification.

I count an extra 14 half-bounties here, for 0.7 BTC in addition to your 0.4 yesterday.  If you dispute anything in particular please do so over PM or email and I'll update this post.  I don't want to spam this list anymore.  This is a lot of tiny things, but all of them together do add up to non-negligible polishing improvement.

This concludes 1.6 BTC worth of bounties.  I've got 1.4 more, and I hope we'll find some higher-level bugs, too (although 20 was a good bug that might distract me for a bit...)

See (5) in original post:  I said that anything to do with message signing or EC calc is already known -- they are not exactly broken, but they are buggy.  That whole thing will be revamped in the near future (when I sync my signing algorithm with Bitcoin-Qt).



Yes and no.  The option should be grayed out, but it should also say "Only available when online".  It does say that if Armory is currently scanning the blockchain, but I guess I missed the trigger when you're in offline mode.  I'll give you that one

The reason it's grayed out is because "Sweeping" requires being connected to the network in order to broadcast the sweep transaction (moving all the coins from one address to another).  This can't be done in offline offline.  OTOH, importing is simply saving the key to your wallet file, which does not require an internet connection.


I must give you this one, too.  Even though there's no real user impact, there is an error thrown under-the-hood, and it deserves being fixed. 


That's intentional.  It is essentially a "factory reset".

---

@ subSTRATA:  I do appreciate all these little bugs.  This is actually exactly what I was looking for, for 0.1 BTC each.  But please collect them internally and post them in batches of 5 or something.  I'm starting to feel spammed by the constant notifications.  Also, please PM me a receiving address so I can send you the bounties (I won't send it yet, but I need to add it to my spreadsheet).

---

This is a little fuzzier... I want to encourage people to get involved, but I also don't want to pay people for helping fix bugs that I can take care of on my own in less than 5 minutes.  If you plan to try to fix a bug and want a bounty for it, please PM or email me first.  If it looks like it will save me time, I will happily pay a bounty for it.

You know -- never once in my entire life have I ever clicked on one of those Windows help buttons.  And now that I do, I think it's behavior is correct -- whatever you expect it to do:  it's unavailable.  I don't even know how to override that behavior if I wanted to. 


Bitcoin-Qt wallet files are not compatible with Armory.  So, I actually do not want users to be able to select Bitcoin-Qt wallet files.   When the new wallet files are complete, I'll bring back the "Bitcoin-Qt Wallet Migration" feature, and then there will be a separate dialog for that.  Until then, it would be a bug if it did let you select a .dat file

Yes, that counts!  If it's a blatant programming error, or data is missing from a dialog, etc, that definitely counts.  I only offer 0.1 BTC because I expect lots of little things like this -- which I really do want to find, but there could be lots of them, so I want to avoid going broke over them.



This is a bug I've known about for a very long time.  And I've tried, multiple times to fix it.   But nothing I do works!  (I actually have code in Armory to try to hide the icon just before it closes... not sure why that doesn't work, actually).   You still deserve 0.1 BTC for it, and I will add it to the list of bugs-I-already-know-about.

Post, PM or email me a BTC address and I'll send you 0.2 BTC in the near future.  I can send it right away, but it sounds like you'll be finding more stuff in the near future

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!

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.  

Restart the bounty!  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 Win64 and Win32

Any bug I claim to have fixed but isn't fixed, counts for the bounty.  That means that there's almost guaranteed to be a bug related to bitcoind 0.8+ that I haven't caught.  Let's find them!

...except that the speaker got the question about quantum computing wrong.  I was in the audience, but I was too much of a pussy to stand up and correct him in front of everyone.  Apparently, I should have done so (since he has now been cited by someone), but I'm shy like that -- especially because I was in the back and no one had any idea who I was.  Oh well.

The speaker says that ECDSA is not susceptible to QCs -- that's just wrong.  ECDSA is most definitely broken by QC's, as well as just most asymmetric crypto algorithms on which internet security relies.  But Bitcoin is better prepared to deal with QCs than most other crypto systems: (1) if you never reuse addresses, then no one knows your public keys and thus there's nothing for a QC to solve.  By the time someone gets your public keys, you've already spent the funds, (2) the crypto algorithms in Bitcoin can be changed to quantum-resistant ones.  Given that we'll probably have two decades advance notice before QCs with enough qubits exist to even threaten Bitcoin, we'll have plenty of time to make the switch.

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

I meant, one of the reasons for P2SH was to give users the ability to use complicated scripts without sending such the script to the person paying.  Because such scripts could be long and annoying to copy, and it's really unnecessary for the payer to know/care about what is in the script.  Also it has the advantage of moving the bulky script itself into the TxIn script, which can then be pruned (though that particular advantage is still preserved, here).

It makes sense that linked wallets only create P2SH scripts and distribute those, thus using P2SH as it was intended.  However, in this case, the other party is forced to care about the innards of this P2SH script, because it must see each individual root key, and verify it before accepting the script -- unnecessarily complicating the protocol and kind of defying the original intent of P2SH.

It's workable, just suboptimal.

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 just about to post about how this would seem to be solved using a combination of multi-sig/linked wallets (like described here) and the derived signatures like described in this thread.  But I just realized this doesn't work with P2SH. 

In the case you're talking about, your multi-national corp would probably have something like 5 wallets linked all using 4-of-5 transactions.  But it is expected that all "addresses" given out would be P2SH scripts.  The P2SH scripts would not be verifiable in the same way, since they are just strictly a hash.

You could supply the customer with all 5 root public keys (all five of which are signed) and let them create the P2SH script for you.  As long as the client includes all public keys in lexicographic order (which I think should be a divinely decreed for all M-of-N P2SH scripts, regardless of application), then all parties automatically know what the P2SH script would look like.   

It would technically work, but it's kinda messy.  The messiness can be hidden, but still complicates the payment protocol quite a bit.  But if you did have this, or were okay without P2SH (using regular multi-sig), then it would seem to solve the issue:  The multiple keys are all individually signed, and the customer client will verify all root keys before multiplying them by the per-invoice scalar, and then combining them into a TxOut -- in a deterministic way.

Nice catch!  The hex conversion normally takes uppercase chars, but my little char-counting method doesn't.  I added 1ioQoMa7v2YLGtrqznQhrafvrJdeDBN3c for 0.1 to my list

The problem with Casascius's tool, and all other EC-trick-based multi-sig, is that it doesn't have the same [necessary] flexibility of using network-based multi-sig.
(1) The coins only go 100% to bettor A or 100% to bettor B.  There is no splitting them without trusting one party.  What if the bet needs to be cancelled? 
(2) A user has to give up a private key in their wallet in order to let the other user take the coins.  This is something I never want to deal with as a client developer:  sometimes it's an epic fail to reveal the private key, sometimes it's expected to reveal a private key. 

I think Casascius's tool is pretty cool, and I am glad someone is making it possible to do these types of transactions.  But it's only an 80-90% solution, in terms of being able to make it accessible to a wider audience. 

You can split the risk, using multi-sig transactions:  both bets go into a transaction requiring 2-of-2 signatures to release it -- one from each bettor.  Neither person actually controls the funds, and both have to agree to the final distribution of the funds (by providing a signature), in order for the money to be distributed. If it's not resolved agreeably, neither person gets the money -- so both sides have an incentive to play fairly.  

This is the same idea as proposed for buyer-seller escrow (with the same risks).  The biggest risk is that a sore loser won't agree to unlock the coins for the winner.  You can solve this by both sides putting an extra "risk deposit" that is returned at the end, so the loser still has incentive to complete the transaction.  But unlike buyer-seller escrow, I imagine that the probability of one party losing their wallet before the bet is over is dramatically smaller -- so a third-party is still recommended, it's not critical to have one.

It would go like this:

(1) Bettor A offers bettor B 3:1 odds on the outcome of a bet -- Bettor A would put in 60 BTC, bettor B would put in 20 BTC, and whoever wins gets all of it.
(2) Bettor B agrees with a 10 BTC risk deposit, and sends A his public key (probably via QR code).
(3) Bettor A creates a tx putting in 70 BTC (60 + 10 risk deposit) on the input side and a single output of 100 BTC to a 2-of-2 multi-sig tx using both their public keys.  Bettor A signs it.  (Note that this transaction is not valid because it has 70 BTC of inputs and 100 BTC of outputs).
(4) Better B receives the partial-tx from A, and adds a 30 BTC input (20 + 10 risk deposit).  After B signs it, the transaction is now valid and is broadcast
(5) After the event, three things could happen:
--Bettor A wins:  creates a tx spending the 100 BTC multi-sig:  sending 90 BTC to himself, 10 BTC back to bettor B.   Bettor B signs it and broadcasts
--Bettor B wins:  creates a tx spending the 100 BTC multi-sig:  sending 90 BTC to himself, 10 BTC back to bettor A.   Bettor A signs it and broadcasts
--Something unusual happens and they agree to "cancel" the bet:  create a tx sending 70 BTC back to A and 30 BTC back to B.  They both sign it and then broadcast.

The beauty of this system is that neither party puts their money in before the other:  either they both get the money in at the same time, or neither of them do.  Similarly, at the conclusion of the bet, they both receive their funds at the same time.  And they both have to agree to the payout tx.

This could actually be made into an app, and most of the above discussion would be hidden under the hood.  As long as there is a convenient way to pass tx data between two unassociated phones. 

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

Thanks flatfly.  There is a box that says "Install for Current User Only" which is checked... but perhaps my MSI creator doesn't do that correctly.  Maybe there's a way to force the correct behavior.

The "offline" thing is one of these strange situations... that message is expected to occur for users who are actually on an offline computer, and won't show up if they are on an online computer that isn't finished scanning.  If the user explicitly puts Armory into offline mode but could be online... I don't know what message to display to match their use case.  I would guess that's the correct message...?   I'll think about that.  Either way,  I added your name to my spreadsheet again

I'm glad you like the app -- I was thinking this might be good marketing for Armory, in addition to getting people to help test it.  If you keep digging through it, maybe you can vacuum up all the bounties for yourself   (and I hope you can see why I can't test this myself... there's an extraordinary number of options, actions, and states that Armory can be in for each of those). 

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

I agreed with this statement at first, but I think it will be difficult to trigger on testnet -- the makeup of the network and the miners is significantly different.  You probably don't have the same density and diversity of peers needed to do it -- you need significant propagation of each tx in the subnetworks of nodes that are willing to accept it and mine it.

Not to say it can't be done, I just think the attack will manifest differently on testnet.  

On the upside, anyone succeeding on the test site might make a few tenths of a BTC for their effort.