[ANN] Armory Multi-Sig with Simulfunding [BOUNTY 0.03 per bug]

[etotheipi]

Armory Multi-Signature "Lockboxes" with Simulfunding
Testing Bounty - 0.03 BTC per bug (up to 1.5 BTC)  


Installers for version 0.92 (pre-release 0.91.99.11-beta):
  Armory 0.91.99.11-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.11-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.11-beta for RaspberryPi (armhf)


Offline Bundles:
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.11-beta Offline Bundle for RaspbianPi (armhf)

Signed Hashes:
  Armory 0.91.99.11-beta: Signed hashes of all installers

Check out our Lockbox tutorials:   https://bitcoinarmory.com/using-lockboxes/







EDIT:  Thanks to SimonBelmond for sending us a link to this intro Armory multi-sig intro video:  http://vimeo.com/96983886
EDIT²:  We actually redesigned the interface/dashboard, so his video doesn't show what the latest version looks like, though the process is the same

I am pleased to announce that Armory has finally completed the design and initial testing of "multi-signature lockboxes" in Armory.  This is the first truly generic, fully-decentralized multi-signature interface available for any cryptocurrency.  Armory is innovating multi-sig the same way it innovated offline wallets -- taking a concept that is inherently complex, and making it about as simple as it can be.  It is still an advanced tool, but makes available features that haven't existed before!

Not only that, but the interface works seamlessly with hot or cold wallets, alike!   To understand how powerful this is, consider that you could independently setup 7 different laptops in five vaults around the world, and a signature is required from physically visiting each one, in order to move any of the money.   Yet you can receive money to it and track its balances safely from an online computer (just like a watching-only wallet, it only has public keys).    Or you can setup a 2-of-2 with hot Armory wallets and simply improve your security for the funds held by you and your spouse.  Or somewhere in between.  Really, the flexibility is astounding, and this solution is the "manual transmission" version that requires no third-party services.  It could be executed by any number of anonymous parties using nothing but email or pastebin.  

The interface enables the following operations (and all work as expected with offline/watch-only wallets):

• Create Lockbox:
  
  • Participants:  Provide Public Keys
  • Organizer: Collect Keys, Define Lockbox, Distribute
  • Participants: Import LOCKBOX definition
• Deposit into lockbox (regular):  
  
  • Use regular send-BTC interface
• Deposit (simulfunding, for certain contract types):
  
  • Participants: Create Promissory Notes
  • Organizer:  Merge Notes to Create Simulfunding Tx
  • Participants: Review and Sign Simulfunding Tx
• Spend:  
  
  • Organizer: Create Proposed Spend
  • Participants: Review and Sign
  • Organizer: Collect Signatures & Broadcast

This process uses no centralized servers or third-party services!  Instead, it provides you with chunks of ASCII-armored text which can be circulated to participants via email (inline) and/or saved to USB key to be taken to offline computers to retrieve signatures.  In the future, Armory Technologies, Inc, will be providing servers to facilitate the data exchanges and simplify the process, though we wanted to make sure that a [usable!] truly decentralized solution was available at all times  [Plus, all automated solutions will just build off the manual solution]


Caveats:

• This does not use BIP32 determinstic key chains!  A lockbox is like a single multi-sig address.  If you do not spend the full amount, change is sent back to the same lockbox.  With regular addresses, this is a privacy concern.  With lockboxes, the privacy issues are mostly unavoidable:  the vast majority of transactions on the network still single-sig, thus a multi-sig change address would be obvious even if a new multisig address was created to receive the change.  By the time this matters, Armory will have the BIP-32 linked wallet stuff in place.
• All message formats changed, including those used for regular offline transactions (which are a special case of multisig: 1-of-1).  If you upgrade your online system that creates offline transactions, you would have to update your offline computer to be able to read and sign these new transaction messages.

Other notes:
The best way to do testing is to run a couple instances of Armory at the same time.  All Armory instances on the same computer can share a single Bitcoin-Core instance, but must have separate --datadir=  settings.  Additionally, you will have to set a random --interport to avoid Armory detecting the already-open instance and aborting.  For instance, I do testing with 3 Armory instances, I run them as follows:

[/list]

Code:

python ArmoryQt.py --debug --testnet --datadir=~/.armorytest1 --interport=9913
python ArmoryQt.py --debug --testnet --datadir=~/.armorytest2 --interport=9914
python ArmoryQt.py --debug --testnet --datadir=~/.armorytest3 --interport=9915

The datadir paths must exist before running the above!  If you corrupt your databases by accidentally running on the same datadir with different interports, use the --rebuild option to fix it.  It only takes a few minute on testnet.


And now for the pretty pictures:

Collect public keys from participants to create a lockbox:


Manage multiple lockboxes:



Collect signatures from all devices/parties:


Each user selects a source wallet and destination lockbox to create a promissory note.  Then the organizer merges them into a funding transaction to be signed by all funders


Once the promissory notes are collected, the parties have to sign.  This works identically to spend-from-lockbox (it's the same dialog).  Note that it only shows you the net value difference for each wallet, even though each "funder" is providing both inputs and change.  Armory figures it out.


As you can see, the final transaction has three different input wallets, and change back to those wallets as well.  

[1715619506]

1715619506

[1715619506]

1715619506

[1715619506]

1715619506

[etotheipi]

Reserved!

[gbmracing]

In your 3-of-4 wallet, the pie charts have 3 slices and in the 2-of-3 wallets, the pie charts only have 2 slices.  It seems like the pie slices are off?

I also think you should enable some integrated mobile/email notification system so the recipients get the block instantly.  Secure message maybe?  And in the same way, they should be able to sign and broadcast back to you without copy/pasting anything or any USB.  All self contained in the client.

[piotr_n]

You can use Armory's "lockbox" interface to store coins with 5-of-5 protection, using five cold laptops stored in different vaults around the world.  Each laptop generates its wallet completely independently, offline, and without any knowledge of the other laptops.  The public keys are then combined to create a lockbox where savings can be held.  Transactions that spend money from this lockbox require a visit to all five vaults to boot each laptop to review and sign.  

Or just use it with two regular online computers.  Or somewhere in between.  Use your imagination to meet your security, redundancy and convenience preferences!

From start to finish, there are no single points of failure.  

Not to be rude, but if you hadn't been boasting so much, I would not have pointed out that my software has had such a  feature built in and working for like months already.
Though, tbh, with much less cool name and no fancy GUI
But at the other hand I believe I managed to explain how to use it in a slightly simpler way: http://www.assets-otc.com/gocoin/manual/multisig

[etotheipi]

Not to be rude, but if you hadn't been boasting so much, I would not have pointed out that my software has had such a  feature built in and working for like months already.
Though, tbh, with much less cool name and no fancy GUI
But at the other hand I believe I managed to explain how to use it in a slightly simpler way: http://www.assets-otc.com/gocoin/manual/multisig

It is precisely the "fancy GUI" which is what makes our implementation exciting.  Both cold storage and multisig have existed in low-level tools for quite some time, but most of them require an extremely high level of sophisitication by the user in order to run terminal/interpretter commands, manually collecting input transaction hashes, etc.   Just like with cold storage, creating an interface that hides all the unnecessary details and is usable by non-Bitcoin-experts is quite challenging.  Especially when you assume that any or all devices could be offline and some may be providing multiple signatures (Armory's multi-wallet interface helps make this a smooth experience).

Admittedly, I did not realize that gocoin had these multisig features available.  And if I had known, I would've played with it and provided feedback.  And I wouldn't have boasted so loudly about the "only generic, fully-decentralized interface for multi-signature transactions."  But I do think that what we just released provides a level of multi-sig usability unmatched by any other existing tools out there.  I'll have to make a demo video...

Either way, we really need testers!  And we're paying!  So anyone reading this, I just upped the bounty to 0.03 BTC per bug.  Rig a few instances to run at the same time (or just use multiple wallets), and find some bugs.

[piotr_n]

I personally prefer no GUI, because it gives me a better impression of security and makes the choice of the host environment far more flexible.
But I see where you're coming from; most people these days prefer mouses over keyboards and if they can operate it using only a mouse, they are usually willing to pay for it a few times more.
On a related topic, I heard Bill Gates once said that, according to their research, if a product had a letter X or V in its name, they could sell it for 20% more

Anyway, this specific feature seems very hard to be made user-friendly and secured at the same time.
I spent a lot of time trying to simplify the process, but I agree that it still isn't something that Gavin's granny could handle.
I will be looking forward though to see how other people approached the problem.
Sorry that I have no time to check it out and test a bit in Armory, but I will gladly watch the video, because from description in OP the process doesn't look much simpler than mine.
In fact it seems quite the same. The only difference I see is that you have a central point that collects the signatures from all the parties, whilst in my case people come to add signatures one after another and the last one to sign can just broadcast the transaction out.

[etotheipi]

I spent a lot of time trying to simplify the process, but I agree that it still isn't something that Gavin's granny could handle.

I have no illusions about anyone's grandmother executing this process.  Nor doing regular offline transactions.  But there is a large class of users for whom this is the first usable solution without having to understand tx structure, UTXOs, change outputs, etc.  

The only difference I see is that you have a central point that collects the signatures from all the parties, whilst in my case people come to add signatures one after another and the last one to sign can just broadcast the transaction out.

There is no central authority -- it's fully decentralized.  One person/device prepares the transaction, and whichever device adds/imports the last signature can broadcast it.  It is passed around as ASCII-armored blocks of text that can be emailed, and/or copied to USB to take to offline devices.  We would like to add a central server that would help users pass the data around, further improving the usability for those who want it... but the decentralized solution would always be available.

P.S. -- This is what people pass around to collect sigs (either inline in emails, or save to file):

=====TXSIGCOLLECT-4ogNaap7======================================================
AQAAAAsRCQcAAAAAAf1OAgEAAAALEQkHX/rr6vit6h6hFEtrSevRUWb0ev79VNLukkIjNUNoZj8AAAAA
/QABAQAAAAEGOwaI7hG2eALnVRhP5U9htkL5nR7pkmuhA++lkvmwjgAAAACLSDBFAiALPCTF3jPh238+
0TRiv7078ukWSykh5etoOC92mgHUtgIhANoaevyjicUcXZrBG4B05MCe0b6Ao4oQF1MWratKk51XAUE E
ziXsxcDUeorfEALx23AQ7/850SCxb/a+ZxbqIQ48ExhQgyCnQRF8ljIqOHz+5p7nJrWdfhVy2vtwICfz
vFbMff////8CQHh9AQAAAAAXqRTllz72+r9S3h22NtdNbPS0W/TqhofAcCc0AAAAABl2qRRJvTihhk4j
NbkfeRLljm0F7x58aYisAAAAAIdSQQRaVaMnjUAAEwZ8WtKXeCYt1UlDBNmX3woLIHwh2+sDB8xs5nqY
6iygkHrJZMSUJncnX/g29PgFrv9Sco2BZKh/QQSTtOSfxz3CHvwktSKnps0SiTZwzoLBqyuju1BawtJn
5FvVUfOSJGjflmvJVB8A3Kk6IIbdW14wv8/YpL4yZpfsUq4ISHVla2pwcEwA/////wJBBFpVoyeNQAAT
Bnxa0pd4Ji3VSUME2ZffCgsgfCHb6wMHzGzmepjqLKCQeslkxJQmdydf+Db0+AWu/1JyjYFkqH8AAEEE
k7Tkn8c9wh78JLUip6bNEok2cM6Cwasro7tQWsLSZ+Rb1VHzkiRo35ZryVQfANypOiCG3VteML/P2KS+
MmaX7AAAATQBAAAACxEJBxl2qRTAJVPUOGJ3S2BllgR6HNc32I8NloisMFF9AQAAAAAAAAROT05FAAA A
================================================================================

[Abdussamad]

Armory could so use an HCI person. Multiple headlines screaming for attention, large blocks of text and an interface with so much going on.

[escrow.ms]

My OS: Windows 8.1
I'm using Regular Installation version.

There's no testnet blockchain torrent available in Testnet Armory? I have to sync bitcoin client normally (it sucks with slow net.)
Meanwhile Testnet armory is offline even when bitcoind is running in background.

[etotheipi]

Armory could so use an HCI person. Multiple headlines screaming for attention, large blocks of text and an interface with so much going on.

I have wanted to get someone in here to not only give us some guidance on the interface stuff, but perhaps create some Qt themes for us which would standardize the buttons, headlines, fonts, styles, etc.  I feel like I'm good at making interfaces extremely functional, but I'm all over the place in terms of presented information quantity and style. 

Feel free to make specific recommendations for any of the existing dialogs, and if it's good I'll implement it give you a bounty for it.

Meanwhile Testnet armory is offline even when bitcoind is running in background.

Make sure you disable "Let Armory run Bitcoin Core in the background" from File->Settings.  If it's still offline, it usually tells you why.

[escrow.ms]

Make sure you disable "Let Armory run Bitcoin Core in the background" from File->Settings.  If it's still offline, it usually tells you why.

My armory is offline and Multisig feature doesn't lets me create Promissory Notes. (So technically we need to sync blockchain first right?)
https://i.imgur.com/3Qb8IIU.png

You can use Armory's "lockbox" interface to store coins with 5-of-5 protection, using five cold laptops stored in different vaults around the world.  Each laptop generates its wallet completely independently, offline, and without any knowledge of the other laptops.  The public keys are then combined to create a lockbox where savings can be held.  Transactions that spend money from this lockbox require a visit to all five vaults to boot each laptop to review and sign.

 

(Well Actually After reading this, I thought users will be able to create Promissory Notes in offline Armory. Or maybe I didn't understood process properly.)

[etotheipi]

My armory is offline and Multisig feature doesn't lets me create Promissory Notes. (So technically we need to sync blockchain first right?)

You can't create a promissory note if you don't know your balance/UTXO-set.  The note is a list of all the inputs and a change output that you will be contributing to the simulfunding transaction.  You must pull the input list (UTXOs) from the blockchain.

I would say skip simulfunding for now.  I think that simulfunding might be moved a bit further back in the interface until we get a synchronization server to assist with it.  It definitely works, but it's an awful lot of steps for each of the parties to execute and I'm not sure many users will have the patience for it.  I still want it to be available as-is, but I'll find a way to make it less prominent since I think most users will be using lockboxes for personal savings which doesn't require simulfunding -- it might just confuse them.

[escrow.ms]

Alright, I am waiting for QT to sync, after that i'll try to test it.
By the way, Let's say I am using it for personal savings. I made a new lockbox and added some funds in it using one of my armory wallet. Now what I need to backup to access my lockbox in future? Just my wallet or I have to export lockbox and keep that data safe too somewhere?

Actually I asked this question because it doesn't shows any warning to keep file safe in case of hardware failure etc.

[etotheipi]

Alright, I am waiting for QT to sync, after that i'll try to test it.
By the way, Let's say I am using it for personal savings. I made a new lockbox and added some funds in it using one of my armory wallet. Now what I need to backup to access my lockbox in future? Just my wallet or I have to export lockbox and keep that data safe too somewhere?

Actually I asked this question because it doesn't shows any warning to keep file safe in case of hardware failure etc.

Great question (and worth a bounty).  We should at least add a note about that in the interface.  As long as the relevant wallets are backed up in the regular way, the coins will be recoverable -- though it will be much easier if you backup the LOCKBOX block.  When we do the new wallets, we had planned to put that information into a separate file that could be backed up regularly, such as in Dropbox or similar service.  Rather, you will have the option to store a separate file to hold multisig info and tx/addr comments, with optional encryption (and the data will be stored in both the main wallet and the separate file).

However, this is minor because all the devices must have the lockbox definition, so if you lose it on one system, you can re-export-import it.  Or if it's multiple parties, anyone can give it to you to reimport.  As long as you have the same wallets as before (probably restored from paper), everything will be back to normal.

[rarebitproject]

There is no central authority -- it's fully decentralized.  One person/device prepares the transaction, and whichever device adds/imports the last signature can broadcast it.  It is passed around as ASCII-armored blocks of text that can be emailed, and/or copied to USB to take to offline devices.  We would like to add a central server that would help users pass the data around, further improving the usability for those who want it... but the decentralized solution would always be available.

P.S. -- This is what people pass around to collect sigs (either inline in emails, or save to file):

=====TXSIGCOLLECT-4ogNaap7======================================================
AQAAAAsRCQcAAAAAAf1OAgEAAAALEQkHX/rr6vit6h6hFEtrSevRUWb0ev79VNLukkIjNUNoZj8AAAAA
/QABAQAAAAEGOwaI7hG2eALnVRhP5U9htkL5nR7pkmuhA++lkvmwjgAAAACLSDBFAiALPCTF3jPh238+
0TRiv7078ukWSykh5etoOC92mgHUtgIhANoaevyjicUcXZrBG4B05MCe0b6Ao4oQF1MWratKk51XAUE E
ziXsxcDUeorfEALx23AQ7/850SCxb/a+ZxbqIQ48ExhQgyCnQRF8ljIqOHz+5p7nJrWdfhVy2vtwICfz
vFbMff////8CQHh9AQAAAAAXqRTllz72+r9S3h22NtdNbPS0W/TqhofAcCc0AAAAABl2qRRJvTihhk4j
NbkfeRLljm0F7x58aYisAAAAAIdSQQRaVaMnjUAAEwZ8WtKXeCYt1UlDBNmX3woLIHwh2+sDB8xs5nqY
6iygkHrJZMSUJncnX/g29PgFrv9Sco2BZKh/QQSTtOSfxz3CHvwktSKnps0SiTZwzoLBqyuju1BawtJn
5FvVUfOSJGjflmvJVB8A3Kk6IIbdW14wv8/YpL4yZpfsUq4ISHVla2pwcEwA/////wJBBFpVoyeNQAAT
Bnxa0pd4Ji3VSUME2ZffCgsgfCHb6wMHzGzmepjqLKCQeslkxJQmdydf+Db0+AWu/1JyjYFkqH8AAEEE
k7Tkn8c9wh78JLUip6bNEok2cM6Cwasro7tQWsLSZ+Rb1VHzkiRo35ZryVQfANypOiCG3VteML/P2KS+
MmaX7AAAATQBAAAACxEJBxl2qRTAJVPUOGJ3S2BllgR6HNc32I8NloisMFF9AQAAAAAAAAROT05FAAA A
================================================================================

A standard text format for "sig codes" that can be sent between users is what multisig needs.

Can this become a BIP?  Something like this can become a standard that all the wallets and other services can support.

But, ...

Would it be better to use JSON clear text, so the user can see what tx/out/etc the sig refers to?  Otherwise, users will get several sigcodes mixed up and go crazy.

[etotheipi]

A standard text format for "sig codes" that can be sent between users is what multisig needs.

Can this become a BIP?  Something like this can become a standard that all the wallets and other services can support.

But, ...

Would it be better to use JSON clear text, so the user can see what tx/out/etc the sig refers to?  Otherwise, users will get several sigcodes mixed up and go crazy.

There is very little infrastructure right now requiring interoperability.  Turning this into a BIP before we've even fully spec'd out the design space would simply slow down our ability to innovate these kinds of features.  I'm not against interoperability, but I tried it with BIP 10 when I was doing offline transactions, and everyone on the mailing list was kind of like "meh, none of us are doing offline transactions, you're on your own" (I don't remember exactly what was said, but it certainly didn't go anywhere -- I tried twice).  

The one exception to this is BitPay with Cosign.  I actually talked to RXC from BitPay and he basically said the same thing -- we're happy to do our own things at the moment get all the kinks worked out with our own users, and then create a BIP and both/all commit to it later.

[SimonBelmond]

This cool video should be linked in the top 1 or 2 posts as well (might have missed it when skimming through):

http://vimeo.com/96983886

Edit: And this is the reddit discussion: http://www.reddit.com/r/Bitcoin/comments/26ya9a/armory_multisig_demonstration/

[LOL]

I can "Delete private keys only, make watching-only," without entering in password for that wallet. Selecting the option to print a paper backup does not function, and makes the "Delete" button nonfunctional.

Restoring a watch only wallet via paper backup just temporarily removes the wallet from the UI. Closing and reopening brings it back as a watch only  wallet once again. Watch only wallet has to be deleted for restoration of that wallet with a paper backup.

Please request details if that would be helpful.

[Corelianer]

I watched the video. The whole process looks complicated at the moment to me.

I would expect that if I am in a group of people signing a multisign transaction, that the signature-process is happening in the tool.
At the moment it looks like that I have to send the partly-signed transaction with a file over to the next person via E-mail or another messaging system.
From a technical standpoint I undstand that the transaction needs to be signed by all required parties first, before it can be broadcasted.
On the otherhand would it be very hand if the partly signed transaction would automatically show up on the other person's wallet waiting for approval.

Like: "1 Transaction waiting for approval" type of messaging system.

[SimonBelmond]

I watched the video. The whole process looks complicated at the moment to me.

I would expect that if I am in a group of people signing a multisign transaction, that the signature-process is happening in the tool.
At the moment it looks like that I have to send the partly-signed transaction with a file over to the next person via E-mail or another messaging system.
From a technical standpoint I undstand that the transaction needs to be signed by all required parties first, before it can be broadcasted.
On the otherhand would it be very hand if the partly signed transaction would automatically show up on the other person's wallet waiting for approval.

Like: "1 Transaction waiting for approval" type of messaging system.

I think DarkWallet will eventually have a P2P connection between parties to sign. However, many Armory users will have their keys in an offline system anyway, so they need some kind of transfer like that. Remember, Armory is targeted to the highest security aware users.

Would there be a way to actally embed transactions in the Blockchain which are not yet valid as they are only signed by one party? So for three signatures three times the miners fee would have to be payed, but who cares. would be awesome to use the already in place network for this. I guess the answer is no, but maybe someone knows for sure.

[etotheipi]

Just to offer some clarification on this:

The multi-sig system being introduced here is not intended to be the most convenient way to do multisig.  It's intended to be the most convenient way to do private, decentralized, trustless multisig between any number of online or offline devices without any third-party dependencies and with maximum control over the entire process.

This is an important distinction -- because it is possible to add extra services to automate these steps, but then the whole process becomes dependent on the availability of that service.  And questions arise about the connections between clients, what data is being stored where, who else might be seeing it, are there vulnerabilities in the networking code, etc.  

For the maximum security, privacy, flexibility and control over your multi-sig funds,  this is the way to go.  Not only that, but the services that we will provide to automate this process will simply build on top of this solution, so we needed to build this first anyway.  But our goal for this release (as is with most of Armory, in general) is to provide a system that maximizes security and privacy first with a set of minimum usability requirements (i.e. GUI inteface), then make the result as usable as possible.  

[FrozenBit]

 Truely outstanding releasing this guys! I can only imagine the work required to fully implement this and of course I hope it succeeds! You guys truely are becoming the beacon of bitcoin. Satoshi would be proud.

Truely, this is an outstanding innovation for an amazing team. You guys are the bomb!

[etotheipi]

If I wanted to add, my redeem script that was generated from another client, is this possible?

Armory's multi-sig interface not only handles a plethora of subtle complexities in the process, but it also bundles along all the data that is needed for an offline device to securely review and sign the transaction.  For instance, if the TxOut being spent is P2SH, the offline device might be a signing authority for it, but it wouldn't know without having the serialized script associated with it.  It can't compute the transaction fee unless it is fed all the full, supporting transactions.   Armory also needs a way to identify that multiple inputs and outputs are related.      For example, if someone contributes to a simulfunding transaction using 3 inputs and a change output, it would otherwise look like 3 different funders and there would be a mysterious extra recipient.  The extra bundled data guarantees that Armory can tell you that someone is funding 1 BTC, not a bunch of random inputs adding up to 1.3 and a mysterious output of 0.3. 

These blocks of ASCII text passed around by Armory handle all of these things complexities gracefully.    As such, it will not sign a bare transaction.  All this data must be supplied.  Once we do an official release, we will document these formats and then look at who else is doing multisig and see if we can standardize.

[Corelianer]

Just to offer some clarification on this:

The multi-sig system being introduced here is not intended to be the most convenient way to do multisig.  It's intended to be the most convenient way to do private, decentralized, trustless multisig between any number of online or offline devices without any third-party dependencies and with maximum control over the entire process.

This is an important distinction -- because it is possible to add extra services to automate these steps, but then the whole process becomes dependent on the availability of that service.  And questions arise about the connections between clients, what data is being stored where, who else might be seeing it, are there vulnerabilities in the networking code, etc.  

For the maximum security, privacy, flexibility and control over your multi-sig funds,  this is the way to go.  Not only that, but the services that we will provide to automate this process will simply build on top of this solution, so we needed to build this first anyway.  But our goal for this release (as is with most of Armory, in general) is to provide a system that maximizes security and privacy first with a set of minimum usability requirements (i.e. GUI inteface), then make the result as usable as possible.  

I understand.

[PRab]

I don't think this is actually related to anything Multi-Sig related, but I found it while I was trying to test Multi-Sig.

I have a a normal install of Armory setup on my machine (Windows 7 64bit). I didn't want to mess that up at all so I downloaded the standalone zip version. I unzipped it and used the TestNet shortcut to launch it. Armory automatically launched bitcoind, but showed that it was offline.

After a little bit of experimenting, I was able to fix the issue by copying the settings from C:\Users\PRabahy\AppData\Roaming\Bitcoin\bitcoin.conf to C:\Users\PRabahy\AppData\Roaming\Bitcoin\testnet3\bitcoin.conf. My guess is that Armory writes to the correct file (because the testnet one had data), but reads from the wrong one.

[PRab]

Bug found.

I can add the same public key to the same lockbox more than once. I made a 2 of 3 lockbox, but all 3 public keys are 049cdf7dc590734dff3fbf3c6a3ef086a31a5371a444370fdc4a9661019648e1072fcb05948223c ed0265671ce46a0792bfc9c2289c64c457c5449b5ec419e0276 resulting a lockbox with address 2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8

Once I made that wallet I funded it using the testnet faucet (http://blockexplorer.com/testnet/tx/4e2a5204fb490bfbef933daf045c9998949dee32e61810d14900a294854f9a96) and asking for a donation on IRC (http://blockexplorer.com/testnet/tx/ed7920520a129de3de91efae210882f4958fa45af05e2a88e1303fe7769f9772). Both of these transactions showed up just fine.

I then went to send some coins back to the testnet faucet and ran into trouble. I click Spend Funds -> Create Transaction, then enter the address and amount and click Continue. On the next screen, I see 3 "Sign" buttons and 3 green key holes. I click the first "Sign" button and enter my password. The first "Sign" button disappears and the key hole turns grey. I click the middle "Sign" button and enter my password. The screen stays the same! (The middle "Sign" button is still there and the key hole is still green.)

At this point my funds are stuck in the lockbox.

1J4RV95hjkUNLaZdY2s1TBNuoxNryXvtjf

[PRab]

Not really a Multi-Sig bug.

Launch Armory in testnet mode. Goto Lockboxes screen and switch to the Transactions tab. Right click a transaction and select "View on www.blockchain.info". Results in "Transaction not found" error in web browser (https://blockchain.info/tx/ed7920520a129de3de91efae210882f4958fa45af05e2a88e1303fe7769f9772).

I recommend either hiding the "View on www.blockchain.info" button in testnet mode or linking to blockexplorer instead (http://blockexplorer.com/testnet/tx/ed7920520a129de3de91efae210882f4958fa45af05e2a88e1303fe7769f9772).

[PRab]

Bug found.

Sorry this description is going to be a little more brief. Feel free to ask questions if you need.

Create 3 wallets. Use 2 of them to create a 2 of 2 lockbox. Send funds from the multisig wallet. Check the "Use existing address for change" box and select specify a change address. Pick an address from the 3rd wallet that is not part of the lockbox.

On the validation/signing screen I would expect to see something about the change address not being part of the lockbox.

1J4RV95hjkUNLaZdY2s1TBNuoxNryXvtjf

Edit: After further investigation, it looks like it just ignored the change address that I gave it. The send address was msj42CCGruhRsFrGATiUuh25dtxYtnpbTx and the change was supposed to be mwoDMoqU8j871Ezi8WE4UAQBQrRKgAdmXq, but https://blockexplorer.com/testnet/tx/131f744225a3641ab7a01fb65877a513f58275ee6da869576dbbb3fe2888d854 shows that the change was sent back to the lockbox.

[Simcom]

Hi etotheipi,

Quick question - I have a laptop running Ubuntu 14.04 LTS, and I want to make it my dedicated cold offline computer. Should I install this Offline bundle release?  I first tried to install Ubuntu 12.04.3 as your website suggests to be compatible with the 0.91.1 Offline Bundle, but my laptop would not run this old version of ubuntu, only the newest version of ubuntu supports the computers hardware. So would it be ok to safely use this alpha release on my 14.04 system?  Alternatively I could try to get the 0.91.1 Offline Bundle installed but your website suggests only Ubuntu 12.04.3 (exact) will work.

Thanks!

[PodBayDoors]

FEATURE DISCUSSION

91.99.2 has some very good features, but it makes one key assumption that reduces its usefulness in enterprise situations. Once installed, a user can do anything he/she likes. It assumes that there will only ever be one all-powerful central user, and that user can do everything, create addresses, import wallets, create transactions, and spend coins.

A better assumption for enterprise users would be a hierarchy of login permissioning. Admin-level login that can do everything; maybe even password protected or 2FA controlled (so multiple sign-ins are required for any admin-level changes). Then, the ability to set up users with different permissions (spend Yes/No, create address Yes/No, modify whitelist spend addresses Yes/No, etc).

Even the first-level login control would be a big step, Armory is difficult to use in a risk-managed enterprise fashion without it.

Any Armory experts who want to create such a feature set (or can construct workarounds) please get in touch

[etotheipi]

Awesome, somehow my notifications were turned off on this thread!   Sorry for being unresponsive (especially PRab)!

First of all, I wanted to mention that I haven't forgotten about this bounty.  We've been working hard to fix bugs in lockboxes and make it easier to use without third-party services.  Check out the new dashboard!



And we started some documentation on using lockboxes, and will even be making some videos as soon as we're done tweaking the interface (nothing like creating videos that walk you through an outdated interface!).

@PRab

Thanks for the feedback.  You'll definitely get some bounties!  I just want to respond to a couple points:

(1) Repeated public keys in lockboxes:  this is actually intentional!  Consider this scenario:  There's a CEO and four other officers of an organization.  Realistically, the CEO's signature should carry more weight than the others, but he still shouldn't have complete access to the funds.  So what we do is set up a 3-of-6 lockbox:  his key is repeated twice, and each of the other four officers' keys are included once.  The result is that you need three signatures from the lower-level officers to move the money or only two signatures if the CEO is one of them  (still three sigs but the CEO is providing two of them).  We refer to this as "asymmetric signing authority" and is a useful feature of lockboxes, especially in situations where you may have higher- and lower-security devices, perhaps using the higher- security devices as backup in case the worst happens.

(2) About change addresses:  this is fixed in the latest version which I will release into this thread shortly.  There was some logic that needed to be re-implemented for every user-address-entry widget, which was getting unwieldy, and we hadn't update the change addr box.  We've now consolidated the logic and all address-entry widgets use it (and have the little autodetect label to let you know that Armory recognizes what you entered).  0.91.99.4+ will have this.


@ Simcom

The offline bundle is simply the regular Armory installer bundled with all the dependencies needed to run on 12.04.3.  If you really need to use the latest Ubuntu on your hardware, you can manually fetch the dependencies the same way we do it for the offline bundles.  There's a command-line way and a GUI way ... can describe the CLI way later if needed.  The GUI way is to use Synaptic.  At least in older version of Ubuntu, there was an option in the File menu like "Generate Offline Download Script".  You select the dependencies you need to install (listed below), and it will list all downloads needed for the dependency tree.  The script is just a bunch of wget calls.  When you bring that script to an online computer, it will download all the .debs.  Take it back to the offline computer and again within synaptic, something like File->"Install Packages".   The packages you need are:  libqtcore4 python-qt4 python-twisted python-psutil

@ PodBayDoors

What you describe is what Armory lockboxes are all about.  Armory has made the literal security for single-signature wallets as strong as we can.  Anything else we do to implement things like "segregation of duties" for organizations would be purely artificial -- i.e. we could have Armory enforce multi-factor auth for access to wallets, etc, but anyone with physical access to the machine could bypass all of it by pulling the data off the harddrive, etc.  This could be solved with phsyical- and electronic-tamperproof HSMs used for protecting SSL private certificate data (for like Verisign, etc).  And I hope one day we'll have that.  But until then, we don't want to give anyone a false sense of security about their single-signature wallet(s).

However this thread is all about multi-sig lockboxes which does exactly what you're talking about.  You can have the multiple parties manage the systems separately, so that no one party has access to more than one signing authority for funds.  Again, if you use HSMs you could have each signing authority protected with further access control (like 2 people per device needed to execute signing), but even without that you have all the segregation of duties you need, here.  Each party sets up their own device and merges their public keys into a lockbox.  No one has access to anyone else's.  They might not even know who the other holders are, or how the other devices are secured!   Fully-decentralized, no single points of failure.

[helgabutters]

Approximately 4 seconds into the video, when hitting "Cancel" in the "Import Multi-Spend Transaction" on Windows 7 32-bit, the "Bitcoin Wallet Management" window will pop up and then close.

https://www.youtube.com/watch?v=4xR6ghvsL9c

[etotheipi]

Approximately 4 seconds into the video, when hitting "Cancel" in the "Import Multi-Spend Transaction" on Windows 7 32-bit, the "Bitcoin Wallet Management" window will pop up and then close.

https://www.youtube.com/watch?v=4xR6ghvsL9c

1CpZpDhoFciGCydqw3S73iF8rqbX9D6sxs

Ack, you just reminded me that I need to do something with that menu.  It is tough to describe why thy are there -- mainly you use them if you want to simulfund a regular address or lockbox you don't have loaded.  The lockbox manager requires you to select the lockbox to be simulfunded, and if you try to switch the simulfunding to another address or lockbox, you get an error (it seems unnecessary, but implementation was much simpler).   

In other words, if you want to simulfund a lockbox that you have loaded, you use the lockbox manager.  If you want to simulfund anything else (such as matching donations to a regular bitcoin address), you currently have to use those menu options.  I'd like to figure out how to make both available in a coherent way.

Nothing really to do with your bug, simply stating that I meant to figure out how to clean those up or remove those menu items, and actually forgot they were there, so they've been neglected.  You will get your bounty nonetheless. 

[PodBayDoors]

Thanks Alan for responding, OK I get your points. But if I had Admin privileges and could turn on/off or limit user functions based on login it would be even more useful. Certainly someone compromising the machine as Admin is still a threat (HSM etc would help that as you say).
Here's my scenario: I want a User to be able to create, import, sign, and broadcast multi-sig txns, but not be able to import new public addresses, and not be able to spend single sig from his wallet, or at least only be able to spend to whitelist addresses maintained by Admin. Only Admin can import new public addresses, change whitelist etc. Even better would be daily spending or txn number limits.
Am I missing something? Will pay BTC to someone who wants to consult and figure this out, thx

[helgabutters]

Bug 1: "Manage Multi-Sign Lockbox Info" window in Linux doesn't gracefully stay behind certain other windows. Two examples: https://www.youtube.com/watch?v=j0QoJ3aYjdw

Bug 2/3: Really long "Extended Lockbox Details" on Windows will cause odd resizing issues https://www.youtube.com/watch?v=Q9Qs9qVaKk4
On Linux you won't be able to read all of the details and there is way of knowing if there is any more. You may not agree with what is not being displayed.
I'm not sure if this is considered one or two bugs since they would both be fixed by adding scroll bars.

Bug 4: For all "Required Signatures" lockbox pictures up to 6 have no numbers in them. The 7th one does and makes it very difficult to see anything well.
https://i.imgur.com/3EUHJ3T.png

https://i.imgur.com/Lt1VpU9.png

Bug 5: Non-ascii can be edited in the export of a lockbox and will be imported successfully. Many of the places have "Armory does not currently support non-ASCII characters in most text fields (like £¥áöé).  Please use only letters found on an English(US) keyboard.  This will be fixed in an upcoming release". One example that changes the ID of Wallet #3

Code:

=====LOCKBOX-tcu7JNJJ===========================================================
AAAAAAsRCQcNIplTAAAAAMlSQQRookyi5xjlzOMcwWUFLK6hdg8PrWHG779NPNuc3e2RgyGzriiST4sL
UmbUC/WyMpivrI6/fGdSR9O4nbE78uN9QQRs5JgypL26AhFkb1FHRi+bUCa6YbiQrqz/LTAzYV0ZshUt
EaW/S8l8pkV9V26J6BnaXu1Iu5S0ZladEYLnHWn2QQSJMq+Jy4dAr6tfgZgJs7NT79i9RiVCvj5fVlQw
apUcME/5/ZauRxApiNiJVjsTe480a8QA3umBie+KZRGxK5JRU64FVGVzdDIFdGVzdDIDAAAAGlByaW1h
cnkgV2FsbGV0ICgyanFmUDhuRGspGlByaW1hcnkgV2FsbGV0ICgyanFmUDhuRGspGlByaW1hcnkgV2Fs
bGV0ICgyanFmUN6+HgMp
================================================================================

Minor Bug 1: There is no period after "Click this button to copy a link directoy into Armory" in "Sending from Wallet"

[PRab]

(1) Repeated public keys in lockboxes:  this is actually intentional!  Consider this scenario:  There's a CEO and four other officers of an organization.  Realistically, the CEO's signature should carry more weight than the others, but he still shouldn't have complete access to the funds.  So what we do is set up a 3-of-6 lockbox:  his key is repeated twice, and each of the other four officers' keys are included once.  The result is that you need three signatures from the lower-level officers to move the money or only two signatures if the CEO is one of them  (still three sigs but the CEO is providing two of them).  We refer to this as "asymmetric signing authority" and is a useful feature of lockboxes, especially in situations where you may have higher- and lower-security devices, perhaps using the higher- security devices as backup in case the worst happens.

Sounds like a good reason to add the same public key more than once, but that still leaves the bug that I can't sign the transaction more than once. I would love to return the coins to the testnet faucet, but right now, I can't figure out how to do that.

[helgabutters]

Bug 1: Description for "Sign Simulfunding Transaction" should either be "Reivew and sign a simulfinding ..." or "Review a signed simulfunding ...": https://i.imgur.com/zcqz8zq.png

Bug 2: The first paragraph has "Grey keyholes are already signed.Untitled" where "Untitled" should not be there: https://i.imgur.com/Aa7aVf3.png

Bug 3: Paste this into the Lockbox Extended Info: http://pastie.org/pastes/9285120/text?key=v5a6hwmyobmyh2tnulp7fq
Then sign and attempt to broadcast a transaction through Promissary Notes. This should be most of the relevant log: http://pastie.org/pastes/9285240/text?key=igfpoka4bh50gxpog
Video example: https://www.youtube.com/watch?v=ANn1N3I2J4o

Bug 4: Set a 3-of-3 lockbox and follow the steps in the video: https://www.youtube.com/watch?v=79qSj2K94K4
This should be most of the relevant log: http://pastie.org/pastes/9285250/text?key=p4tfturkj2zbtphysfgjg

[helgabutters]

Bug 1: Overly long names will not fully be shown on screen: https://www.youtube.com/watch?v=CBIwHxvicPM

Bug 2: Main Lockbox Management shows transaction is in block but transaction information displays not in block yet: https://www.youtube.com/watch?v=1a2GMHLKknU

Bug 3: Amount of BTC recieved through notification is showing both actual amount and change address amount (which is not controlled by anything in this wallet) / At about 17 seconds in: https://www.youtube.com/watch?feature=player_detailpage&v=fGqYngHGCYA#t=17

Bug 4: Trying to set a Lockbox Bare or P2SH as a change address: https://www.youtube.com/watch?v=3fuWzQmFmVs

Bug 5: In "Create Simulfunding Promissory Note" if no BTC amount is given and you hit "Continue":
'You did not specify an amount to promise!
The extra ' should be removed

[etotheipi]

Thanks Alan for responding, OK I get your points. But if I had Admin privileges and could turn on/off or limit user functions based on login it would be even more useful. Certainly someone compromising the machine as Admin is still a threat (HSM etc would help that as you say).
Here's my scenario: I want a User to be able to create, import, sign, and broadcast multi-sig txns, but not be able to import new public addresses, and not be able to spend single sig from his wallet, or at least only be able to spend to whitelist addresses maintained by Admin. Only Admin can import new public addresses, change whitelist etc. Even better would be daily spending or txn number limits.
Am I missing something? Will pay BTC to someone who wants to consult and figure this out, thx

Going forward, this kind of thing makes sense for us to do.  In fact, your comments inspired this thread, and I think that will be one of the first things we implement when we start figuring out how to better satisfy small-business type use cases.  I hadn't considered the idea before that you could make sure the key is encrypted with multiple passwords, thus enabling better access control on consumer hardware as long as there is operational security to back it up.

@PRab

Just fixed the repeated-public-key issue.  Will release an update this week that will enable you to sign your transactions back to the faucet

@helgabutters

Thanks so much for the feedback!  Especially for all the useful videos showing the bugs!  It's been extremely helpful. 

I think I fixed most of the issues you identified, except for some of the longstanding sizing issues and quirks running Armory on Linux.  Mostly what I've done is I've imposed a maximum character size on all the free-form entry fields (like prom note labels, etc), or limited the number of characters displayed. 



With the new lockbox dashboard and a bunch of these quirks fixed, I'll have a new version for you to test midweek and you can collect more bounties. 

[helgabutters]

With the new lockbox dashboard and a bunch of these quirks fixed, I'll have a new version for you to test midweek and you can collect more bounties. 

Awesome! I've been using Armory for years now and it is hands down my favorite bitcoin wallet.

You seem like you do a lot of the stuff yourself, if you need help with anything else give me a PM. I'm not a coder but I do network administration/security research/pentesting and I can help with things such as documentation, support, servers, maintenance, testing, etc.

Also, I just want to verify that as of now there is no way to getting armory on testnet in OSX, correct?

[etotheipi]

With the new lockbox dashboard and a bunch of these quirks fixed, I'll have a new version for you to test midweek and you can collect more bounties. 

Awesome! I've been using Armory for years now and it is hands down my favorite bitcoin wallet.

You seem like you do a lot of the stuff yourself, if you need help with anything else give me a PM. I'm not a coder but I do network administration/security research/pentesting and I can help with things such as documentation, support, servers, maintenance, testing, etc.

Also, I just want to verify that as of now there is no way to getting armory on testnet in OSX, correct?

Thanks! 

Armory is now a company, and we have a few full-time devs.  I still do the "feature innovation" like multi-sig, which I've been anxious to do for months/years and have already implemented six times over in my head.  When my current "vision" for Armory is complete, then I'll let some of the other guys do fun stuff like this    Plus, it's no small task to learn the subtleties of Bitcoin the way that is needed to implement things like this securely/properly. 

So yeah, all the multisig stuff I'm doing myself, with the others helping out, doing code reviews, fixing bugs and generally learning about what I implemented.  But they are covering the other parts of project so I can focus on my vision, such as armoryd, blockchain engine upgrades, better testing frameworks, etc.

Speaking of that, one of the big things for this release is a much more featureful armoryd.  It's not complete yet, so I won't call for testing, but it will be by the time we release 0.92-multisig, and will feature multi-wallet, multi-sig, and have a full suite of unit/functional tests.  PM me if you'd like to discuss how you could contribute.  We'd love to get more testing resources, especially if there's some security background involved!

As for testnet on OSX:  should be no problem.  You'll have to run it from the command line and use "--args" as the first CLI arg, otherwise OSX doesn't pass them along.  I believe it would look something like

Code:

open ArmoryQt --args --testnet --debug

[SimonBelmond]

Question: If I create let's say a 6/9 lockbox and want to spend some funs from there, is it possible to send the unsigned tx to all 9 keyholders and have them sign the transaction. Can I then fuse it together once I have six signatures? Or do all the 6 participants have to sign sequentially? Would be really great if they could all sign in parallel.

[etotheipi]

Question: If I create let's say a 6/9 lockbox and want to spend some funs from there, is it possible to send the unsigned tx to all 9 keyholders and have them sign the transaction. Can I then fuse it together once I have six signatures? Or do all the 6 participants have to sign sequentially? Would be really great if they could all sign in parallel.

Yup, you can sign in parallel.   Both regular multi-sig spends and simulfunding. 

If you look at the screenshot I posted a few up, you'll see that the latest version organizes everything into "Organizer" and everyone else.  In all operations, the organizer simply communicates with each other party/device indepdently, and merges the results. 

[etotheipi]

Finally, we have a solid beta/testing release of 0.92!

Let's start the testing machine again:  Grab 0.91.99.7-beta through the secure downloader and Armory will verify all signatures for you!  (Help->Update Software)  If you don't have access via secure downloader, use the links below.

Installers for 0.91.99.7-beta:
  Armory 0.91.99.7-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.7-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.7-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.7-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.7-beta for Raspbian (armhf)

Offline Bundles:
  Armory 0.91.99.7-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.7-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.7-beta Offline Bundle for Raspbian (armhf)

Signed Hashes:
  Armory 0.91.99.7-beta: Signed hashes of all installers

The interface has been redesigned, tons of tests have been added, and armoryd.py has gotten a lot of TLC!   We are already using it on our offline computers, and maintaining quite a bit of company funds now using mixtures of online and offline computers controlled by different officers.   It's pretty smooth! 

[PRab]

Bug report:

Stuck with multiple Armory icons in the task bar.

Steps:
Launch Armory (Mainnet)
Launch Armory (Testnet)
Testnet Armory complains that it is already running and exits automatically, but the icon stays in the taskbar.
The Testnet icon is unresponsive to any clicks.

Looks like Testnet Armory didn't actually exit completely. I had to kill it from taskmanger.

Edit:
Scratch that, it looks like Testnet is completely broken. I try to launch it and it creates the tray icon, but never comes up. If I look in taskmanager, I can see that it launches bitcoind with the testnet parameter.

2014-06-29 13:03 (ERROR) -- ArmoryUtils.pyc:1159 - Determined that exec dir is C:\Program Files (x86)\Armory\armoryengine but it does not exist
2014-06-29 13:03 (ERROR) -- Traceback (most recent call last):
  File "ArmoryQt.py", line 7280, in <module>
  File "armoryengine\Timer.pyc", line 99, in inner
  File "ArmoryQt.py", line 503, in __init__
  File "ArmoryQt.py", line 875, in loadArmoryModules
  File "ntpath.pyc", line 96, in join
TypeError: object of type 'NoneType' has no len()

[etotheipi]

Bug report:

Stuck with multiple Armory icons in the task bar.

Steps:
Launch Armory (Mainnet)
Launch Armory (Testnet)
Testnet Armory complains that it is already running and exits automatically, but the icon stays in the taskbar.
The Testnet icon is unresponsive to any clicks.

Looks like Testnet Armory didn't actually exit completely. I had to kill it from taskmanger.

Edit:
Scratch that, it looks like Testnet is completely broken. I try to launch it and it creates the tray icon, but never comes up. If I look in taskmanager, I can see that it launches bitcoind with the testnet parameter.

2014-06-29 13:03 (ERROR) -- ArmoryUtils.pyc:1159 - Determined that exec dir is C:\Program Files (x86)\Armory\armoryengine but it does not exist
2014-06-29 13:03 (ERROR) -- Traceback (most recent call last):
  File "ArmoryQt.py", line 7280, in <module>
  File "armoryengine\Timer.pyc", line 99, in inner
  File "ArmoryQt.py", line 503, in __init__
  File "ArmoryQt.py", line 875, in loadArmoryModules
  File "ntpath.pyc", line 96, in join
TypeError: object of type 'NoneType' has no len()

There's actually two things going on here:  

(1) Do not use auto-bitcoind in testnet mode.  I've tried a couple times to get that working, but it's non-trivial.  For testnet, you'll have to run Bitcoin Core manually and disable the option in the menu.  This is good anyway, if you plan to run multiple Armory instances -- you can have all of them connect to the same Core instance.
(2) I see the problem with the path... I have that path in my exec directory, but didn't realize that lacking that path causes it to hard fail.  Very easy to fix, and will make sure I have that in the next iteration.  For now, to run in testnet use --disable-modules.

Actually, on the second one above:  can you check your testnet log file for an error that looks like this and tell me what it is?

Code:

ERROR: Determined that exec dir is ______ but it does not exist

[PRab]

Actually, on the second one above:  can you check your testnet log file for an error that looks like this and tell me what it is?

Code:

ERROR: Determined that exec dir is ______ but it does not exist

2014-06-29 17:20 (ERROR) -- ArmoryUtils.pyc:1159 - Determined that exec dir is C:\Program Files (x86)\Armory\armoryengine but it does not exist

I installed Armory to C:\Program Files (x86)\Armory and can confirm that there is nothing called armoryengine in there (either file or folder).

As soon as I added --disable-modules to the shortcut everything worked fine (including autostarting bitcoind in testnet mode).

[PRab]

Looks like only 1 out of my 2 bugs got fixed.

When I add the same public key to the same lockbox and click sign, it now signs for all the same public keys. Cool, that's good.

Now when I add a custom change address that is not actually the lockbox, it shows the change address as a receiving address. Cools, that's better than before. The bug I am seeing now is that in this state, when I try to click "Broadcast" it doesn't do anything. It is a 2 of 3 lockbox and all 3 keyholes have a green check mark next to them, so I believe I should be able to broadcast the transaction.
Edit: Oh, this might not be related to the change address... I just tried a normal transaction without a custom change address and got the same behavior.



Final note, I like the new dashboard, but a the address isn't on it. To me the address is one of the most important pieces of information, but it is hidden on the Info tab. This took me a minute or 2 to discover so that I could request testnet coins from the faucet.

[etotheipi]

Looks like only 1 out of my 2 bugs got fixed.

When I add the same public key to the same lockbox and click sign, it now signs for all the same public keys. Cool, that's good.

Now when I add a custom change address that is not actually the lockbox, it shows the change address as a receiving address. Cools, that's better than before. The bug I am seeing now is that in this state, when I try to click "Broadcast" it doesn't do anything. It is a 2 of 3 lockbox and all 3 keyholes have a green check mark next to them, so I believe I should be able to broadcast the transaction.
Edit: Oh, this might not be related to the change address... I just tried a normal transaction without a custom change address and got the same behavior.



Final note, I like the new dashboard, but a the address isn't on it. To me the address is one of the most important pieces of information, but it is hidden on the Info tab. This took me a minute or 2 to discover so that I could request testnet coins from the faucet.

If you ever hit a button and it doesn't do anything, there's an error being thrown under the hood.  Please check the logfile and post the error or copy the logfile to pastebin or something. 

You're absolutely right about the address!  I should put it on the funding row.  There's plenty of space when the "Simul" checkbox is not checked.    Thanks (definitely deserves a bounty!)

I just fixed the pathing bugs, and was about to release it as *.8, but maybe I'll put in that  address display widget.  Then I'll do .8 later tonight.

[PRab]

If you ever hit a button and it doesn't do anything, there's an error being thrown under the hood.  Please check the logfile and post the error or copy the logfile to pastebin or something. 

http://sebsauvage.net/paste/?f6d444852057d1bc#TO+vb9H47emZRiP0Vb5c8o9HYkRij74RSBfvySy+CWM=

I believe my error should be in there. I tried it multiple times.

When I restarted Armory, I was able to send once without any problems, but the problem came back the second time I tried to send.

[helgabutters]

Bug 1) On testnet, in Manage Multi-Sig Lockbox Info, right click on one of the IDs > "View address on blockexplorer.com" and it takes you to "Invalid address"

Bug 2) Typing in 3 letters and then selecting "Click here for more information about this transaction" in the "Review Offline Transactions" window (nothing happens):
http://pastie.org/private/ijwmwhdc1xdsme1a7tnu0w

Bug 3) In Windows 7 download an update for Armory through the Secure Downloader and save with offline signature. The file downloaded has a "," added to the end of the file name and is also displayed in the Download complete dialog box.

Bug 4) Help > Verify Signed Package has a title bar that just says ArmoryQt

[etotheipi]

Final note, I like the new dashboard, but a the address isn't on it. To me the address is one of the most important pieces of information, but it is hidden on the Info tab. This took me a minute or 2 to discover so that I could request testnet coins from the faucet.

You're absolutely right about the address!  I should put it on the funding row.  There's plenty of space when the "Simul" checkbox is not checked.    Thanks (definitely deserves a bounty!)

How does this look?

[PRab]

How does this look?

Can I ask for it to be in a QR code also?

[SimonBelmond]

Feature request, not related to multi sig: When Armory is connected I would love to see the number of connections bitcoind has to the network. I have only recently started to open port 8333 so I can help the network as I am runnng Armory anyway and have a fast connection. Now how do I check the number of connections in Armory? Maybe there is a good way. I just think on the bottom where it states the number of blocks and shows connected in green would be a great space to add this. Could be a similar icon to what is known from Bitcoin-QT. Maybe just as a tool tip when hovering over. Could be that I am missing something?

[neha]

Hi, I have a question. When we use multi sig. Can the transaction be created by the person who initially made the wallet or can a transaction be created by any of the people who are part of the group? Please confirm.

[SimonBelmond]

Hi, I have a question. When we use multi sig. Can the transaction be created by the person who initially made the wallet or can a transaction be created by any of the people who are part of the group? Please confirm.

You can export the lockbox an import it on any other instance of Armory also multiple instances. However, let's get this confirmed by etotheipi.

[neha]

No, What I mean is can all the members of the multisig group create a new transaction or can it be only made by the initial author?

[etotheipi]

No, What I mean is can all the members of the multisig group create a new transaction or can it be only made by the initial author?

Anyone can create the transaction as long as they have imported the lockbox.  They don't even have to be a signer.  The lockbox block is basically a watching-only wallet for your multi-sig.

[neha]

So if we dont share the lockbox, then they cant create a transaction but they can still sign the transaction created by us? Correct?

Thanks for the help.

[etotheipi]

So if we dont share the lockbox, then they cant create a transaction but they can still sign the transaction created by us? Correct?

Heh, kinda.  If you "Use Bare Multisig (no P2SH)", Armory should be able to recognize its own key and be able to sign without the lockbox.  I think.  Testers: try it!

Otherwise, it uses P2SH which is totally opaque and you must have the lockbox in order to even recognize it's relevant to you.

[neha]

Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

Moreover, if we have a 2 out of 7 pool, then if 1 user signs it and sends the file to the balance 6 users and if 2 out of the 6 open it approximately the same time and sign and broadcast, does it send the money twice from the wallet?

I am sorry if these questions seem too much but we are exploring using armory for our new service that we will launching soon. Thanks in advance.

[CircusPeanut]

Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

Moreover, if we have a 2 out of 7 pool, then if 1 user signs it and sends the file to the balance 6 users and if 2 out of the 6 open it approximately the same time and sign and broadcast, does it send the money twice from the wallet?

I am sorry if these questions seem too much but we are exploring using armory for our new service that we will launching soon. Thanks in advance.

The money can only be sent once. Only one of the signed transactions will be accepted into the a block first. The bitcoin software will never allow both signer's broadcasted versions of the transaction into the block chain. That would constitute a double spend.

As an aside, I would be weary of participating in a 2 of 7. Unless there is a trivial amount of money in that lockbox, somebody is placing a lot of trust in the other participants.

[neha]

As an aside, I would be weary of participating in a 2 of 7. Unless there is a trivial amount of money in that lockbox, somebody is placing a lot of trust in the other participants.

This is the reason I want that transaction creation should be handled by us but signing/verifying be given to a few members of the board. Their only job would be to check if the transactions are correct and then sign. But we want a system in which the other members cannot create transaction.

Also, does each transaction need to be signed or bulk transactions can signed at once?

[CircusPeanut]

This is the reason I want that transaction creation should be handled by us but signing/verifying be given to a few members of the board. Their only job would be to check if the transactions are correct and then sign. But we want a system in which the other members cannot create transaction.

Also, does each transaction need to be signed or bulk transactions can signed at once?

The signers must all have a copy of the lockbox.

Using the Armory application each transaction can only be signed one at a time.  

With the ArmoryD API you have more options. For instance you can implement an auto signer. This would make your lockbox less secure though.

[etotheipi]

Fixed the testnet-startup-fail-in-windows bug, as well as made the regular-funding row four buttons plus your address string.  There was plenty of space, and I tried to used it efficiently, though I agree that it should be painfully obvious how easy it to receive money to the lockbox!

If you're currently running any version 0.91+, use the secure downloader within Armory
Help->Update Software (yes, I know the interface is messy -- but it does work if you futz with it enough)

Installers for 0.91.99.8-beta:
  Armory 0.91.99.8-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.8-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.8-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.8-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.8-beta for Raspbian (armhf)

Offline Bundles:
  Armory 0.91.99.8-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.8-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.8-beta Offline Bundle for Raspbian Raspbian armhf

Signed Hashes:
  Armory 0.91.99.8-beta: Signed hashes of all installers

[SimonBelmond]

OK. First of all THX again for doing all this work. Simulfunding was a great surprise and is a hell of a feature which I would not have expected when trying out the lock boxes. I had some good and bad investments with Bitcoin so far. However, I have only made good donations.  



Please add one of your many awesome Question marks with tool tip. No need for a Manual with armory. These things explain almost everything and you learn a lot about the Bitcoin protocol and more.



There seems to be a strange line break there and "Untitled."
"Cannot be signed by you" However, both watching-only wallets are marked as "mine". Therefore the comment should rather be that the signature cannot be given from this instance of Armory, and then explain the conditions (keys are not here or not your wallet). Whatever, doesn't seem 100% correct. Maybe a "light" green would be good in case you can even cover it with the architecture.

What about Simulfunding of normal single key addresses? What about if I want to set up a 10 party 0.1 BTC simulfund to give to Armory? Would you have to set up a 1/1 lockbox for that?

Just in case you haven't seen it:
https://bitcointalk.org/index.php?topic=607046.msg7594421#msg7594421

old version 0.91.99.7 on Win7 x64 SP1  

Edit:stuff, typos

[etotheipi]

Please add one of your many awesome Question marks with tool tip. No need for a Manual with armory. These things explain almost everything and you learn a lot about the Bitcoin protocol and more.

Yeah, that's one of those things that should be under super-expert feature.  There limited uses for using regular multisig over P2SH, but they do exist (having transparent public keys in the blockchain can assist with automated tools that are tracking multisig addresses they are signers for).  I'll add a (?) thingy

"Cannot be signed by you" However, both watching-only wallets are marked as "mine". Therefore the comment should rather be that the signature cannot be given from this instance of Armory, and then explain the conditions (keys are not here or not your wallet). Whatever, doesn't seem 100% correct. Maybe a "light" green would be good in case you can even cover it with the architecture.

Yeah, I don't use the "is mine" or "belongs to someone else" distinction here.  If we can come up with something clean to say, I'll change it.  Otherwise, I'm sure the user will figure it out

What about Simulfunding of normal single key addresses? What about if I want to set up a 10 party 0.1 BTC simulfund to give to Armory?

I struggled with simulfunding of regular addresses -- there's no reason the same code can't be used for it, but it didn't fit cleanly into the lockbox dashboard.  So I added a "Multisig" menu to the main window, and you can do arbitrary simulfunding from there.  I want to unify the interface somehow, but not quite sure yet how to do it.  Either way, feel free to try out all the same features from that menu instead.  (by the way, "arbitrary" means arbitrary recipients.  But not arbitrary inputs:  I still haven't found a good way to build into the UI the ability to simulfund with Lockboxes... shouldn't be too hard though)

[SimonBelmond]

Oh! I have to edit my post above. Simulfund to normal addresses works like a charm. Let's try this, Hope this is fun!

I provide a promissory note to donate 0.1 BTC to Armory in case 9 others will sign such a note as well. I also volunteer to merge, will sign as well if someone else does.

Good Night to all!

SimonBelmond


=====PROMISSORY-BXawafsM========================================
AQAAAPm+tNk0AQAAAPm+tNkZdqkU/jlZ2yUPJHrXJPKvVDnKMui+PbGIrICWmAAA
AAAAAAAETk9ORQAAADQBAAAA+b602Rl2qRQr06rLV1tKFjqiCqIbmKi2S5SieYis
oFJXAQAAAAAAAAROT05FAAAAECcAAAAAAAAB/csCAQAAAPm+tNmtl2qQvnz+VwOB
Z/7r6iXqJqK5XZocYa0YQc57zVPlUwAAAAD9SAIBAAAAA7z9A4cXL7lfm6phJ3IH
11Sy475b5lN4jdXVLjygfP5oAQAAAItIMEUCIQCP+/tm7ZuJWqJ3dtkyk1HygXiz
HUyF2/vM2vLy+BJZrQIgaPoWGSL87KrVQjxxLs1HE0cwOb24sYHuPFeXYA7R0BYB
QQSgU2UmdsQ4WVcBAFhnXZ5bq8CWt+1TM1EKNx+FUSJ87fUVyWSOLWRvfApIVxlF
b3gy+XXlVahaX7WvRZoUcPVa/////+rpt/i7q4eULcwWx8RgP63nCFDmEgoeRiW2
R87wupK0AAAAAItIMEUCIBoz9hb4rPr9NOC3BQDRviAWABpMF/3+JogB56wXTEfv
AiEArD2/Pd4GobYuRdym1g5SGY/QEzjTBWNZ4Z4qRuTuVAwBQQSgU2UmdsQ4WVcB
AFhnXZ5bq8CWt+1TM1EKNx+FUSJ87fUVyWSOLWRvfApIVxlFb3gy+XXlVahaX7Wv
RZoUcPVa/////4gkcX6AzyyLAvVHm17w+lTsqz+Maq+Mubwn6ZIryVItAAAAAItI
MEUCIHwS3GvPi2Ca7SZtjzFt5nhRjGu9+WyV+1lbz9sUBNEGAiEA3cKVHcMs6oEo
0M4NLaSazPr5Ny09tHhF5jP/RbO/sNQBQQSgU2UmdsQ4WVcBAFhnXZ5bq8CWt+1T
M1EKNx+FUSJ87fUVyWSOLWRvfApIVxlFb3gy+XXlVahaX7WvRZoUcPVa/////wEw
EPABAAAAABl2qRQJVnTA871Z1djsUHlQLsnjYjbFFYisAAAAAAAIQlhhd2Fmc00A
/////wFBBE3p1mnv57raAbJtPdkCsoY1qu327aN+OsnmwkmxQ7DQ5CF0jg78C6wc
xiDTAwv+AD8b/aikZ6/Eqj/bTigjAXAAAERTaW1vbkJlbG1vbmQgd2lsbCBtZXJn
ZSBhbmQgc2lnbiBpZiAxMCBvZiB0aGVzZSB3aWxsIGJlIHBvc3RlZCBoZXJlIQA=
================================================================

[PRab]

Downloaded the 0.91.99.8-beta and there is still a some sort of glitch with sending multiple times from a lockbox.

1st broadcast - success.
2nd broadcast - no response to button push.
3rd broadcast (still same screen as 2nd) - success.

2014-06-30 17:39 (INFO) -- ArmoryQt.py:5533 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-06-30 17:39 (INFO) -- ArmoryQt.py:5475 - Switching Armory functional mode to "Online"
2014-06-30 17:39 (INFO) -- ArmoryQt.py:5533 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-06-30 17:40 (INFO) -- TxFrames.pyc:682 - Change address behavior: Feedback
2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3751)

  01000000 01672b62 9e210d2f bdcc234c 2cb7eef6 12e93654 a3f2f78f 8976029b
  3250bdbd 68000000 00fda701 00483045 022100b9 5a4aed80 d26fe1ad e77f4ca3
  b3f0bfe5 5d546da2 6125d64b 813751b0 4b2c6202 2041c1f6 a61eb946 65d38b5e
  acd34dfb 0a54cb9f 8281c9da 17af20bb 59a7d3be be014830 45022100 b95a4aed
  80d26fe1 ade77f4c a3b3f0bf e55d546d a26125d6 4b813751 b04b2c62 022041c1
  f6a61eb9 4665d38b 5eacd34d fb0a54cb 9f8281c9 da17af20 bb59a7d3 bebe0148
  30450221 00b95a4a ed80d26f e1ade77f 4ca3b3f0 bfe55d54 6da26125 d64b8137
  51b04b2c 62022041 c1f6a61e b94665d3 8b5eacd3 4dfb0a54 cb9f8281 c9da17af
  20bb59a7 d3bebe01 4cc95241 049cdf7d c590734d ff3fbf3c 6a3ef086 a31a5371
  a444370f dc4a9661 019648e1 072fcb05 948223ce d0265671 ce46a079 2bfc9c22
  89c64c45 7c5449b5 ec419e02 7641049c df7dc590 734dff3f bf3c6a3e f086a31a
  5371a444 370fdc4a 96610196 48e1072f cb059482 23ced026 5671ce46 a0792bfc
  9c2289c6 4c457c54 49b5ec41 9e027641 049cdf7d c590734d ff3fbf3c 6a3ef086
  a31a5371 a444370f dc4a9661 019648e1 072fcb05 948223ce d0265671 ce46a079
  2bfc9c22 89c64c45 7c5449b5 ec419e02 7653aeff ffffff02 e0a69d21 00000000
  17a914fa d89dde6d 08c5b2d3 d04ab80d 29b6b64c e7cc9187 00a3e111 00000000
  1976a914 1430e7f7 bf01c7a2 69453743 96d8d0cd 96e5eb05 88ac0000 0000
2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3752)
Transaction:
   TxHash:    b2a0a275adbce9ebe20660f985d8ef821465e50dcdb9e5ea878a9a803d4cb012 (BE)
   Version:   1
   nInputs:   1
   nOutputs:  2
   LockTime:  0
   Inputs:
      PyTxIn:
         PrevTxHash: 68bdbd50329b0276898ff7f2a35436e912f6eeb72c4c23ccbd2f0d219e622b67 (BE)
         TxOutIndex: 0
         Script:     (00483045022100b95a4aed80d26fe1ade77f4ca3b3f0bfe55d546da26125d64b)
         Sender:     2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8
         Seq:        4294967295
   Outputs:
      TxOut:
         Value:   563980000 (5.6398)
         Script:  OP_HASH160 (2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8) OP_EQUAL
      TxOut:
         Value:   300000000 (3.0)
         Script:  OP_DUP OP_HASH160 (mhMiPwvKT8rGU9ehL2mxa1HqiYcb6GV9r8) OP_EQUALVERIFY OP_CHECKSIG

2014-06-30 17:41 (INFO) -- ArmoryQt.py:3754 - Sending Tx, 12b04c3d809a8a87eae5b9cd0de5651482efd885f96006e2ebe9bcad75a2a0b2
2014-06-30 17:41 (INFO) -- Networking.pyc:278 - sendTx called...
2014-06-30 17:41 (INFO) -- ArmoryQt.py:3756 - Transaction sent to Satoshi client...!
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Received!
Amount:  3 BTC
Recipient:  Wallet "Primary Wallet" (2QidxBjZ8)
2014-06-30 17:41 (INFO) -- TxFrames.pyc:682 - Change address behavior: Feedback
2014-06-30 17:41 (ERROR) -- Traceback (most recent call last):
  File "ui\MultiSigDialogs.pyc", line 2967, in doBroadcast
  File "armoryengine\Transaction.pyc", line 810, in pprintHex
IOError: [Errno 9] Bad file descriptor

2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3751)

  01000000 0112b04c 3d809a8a 87eae5b9 cd0de565 1482efd8 85f96006 e2ebe9bc
  ad75a2a0 b2000000 00fda401 00473044 0220095a e27ac269 6bc3941c 4b309459
  e05d2e68 7f063e0f 161b993b 117209a9 5af80220 1346f9f2 81182b77 81db27b5
  bb791dad 50d7be6a 724982ae dd0ca4f3 92d18b24 01473044 0220095a e27ac269
  6bc3941c 4b309459 e05d2e68 7f063e0f 161b993b 117209a9 5af80220 1346f9f2
  81182b77 81db27b5 bb791dad 50d7be6a 724982ae dd0ca4f3 92d18b24 01473044
  0220095a e27ac269 6bc3941c 4b309459 e05d2e68 7f063e0f 161b993b 117209a9
  5af80220 1346f9f2 81182b77 81db27b5 bb791dad 50d7be6a 724982ae dd0ca4f3
  92d18b24 014cc952 41049cdf 7dc59073 4dff3fbf 3c6a3ef0 86a31a53 71a44437
  0fdc4a96 61019648 e1072fcb 05948223 ced02656 71ce46a0 792bfc9c 2289c64c
  457c5449 b5ec419e 02764104 9cdf7dc5 90734dff 3fbf3c6a 3ef086a3 1a5371a4
  44370fdc 4a966101 9648e107 2fcb0594 8223ced0 265671ce 46a0792b fc9c2289
  c64c457c 5449b5ec 419e0276 41049cdf 7dc59073 4dff3fbf 3c6a3ef0 86a31a53
  71a44437 0fdc4a96 61019648 e1072fcb 05948223 ced02656 71ce46a0 792bfc9c
  2289c64c 457c5449 b5ec419e 027653ae ffffffff 0250cdb6 12000000 0017a914
  fad89dde 6d08c5b2 d3d04ab8 0d29b6b6 4ce7cc91 8780b2e6 0e000000 001976a9
  14b2953e 4affec23 597a79ca 0b374949 f6e77b5d 8d88ac00 000000
2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3752)
Transaction:
   TxHash:    8cdf93d8c2429bce748ed8dc929db25f543492774c04a0771d36b3c0dd6d0aeb (BE)
   Version:   1
   nInputs:   1
   nOutputs:  2
   LockTime:  0
   Inputs:
      PyTxIn:
         PrevTxHash: b2a0a275adbce9ebe20660f985d8ef821465e50dcdb9e5ea878a9a803d4cb012 (BE)
         TxOutIndex: 0
         Script:     (004730440220095ae27ac2696bc3941c4b309459e05d2e687f063e0f161b993b)
         Sender:     2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8
         Seq:        4294967295
   Outputs:
      TxOut:
         Value:   313970000 (3.1397)
         Script:  OP_HASH160 (2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8) OP_EQUAL
      TxOut:
         Value:   250000000 (2.5)
         Script:  OP_DUP OP_HASH160 (mwoDMoqU8j871Ezi8WE4UAQBQrRKgAdmXq) OP_EQUALVERIFY OP_CHECKSIG

2014-06-30 17:41 (INFO) -- ArmoryQt.py:3754 - Sending Tx, eb0a6dddc0b3361d77a0044c779234545fb29d92dcd88e74ce9b42c2d893df8c
2014-06-30 17:41 (INFO) -- Networking.pyc:278 - sendTx called...
2014-06-30 17:41 (INFO) -- ArmoryQt.py:3756 - Transaction sent to Satoshi client...!
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Sent!
Amount:  3.0001 BTC
From:    Lockbox 2-of-3 "Lockbox 2 of 3" (YaGTwqNK)
To:      Wallet: "Primary Wallet" (mhMiPwvKT8rG...)
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Received!
Amount:  2.5 BTC
Recipient:  Wallet "Third Wallet" (3C8N8sMzN)
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Sent!
Amount:  2.5001 BTC
From:    Lockbox 2-of-3 "Lockbox 2 of 3" (YaGTwqNK)
To:      Wallet: "Third Wallet" (mwoDMoqU8j871E...)

[CircusPeanut]

Downloaded the 0.91.99.8-beta and there is still a some sort of glitch with sending multiple times from a lockbox.

1st broadcast - success.
2nd broadcast - no response to button push.
3rd broadcast (still same screen as 2nd) - success.
.
.
.

I tried to reproduce this bug, and failed.

I assumed it something to do with zero conf change, but I was able to spend that change fine. I'm still not sure how that is not a problem, but I was able to do it.

This is testnet right, I assume that this address is testnet: mwoDMoqU8j87....

And the amounts are too big for main net unless you are stupid or wealthy or both

How old are those lockboxes?

If you pulled from previous version of the Armory repo and used an older version to create those lockboxes maybe your problem is caused by lockbox incompatibility. They did change a bit from the first time Alan let people try out lockboxes.

I mention these tries in case they spark any ideas on how to reproduce this bug.  Please let me know if you think of anything. Sometimes it is the strangest things that makes the difference on reproducing a bug.

It's rare that I can fix what I can't reproduce, and even then it's hard to trust the fix.

[etotheipi]

There does continue to be an error related to print statements in Windows.  I believe that once Armory passes through py2exe, that stdout no longer exists and therefore any print/pprint statements will fail with "Bad File Descriptor".  CircusPeanut:  I assume you are trying to reproduce from python-executed code, correct?  Try running from the installed version and/or rebuilding from the MSVS project and using the .exe. 

I thought I had removed all the print statements.  They are never necessary, usually just left over debugging artifacts that should be harmless.  After all, there should always be a stdout, right?  I will go over it again and make sure there are no remnants left.

[teste]

Hi,

1- What is the reason of have 1 of 2 (m-of-n)?
2- I don't understand why is possible to edit a created lockbox.

Sorry if the questions doesn't make sense.

[CircusPeanut]

Hi,

1- What is the reason of have 1 of 2 (m-of-n)?
2- I don't understand why is possible to edit a created lockbox.

Sorry if the questions doesn't make sense.

#1 is a good model for a joint account. Especially married people.

#2 good point. It seems like it would only be a good idea to modify an empty lockbox. Maybe we shouldn't allow a lockbox with funds deposited to be modified. I think that would make funds deposited inaccessible without recreating the original configuration. I will have to try this.

[etotheipi]

2- I don't understand why is possible to edit a created lockbox.

Already got you covered on this:

• If you edit the lockbox metadata, nothing changes, it just updates the meta data and everything is the same.
• If you edit M, N or any of the public keys, it gives you the warning below

Code:

               You originally loaded lockbox (%s) but the edits you made
               have caused it to become a new/different lockbox (%s).
               Changing the M-value, N-value, or any of the public keys 
               will result in a new lockbox, unrelated to the original.
               
               *If you click "Ok" a new lockbox will be created* instead
               of replacing the original.  If you do not need the original,
               you can go the lockbox browser and manually remove it.

[CircusPeanut]

#2 good point. It seems like it would only be a good idea to modify an empty lockbox. Maybe we shouldn't allow a lockbox with funds deposited to be modified. I think that would make funds deposited inaccessible without recreating the original configuration. I will have to try this.

I should have tried it before commenting.

Alan has brilliantly kept the original lockbox if you modify it to be a different lockbox!

[teste]

2- I don't understand why is possible to edit a created lockbox.

Already got you covered on this:

• If you edit the lockbox metadata, nothing changes, it just updates the meta data and everything is the same.
• If you edit M, N or any of the public keys, it gives you the warning below

Code:

               You originally loaded lockbox (%s) but the edits you made
               have caused it to become a new/different lockbox (%s).
               Changing the M-value, N-value, or any of the public keys 
               will result in a new lockbox, unrelated to the original.
               
               *If you click "Ok" a new lockbox will be created* instead
               of replacing the original.  If you do not need the original,
               you can go the lockbox browser and manually remove it.

Thanks.

[CircusPeanut]

CircusPeanut:  I assume you are trying to reproduce from python-executed code, correct?  Try running from the installed version and/or rebuilding from the MSVS project and using the .exe. 

I installed the windows download from this thread, and ran it from the windows start menu. Am still unable to reproduce the bug.

[teste]

Im using Armory offline and the button (collect sigs and broadcast) say (must be online to broadcast). But  I can click on the button.

Different of:

The button (create spending Tx) say I must be online to spend. But because Im in offline mode, the button is INACTIVE.

[PRab]

This is testnet right, I assume that this address is testnet: mwoDMoqU8j87....

And the amounts are too big for main net unless you are stupid or wealthy or both

How old are those lockboxes?

If you pulled from previous version of the Armory repo and used an older version to create those lockboxes maybe your problem is caused by lockbox incompatibility. They did change a bit from the first time Alan let people try out lockboxes.

I mention these tries in case they spark any ideas on how to reproduce this bug.  Please let me know if you think of anything. Sometimes it is the strangest things that makes the difference on reproducing a bug.

It's rare that I can fix what I can't reproduce, and even then it's hard to trust the fix.

Yes the lockbox is testnet.
This lockbox was created by the first publicly available version of armory that supported lockboxes. I have been the same lockbox ever since.
It could be related to zero-confirm because I'm testing quickly, but there is an error in the middle of the log related to a missing folder. I am more suspicious of that. I know how you feel about unreproducible bugs. Programming is my day job.

I will be away from my main computer for a few days so will be unable to run any more test. Sorry

[etotheipi]

Im using Armory offline and the button (collect sigs and broadcast) say (must be online to broadcast). But  I can click on the button.

Different of:

The button (create spending Tx) say I must be online to spend. But because Im in offline mode, the button is INACTIVE.

I actually have a comment in the code explicitly discussing this:

https://github.com/etotheipi/BitcoinArmory/blob/devel/ui/MultiSigDialogs.py#L1101

Code:

                  #    The 'MergeSigs' button is the only one that kinda makes 
                  #    sense to not work offline, but there may be isolated 
                  #    cases where the user would merge without intending to 
                  #    broadcast.  Having it disabled in offline mode would
                  #    make them go mad.  So I'm going to explicitly make sure
                  #    that just that button is always enabled, even though
                  #    it might look like a bug.

The gist of it is:  the button is still potentially useful in offline mode, but only for collecting and merging signatures.  Broadcasting requires being online, but I couldn't separate out that functionality.  Obviously it's not entirely clear and does actually look like a bug... hmm

[etotheipi]

Okay, one more try!  I just uploaded an identical copy of 0.91.99.8-beta, except that the Windows version now has all the print statements removed.  Otherwise, it should be identical to the previously-available 0.91.99.8.  

Just be aware that since the file is named the same (it's literally the same except for irrelevant print statements removed), that the secure downloader signature verification will fail for the next 30-60 minutes, or until you go to the "Announcements" tab and click "Check for Updates".  You can't get the wrong one though, since you'll get an error and Armory will refuse to save the file.

P.S. - In case it wasn't clear:  this 0.91.99.8 re-do seeks to solve the "Bad File Descriptor" error.

[helgabutters]

1) When you are viewing the "Transactions" tab in "Manage Multi-Sign Lockbox Info", I can't right click and view the details of a transaction.
This is from a lockbox that I imported that doesn't have any of keys on this machine.
Armorylog: http://pastie.org/pastes/9358430/text?key=235mpxztzfutb3zmp3hs1a

2) When you are using a lockbox on the Test Network and you "Manually Enter bitcoin: Link" such as: bitcoin:2NFa9B2Pt3g279U16gLMfMbxWHWBsCYHaJz?amount=0.001
You will get an "Wrong Network" error that you are on the Test Network and the address supplied is for the Test Network.

https://i.imgur.com/1CnvalO.png

3) I know this is still beta but there is nothing in your privacy policy about talking with Coinbase and getting the exchange rate.

Request: There is no way to set the "owner" of the lockbox. This one I'm not sure about since you can simply be an organizer but it would be nice to have a setting to specify if you are an owner or just an organizer. An example situation is, I've imported a lockbox but I don't have any of the keys. It will still display that I received bitcoins even thought I can't do anything with them. I'm guessing this is correct behavior since it doesn't know if, for example, your keys are stored offline but it would be nice to be able to differentiate between the two. This is unless I am misunderstanding the different usages of the lockboxes.

[helgabutters]

1) Something really odd happens to the numbers when you put in large values of BTC when you are sending bitcoins in "Sending from Wallet" or Recieving Bitcoins through "Create Payment Request Link"
Example: Put in a value with about 15/20 or more numbers in "Request (BTC)" in "Create Payment Link" or "Amount" in "Sending from Wallet" and you will start getting different numbers BTC amounts then what the value you put in is. Example here is with all 9's:

https://i.imgur.com/HSTfBAY.png


2) The "BTC Balance" in the "Exchange Rates" tab is right justified. It doesn't allow you to resize the column to not have a lot of whitespace without covering up the actual BTC value.
You can see everything here:

https://i.imgur.com/kglpt7K.png

This is after slightly making the column smaller:

https://i.imgur.com/P24EUFC.png

After some more testing I noticed this happens in a lot of spots so it may be a known issue. Just seems like unnecessary whitespace when you need something smaller.

3) If you have a lockbox but do not have any of the keys on the machine, you can not make any comments to transactions. The window will pop up but you will get the same error that I pasted before with the "View Details":
UnboundLocalError: local variable 'wlt' referenced before assignment

4) Below are two examples of the same issue. The transaction amount displayed is "-0.001 BTC" but as you can see from both transactions, 0.001 BTC is not any of the inputs or outputs.
This is from a lockbox with 2 keys on one machine and 1 key on another. They also all display "Sent" when they were actually recieving.

https://i.imgur.com/gJmmRNE.png

https://i.imgur.com/lGMoIuj.png

[helgabutters]

1) "Public Key Information" window pops up randomly when editing a lockbox. I can't consistently reproduce this issue so I'm not really sure what the cause may be: https://www.youtube.com/watch?v=ZE4EzI7lFmE

This is a 2-of-2 lockbox on Win7 with both wallets on this machine.
There is no "extended info" for the lockbox as well as no "Name or ID" for both pieces.
It only has one transaction which is the original funding transaction.

2) Can't resize the "Transaction Info" windows

https://i.imgur.com/T7P4fsd.png

3) On Windows for "Import Lockbox", "Import Signature Collector", "Import Promissory Note" in the upper right hand corner there is a "?". Pressing this does nothing but change your pointer to a Do Not symbol: https://i.imgur.com/qja2U86.png

3.1) Import Lockbox:

https://i.imgur.com/oJ3eJBU.png

3.2) Import Signature Collector:

https://i.imgur.com/vQxW9pG.png

3.3) Import Promissory Note:

https://i.imgur.com/FyF0bQc.png



4) In "Create Payment Request Link" an overly long "Link Text" pushes everything down and you can't view all of the information unless you copy to clipboard or raw html.

https://i.imgur.com/CuapRpZ.png

[PRab]

I just re-tested with the latest version and from what I can tell all of the bugs/glitches/improvements that I have mentioned have been fixed! I am extremely excited about this next release of Armory. Armory continues to lead the way in cutting edge bitcoin security that is accessible by anyone.

Now I just get to sit back and enjoy this technology while you guys work on deterministic/HDish lockboxes (I'm assuming that's next, but I trust your judgement if something else is more urgent).

Note: I have been doing all of my testing on one online box. I haven't tried anything with doing the signing/merging transactions on an offline computer.

[helgabutters]

1) I was sending from a Lockbox to a variation of lockboxes / bare P2SH addresses. Armory threw an error that the transaction was not accepted but it was sent and included in the next block: http://pastie.org/pastes/9365846/text?key=jf5oyzmqmeo6cg890agiw

2) Clicking "Manually Enter Bitcoin: Link" without anything inside doesn't display any error and causes: http://pastie.org/pastes/9365725/text?key=mod6tocttrku2maks8i1g

3) When two separate transactions are listed that are actually part of the same transaction in the MultiSig info box you can't set separate comments for each one, it will autofill in the other.

4) This is a signed, exported transaction from an OSX wallet: http://pastie.org/pastes/9365763/text?key=mlykdfhsayfcms9t84ytq
Putting this text into "Import Lockbox" and hitting "Done" does not give a dialog box and this is the armorylog: http://pastie.org/pastes/9365761/text?key=fvxvffei8zxastiz0imioa

5) In OSX, "Collect Sigs and Broadcast" doesn't display receiving addresses. You can add the above signed transaction to see: http://pastie.org/pastes/9365763/text?key=mlykdfhsayfcms9t84ytq

https://i.imgur.com/J5MPCho.png

6) The MultiSign "Dashboard" information is cut off in OSX:

6.1)
https://i.imgur.com/6cNSmjV.png

6.2)
https://i.imgur.com/CdAXVUy.png

[helgabutters]

1) Total public keys will randomly jump to a different number when selecting. You can see this around 42 seconds where I select "4" and it jumps to "6":

https://www.youtube.com/watch?v=BJmElel5hlQ#t=42

2) The "Show Keyboard", when it has already been opened and you go to enter the password again will display "Show keyboard" instead of "Hide keyboard":

https://www.youtube.com/watch?v=m_Ust67eGFs

3) Creating a promissory note with all three promissories in the same wallet with a few different values:

http://pastie.org/pastes/9366419/text?key=iduvkt3bfpqezvtidbria
https://www.youtube.com/watch?v=QLpTzWKe1TI

4) In "New Receiving Address" you can insert a seemingly infinite amount of information in the "(Optional) Add a label ..." but this information will be cut off when you "Create Clickable Link":

https://www.youtube.com/watch?v=RdAuTh2vy-8

5) Armory randomly crashes after playing with offline transactions / wallet properties / lock boxes:

http://pastie.org/pastes/9366416/text?key=r7isdfaonz0oaa1w4jjqna
https://www.youtube.com/watch?feature=player_detailpage&v=DIXIN53VIHM#t=69 (actual crash is around 1:09)

[helgabutters]

1) (?) for "Print Wallet Backup" with "Use SecurePrint(TM)" talks about "Turn off this feature if you copy the 'Root Key' and 'Chaincode' by hand" but there is no "Chaincode" anymore.

https://i.imgur.com/vOYGT00.png

2) "Printable paper backups" > "Fragmented Backup (M-of-N)" ... "Create Backup Fragments" does not have a "(?)" for the SecurePrint information that the single-sheet does.

https://i.imgur.com/zETEA8y.png

3) In the "Wallet Creation Wizard" the first step has a "< Back" button but there is no reason for this button. It is greyed out but a non-greyed out cancel button may work better (or just removed completely)

https://i.imgur.com/gcIkN2I.png

4) "Wallets" > "Fix Damaged Wallet" if you don't put anything inside the "Wallet Path" and hit "Recover" then the menu closes and you get this error:

http://pastie.org/pastes/9366709/text?key=ox9ftzrbkvmap4j60hwq

https://i.imgur.com/bTCMFKq.png

5) Can't print Armory backup wallet to PDF successfully in OSX: https://www.youtube.com/watch?v=qBPCdlWtRg8

[helgabutters]

1) "Sign with Address" with a lockbox selected and clicking "Bare Signature" then "Base64 Signature" then "Clearsign Signature":

http://pastie.org/pastes/9369038/text?key=64ygktykwwx01xor2y85g

2) Same as above but with the actual P2SH address instead of Lockbox:

http://pastie.org/pastes/9369034/text?key=mq3dg3ngb3sch3carnpcuw

3) In the Address Book in OSX, setting a comment on a reciving address won't update the display until you select another transaction or try to change the name again:

https://www.youtube.com/watch?v=4fJMsvu7vM8

4) In same video around 11 seconds you can see that every so often it won't successfully change a comment:

https://www.youtube.com/watch?v=4fJMsvu7vM8#t=11

[CircusPeanut]

Helgabutters - Thanks for all of your hard work. I have counted 54 bug reports and found ~43 distinct bugs that we have either fixed already or will fix. That's an ~80% hit rate. Also, your reports were easy to read and understand. In most cases you included no more and no less information than I needed to reproduce the bug. I only need one clarification that is included below.

To thank you for quantity and the quality of your output we have decided to pay 0.03 for all of your bug reports including whatever we think are duplicates and not bugs. This also saves us the trouble of making calls on the few borderline bugs.

So that is 54 * 0.03 = 1.62 BTC.  Just post your address and we will send you your prize.

Anyone else that may be thinking what about my bug reports. I'm not sure, I've just been focused on this lot. We intend to reward everyone for useful bugs that they've submitted. And for anyone who can match Helgabutters prolific output, we will reward you just as generously.

Thank you Helgabutters and everyone who's participating in crowd testing Armory.


------------------------------------------------------
"I was sending from a Lockbox to a variation of lockboxes / bare P2SH addresses. Armory threw an error that the transaction was not accepted but it was sent and included in the next block: http://pastie.org/pastes/9365846/text?key=jf5oyzmqmeo6cg890agiw"


Not sure what you mean by bare P2SH, please clarify.

[etotheipi]

So that is 54 * 0.03 = 1.62 BTC.  Just post your address and we will send you your prize.

 Actually, I've already got an encrypted GPG thread with helgabutters over email.  Please send the payment address there. 

And yes, thanks again!  You get the bug bounty overachievers award!

[helgabutters]

Helgabutters - Thanks for all of your hard work. I have counted 54 bug reports and found ~43 distinct bugs that we have either fixed already or will fix. That's an ~80% hit rate. Also, your reports were easy to read and understand. In most cases you included no more and no less information than I needed to reproduce the bug. I only need one clarification that is included below.

To thank you for quantity and the quality of your output we have decided to pay 0.03 for all of your bug reports including whatever we think are duplicates and not bugs. This also saves us the trouble of making calls on the few borderline bugs.

That's awesome! Thank you very much.

So that is 54 * 0.03 = 1.62 BTC.  Just post your address and we will send you your prize.

 Actually, I've already got an encrypted GPG thread with helgabutters over email.  Please send the payment address there.

Yes, please send to the address that I previously sent to etotheipi.

"I was sending from a Lockbox to a variation of lockboxes / bare P2SH addresses. Armory threw an error that the transaction was not accepted but it was sent and included in the next block: http://pastie.org/pastes/9365846/text?key=jf5oyzmqmeo6cg890agiw"


Not sure what you mean by bare P2SH, please clarify.

Sorry for the mix up, it should be "Bare Multi-Sig (No P2SH)". Below is an example of the type of transaction I sent (and just confirming that this one too gave the error):

https://i.imgur.com/6PUG1Ht.png

[doug_armory]

Helgabutters - Thanks for all of your hard work.

Yes, thank you very much. At my previous job, I got bug reports from so many people who had no clue what they were talking about, or couldn't organize their materials, or otherwise drove me nuts. Your bug reports are damn near perfect. You've earned your bounty. Now then, to fix those Mac bugs.... (FYI, the printing bug is already fixed.)

[fran2k]

This is very awesome work! Finally some multi-sig into the GUI.

Thanks.

[burekzastonj]

Armory caused me a lot of grey hair in the past, so thank you, no more!

[etotheipi]

Last testing version before 0.92 release (0.91.99.9-beta)
Still 0.03 BTC per bug!


As before, use the secure downloader to grab the latest testing version.  Armory will check the digital signatures for you!  Only use the links below if you do not yet have a trusted version of 0.91+ available.

Installers for 0.92-beta (pre-release 0.91.99.9-beta):
  Armory 0.91.99.9-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.9-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.9-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.9-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.9-beta for Raspbian (armhf)

Offline Bundles:
  Armory 0.91.99.9-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.9-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.9-beta Offline Bundle for Raspbian (armhf)

Signed Hashes:
  Armory 0.91.99.9-beta: Signed hashes of all installers


Thanks to all our testers, especially helgabutters!   It took us a while to get through all his bug reports, but I think we knocked them off all of the non-OSX bug reports.  Although we may not have fixed all the OSX bugs, doug_armory was able to integrate some Qt4 patches into the OSX build system that should resolve a ton of stability issues.  No promises, but he insists that he experienced a notable improvement!  Please let us know.

Not only that, but doug_armory and CircusPeanut have got a ton of new unit tests and functional tests integrated, which should dramatically improve robustness of everything going on under the hood.  We're still working on some automated GUI tests, but they're not ready yet.  Hopefully soon.

Finally, we made some significant improvements to armoryd.py.  It's still not quite stable, and we don't plan for it to be for the 0.92 release, but it's getting closer.  If you are interested in armoryd, please try it out and feel free to report bugs here for bounties.   We have made no claims of it being stable, so there's probably quite a few bounties to be collected.  We're happy to pay them out to speed up our development.

The 0.03 bounty is still active for 0.91.99.9, both GUI and now armoryd.  

[helgabutters]

First armoryd bug!

When running "help" they all return "Error": "The function description is malformed."
http://pastie.org/pastes/9395585/text?key=fbvn2gyp5xzxicil4reag

Since this is the last release before 0.92 is there any specific date you are aiming to have it out by?

[etotheipi]

Since this is the last release before 0.92 is there any specific date you are aiming to have it out by?

It's funny you ask that.  The guys that work with me would probably complain that I like to declare schedules and then not stick to them.  Which is true -- I try to set schedules to give us a target to work for, but the true end date is "when it's ready"    Especially with a piece of software as sensitive as this, we never rush anything which might lead to dangerous bugs.

So to answer your question more directly:  we'd like to officially release this next week.  Saturday is a good target for the end of the testing phase.  But depending on how testing goes, it may be further delayed.  So far, things are looking good, an these bounties have been tremendously useful for speeding up this process so you guys can expect these to continue for further releases!

[TimS]

Edit: I upgraded to .9 and this is gone, so you should probably disregard this.

I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".


This is in version 0.91.99.8-multisig.

A brief overview of how I got here, in case it matters:
I created two promissory notes (0.1 BTC each) to pay an address in my own wallet, created the TXSIGCOLLECT from that, and then imported that into the Review & Sign window (these are still unsigned transactions).

[etotheipi]

I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".

...

A brief overview of how I got here, in case it matters:
I created two promissory notes (0.1 BTC each) to pay an address in my own wallet, created the TXSIGCOLLECT from that, and then imported that into the Review & Sign window (these are still unsigned transactions).

Whoops, that's a pretty obvious error.  You definitely deserve a bounty for that ... or at least we deserve to lose a bounty for not noticing it ourselves

[helgabutters]

1) In armoryd if you don't give backupwallet a valid file path it throws: "global name 'IOERROR' is not defined" 

Code:

armory@armory-vm:~/armoryD$ python /usr/lib/armory/armoryd.py --testnet backupwallet testes
{
    "Error": "An error occurred in backupwallet", 
    "Error Type": "NameError", 
    "Error Value": "global name 'IOERROR' is not defined"
}

1.1) This is also thrown when you try to save a file to a folder where you do not have proper permissions.

Code:

armory@armory-vm:/usr/lib/armory$ python armoryd.py --testnet backupwallet /root/test.za
{
    "Error": "An error occurred in backupwallet", 
    "Error Type": "NameError", 
    "Error Value": "global name 'IOERROR' is not defined"
}

2) In armoryd you can create a 1 of 1 lockbox. You can't do a 1 of 1 in the armoryqt so you can't edit the lockbox you created.

https://i.imgur.com/1m24oqY.png

3) In Linux: When you select "Request Payment" in the lockbox manager nothing happens and it throws this error:

Code:

2014-07-16 17:18 (ERROR) -- Traceback (most recent call last):
  File "/usr/lib/armory/ui/MultiSigDialogs.py", line 1158, in funcReqPayment
    DlgRequestPayment(self, self.main, p2shAddr).exec_()
  File "/usr/lib/armory/qtdialogs.py", line 9896, in __init__
    linkText = hex_to_binary(self.main.getSettingOrSetDefault('DefaultLinkText', defaultText))
  File "/usr/lib/armory/armoryengine/ArmoryUtils.py", line 1846, in hex_to_binary
    bout = h.replace(' ','')  # copies data, no references
AttributeError: 'long' object has no attribute 'replace'

4) In Linux: When you select "Create Clickabe Link" in Recieve Bitcoins > New Recieving Address nothing happens and it throws this error:

Code:

2014-07-16 17:20 (ERROR) -- Traceback (most recent call last):
  File "/usr/lib/armory/qtdialogs.py", line 2772, in openPaymentRequest
    dlg = DlgRequestPayment(self, self.main, addrStr, msg=msgTxt)
  File "/usr/lib/armory/qtdialogs.py", line 9896, in __init__
    linkText = hex_to_binary(self.main.getSettingOrSetDefault('DefaultLinkText', defaultText))
  File "/usr/lib/armory/armoryengine/ArmoryUtils.py", line 1846, in hex_to_binary
    bout = h.replace(' ','')  # copies data, no references
AttributeError: 'long' object has no attribute 'replace'

5) In armoryd you when encrypt and unlock a wallet, instead of a displaying the wallet ID the output is "<armoryengine.PyBtcWallet.PyBtcWallet object at ... >"

Code:

armory@armory-vm:/usr/lib/armory$ python armoryd.py --testnet unlockwallet password1
"Wallet <armoryengine.PyBtcWallet.PyBtcWallet object at 0x9add54c> has been unlocked."
armory@armory-vm:/usr/lib/armory$ python armoryd.py --testnet encryptwallet password
"Wallet <armoryengine.PyBtcWallet.PyBtcWallet object at 0x9add54c> has been encrypted."

[etotheipi]

@helgabutters

#3 and #4 are actually the same bug.  And I recognize the issue... it's a rare condition that's leading to the data being saved in the settings file being read later, incorrectly.  Can you tell me what data is in the "DefaultLinkText" line of the ArmorySettings.txt file?  Either way, you can close Armory, remove that line, and then restart Armory and it will be fixed.  I'll figure out how to avoid that condition.

[doug_armory]

Thanks to all our testers, especially helgabutters!   It took us a while to get through all his bug reports, but I think we knocked them off all of the non-OSX bug reports.  Although we may not have fixed all the OSX bugs, doug_armory was able to integrate some Qt4 patches into the OSX build system that should resolve a ton of stability issues.  No promises, but he insists that he experienced a notable improvement!  Please let us know.

Hello. Don't worry, everybody, I'll be cranking out OS X fixes as quickly as possible! I probably would've gotten them done by now had I not spent a few days researching the stability patch (I tried an earlier version months ago, and it crashed and burned), not to mention cleaning up some other OS X build stuff that's invisible to 99.9% of you but critical for anybody building Armory, ourselves included.

First armoryd bug!

When running "help" they all return "Error": "The function description is malformed."
http://pastie.org/pastes/9395585/text?key=fbvn2gyp5xzxicil4reag

Since this is the last release before 0.92 is there any specific date you are aiming to have it out by?

How did I know you'd be on the case? Odd that it's no longer working. Worked like a charm last I checked, although the code is a bit fragile. (Nature of the beast for now, unfortunately.) I'll look into this and the other bugs ASAP.

[helgabutters]

@helgabutters

#3 and #4 are actually the same bug.  And I recognize the issue... it's a rare condition that's leading to the data being saved in the settings file being read later, incorrectly.  Can you tell me what data is in the "DefaultLinkText" line of the ArmorySettings.txt file?  Either way, you can close Armory, remove that line, and then restart Armory and it will be fixed.  I'll figure out how to avoid that condition.

Ah, that makes sense.

The value for DefaultLinkText is: 66657766616566

[PRab]

Testnet bug.

Open in testnet mode and send a transaction. It asks if you want to donate, say yes. It will fill in the mainnet address.

[PRab]

Enhancement request.

If you send from 1 wallet to another (both controlled by the same armory instance) the outgoing transaction doesn't always show up before the incoming transaction.

 

[SimonBelmond]

I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".

...

A brief overview of how I got here, in case it matters:
I created two promissory notes (0.1 BTC each) to pay an address in my own wallet, created the TXSIGCOLLECT from that, and then imported that into the Review & Sign window (these are still unsigned transactions).

Whoops, that's a pretty obvious error.  You definitely deserve a bounty for that ... or at least we deserve to lose a bounty for not noticing it ourselves

This was already pointed out here: https://bitcointalk.org/index.php?topic=607046.msg7606266#msg7606266

[etotheipi]

I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".

...

A brief overview of how I got here, in case it matters:
I created two promissory notes (0.1 BTC each) to pay an address in my own wallet, created the TXSIGCOLLECT from that, and then imported that into the Review & Sign window (these are still unsigned transactions).

Whoops, that's a pretty obvious error.  You definitely deserve a bounty for that ... or at least we deserve to lose a bounty for not noticing it ourselves

This was already pointed out here: https://bitcointalk.org/index.php?topic=607046.msg7606266#msg7606266

...and he still gets the bounty because it should've been fixed but still exists in the new testing version.   I think we got so distracted by helgabutters' bugs, we forgot to go back through some of the other reports.  Whoops.  [EDIT: scratch that... it was fixed, but TimS's report was made against an earlier testing version]

Enhancement request.

If you send from 1 wallet to another (both controlled by the same armory instance) the outgoing transaction doesn't always show up before the incoming transaction.

...

You know, that has always bugged me, but just not enough to be motivated to go find and update the sorting code.  Thanks for encouraging me to do it, finally!

Perhaps .9 won't be the last testing release, but I also won't make a big deal about doing a couple tiny intermediate releases.  My release scripts are mature enough that it's not a huge burden anymore.  And as simple as these changes are, it always makes me uncomfortable right before a release (but none of them are the kind that would lead to money loss if we botched something).  

[CircusPeanut]

I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".

Thought I fixed it here:

https://github.com/etotheipi/BitcoinArmory/commit/29944272499dd167f3a26af6d164750fd3266af7

[TimS]

I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".

Thought I fixed it here:

https://github.com/etotheipi/BitcoinArmory/commit/29944272499dd167f3a26af6d164750fd3266af7

Yes, as has been mentioned in a couple of edits, I was testing against an older version. Oops

[Searinox]

0.91.99.9: The warning popup is now gone but the "minimize to tray on open" now no longer works and Armory pops up to full window on launch instead of discretely activating in tray. The option appears to be broken. The whole idea for me waiting for the update was something that could launch on startup or sleep quietly(yes I actually made a script to restart it on resume sleep), and now I've gone from annoying warning to program UI popping in my face.

Also an older issue: on both graceful and ungraceful shutdown, Armory leaves a ghost icon of itself in the tray which vanishes on mouseover.

OS: Windows 7 x64 SP1 + All Updates

[TimS]

I'm using .9 now.

"oragnizer" instead of "organizer":


From https://github.com/etotheipi/BitcoinArmory/blob/doug-devel/ui/MultiSigDialogs.py#L1727 (note the branch...the main branch doesn't have this file at all yet, and I'm unfamiliar with the branch structures you use) has an unnecessary comma (I haven't found yet where, or if, this is shown in the app, so no screenshot).

Once it has enough signatures, any device, can broadcast the transaction to the network.

Should be

Once it has enough signatures, any device can broadcast the transaction to the network.

This is in both lines 1727 and 1791.

[TimS]

When spending from a 2 out of 3 lockbox, Armory allows you to provide all 3 signatures. When it tries to broadcast this, it is rejected by the network (presumably because it sent all 3 though it had promised just 2). It should either stop you at 2 signatures, or allow all 3 and then only broadcast any 2 of them.




Also, when exporting signed/unsigned sigcollect.tx files, the suffix can appear twice (I'm using Win 7 SP1 x64). When I actually click Save, it saves with just one suffix. If the file (with the single suffix) already exists, this will mean that you can overwrite the file without a confirmation telling you the file already exists.

[doug_armory]

From https://github.com/etotheipi/BitcoinArmory/blob/doug-devel/ui/MultiSigDialogs.py#L1727 (note the branch...the main branch doesn't have this file at all yet, and I'm unfamiliar with the branch structures you use) has an unnecessary comma (I haven't found yet where, or if, this is shown in the app, so no screenshot).

That's an old branch I haven't synced in a month and really haven't developed on since May. Any issues there that aren't in the "devel" branch should be ignored. (In fact, the entire branch should be ignored!)

[etotheipi]

From https://github.com/etotheipi/BitcoinArmory/blob/doug-devel/ui/MultiSigDialogs.py#L1727 (note the branch...the main branch doesn't have this file at all yet, and I'm unfamiliar with the branch structures you use) has an unnecessary comma (I haven't found yet where, or if, this is shown in the app, so no screenshot).

That's an old branch I haven't synced in a month and really haven't developed on since May. Any issues there that aren't in the "devel" branch should be ignored. (In fact, the entire branch should be ignored!)

On that note, after this release we're going to go through and clean up all the random side branches.  I'd like to reduce to just "master", "testing", "dev", and a couple others that are works in progress.  There's a lot of abandoned branches that were really for one bug or feature that took way longer than it should have.   A little belated spring cleaning. 

[Searinox]

Was something changed in the way Armory handles the minimize on startup and I'm doing it wrong? Because I continue to fail to get it to start in tray, even with a vbscript sending it alt+f4. When the program launches, it pops up the UI and completely disregards shortcuts that have "start minimized" in the properties, armory's options, VBscripts that try to change the window state, or anything of the sort. AFTER the UI has been brought up it responds to closing, it closes nicely in tray, but ONLY after it's done slapping itself on the screen and its resilience is annoying me.

[helgabutters]

Sorry for the delay, works been rather busy the past few days so I haven't been able to put in as much time as I'd like. Also, could you give me some insight on which ones I've submitted that are definitely not bugs and a few that you aren't sure of? I'm just trying to gauge what exactly you want and what I can safely not worry about finding/reporting.

1) You can't "importprivkey" as it will always error. I tried both hex and base58

http://pastie.org/pastes/9403588/text?key=1qunxbmpxlqa8arkoitgxq

2) There is some calculation error in listaddrunspent. You can see once you hit 3 characters in the string, it will still say 3 once you've put in a fourth and continue counting up from there.

http://pastie.org/pastes/9403585/text?key=roc4hfgkcsc6k9igcmmgq

3) You get different errors depending on the number of characters in "getblock". It seems dependent on if it's even or odd.

http://pastie.org/pastes/9403583/text?key=wucl7ytepivyq4uywdq5w

4) If you have a very long wallet description, the "Delete Wallet Options" window gets overly large and it won't show the whole thing. It also can't be resized down at all (This happens on Win and Linux, haven't tested OSX)

https://www.youtube.com/watch?v=xxl08nkXNPk

5) You can't "verifysignature" as it always interprets the "-----" as an argument for armoryd (and the only compatible signature types have "-----" in them).
I've tried in just the command line and in a bash script to no avail. If this is just an issue with my understanding of the command or how to properly give the command the information, please let me know.

Address: mkT61iEMnSSFgoCJkXFqbV9SiMHKnHDktN
Message: This is to test armoryd verifysignature for mkT61
Base64 Sign

http://pastie.org/pastes/9403589/text?key=dwsxu9jjzfyrgwlooqija

Same as above but Clearsign

http://pastie.org/pastes/9403590/text?key=zcw015sdcylrwu7k1hkniq

6) For a verified signature there is an extra ' in front of "The owner of the following ..."

https://i.imgur.com/zcbMDn8.png

7) You get an "Unexpected BLKSTRING" error when trying to signasciitranscaction. I tried both right in the command line and from a file output

http://pastie.org/pastes/9403594/text?key=zu0cydlii6zwkfyqozpq

8 ) This one I'm not sure of the cause. I thought it was originally because the wallet was locked but that isn't the case. One of my wallets if I try to "getledger" or "getledgersimple" I will get an "AttributeError":

http://pastie.org/pastes/9403608/text?key=qtztvorf7wni6c8tj9jtbg

I can provide you with this wallet if you'd like, just let me know.

[etotheipi]

Final Testing Version before 0.92 (0.91.99.11-beta)
This will be the released version of 0.92 unless important/dangerous bugs are found (gotta stop polishing and just release it at some point).  Plan to rename this to 0.92 on Tues or Weds.

Installers for version 0.92 (pre-release 0.91.99.11-beta):
  Armory 0.91.99.11-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.11-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.11-beta for RaspberryPi (armhf)


Offline Bundles:
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.11-beta Offline Bundle for RaspbianPi (armhf)

Signed Hashes:
  Armory 0.91.99.11-beta: Signed hashes of all installers


Honestly, not a lot has changed from the .9 testing version except:

• Proper sorting of simultaneous ledger entries now (should've done that like 2 years ago)
• Offline message format upgrade warning when you attempt to create and unsigned transaction from the "Send Bitcoins" dialog (matching the one when you click "Offline Transactions" from the main window)
• Strips extraneous signatures from transactions just before broadcast -- it will carry the extra sigs around with it so you can see who has signed, but the extras are removed when you hit "Broadcast".

[doug_armory]

Sorry for the delay, works been rather busy the past few days so I haven't been able to put in as much time as I'd like. Also, could you give me some insight on which ones I've submitted that are definitely not bugs and a few that you aren't sure of? I'm just trying to gauge what exactly you want and what I can safely not worry about finding/reporting.

Thanks for posting some more bugs to fix. I've started going through them. At least one (#2) isn't a bug because you're passing in a Base58 value, while the error message is counting the number of bytes in the decoded value. Subtle, I know, but it doesn't really count as a bug.

In the meantime, I'll see what I can get into 0.92. Gonna go pester Alan.

EDIT: Also, as I'm going through these, I'm noticing that some aren't actual bugs. For example, #3 isn't a bug. You need to supply a block hash. So, the following would be valid. (I just tested it.)

Code:

python armoryd.py --testnet getblock 00000000000072da6566808cce7e50c0b4f26fd56993a2a22d8d26e7cc23bad8

Use the following to see what the parameters should be. You can also poke around the source to see some examples.

Code:

python armoryd.py --testnet help

EDIT 2: Regarding #5, this is a bug, but not in the sense that you may think. One thing I forgot to point out in the help text is that the message needs to be passed in with quotation marks so as to avoid tripping up the command line argument detector. I've included an example of what's valid (other than the obvious nonsense).

Code:

python armoryd.py verifysignature \"-----BEGIN BITCOIN SIGNED MESSAGE-----$'\n'Comment: Hello.$'\n'-----BEGIN BITCOIN SIGNATURE-----$'\n'$'\n'junkjunkjunk$'\n'-----END BITCOIN SIGNATURE-----\"

That being said, it turns out that the unit test we wrote didn't take into account the fact that, on the command line, the spaces would cause the sig to be split into multiple pieces. I fixed that.

EDIT 3: #7 is also not a bug. The formatting isn't quite right. The following shows a format that will work. It's basically the same as the one from #5 with the exception that quotation marks aren't required (and will, in fact, mess things up, although I might slip in some code to handle that particular case.)

Code:

python armoryd.py --testnet signasciitransaction =====TXSIGCOLLECT-GynG9f37======================================$'\n'AQAAAAsRCQcAAAAAAf18AQEAAAALEQkHchUHvHxM29fPeY02InKy5ZQeYZ8vMA9G$'\n'rJVpM8tCGBEAAAAA/QEBAQAAAAEhOzQQbizqkYkkOvs8sxROO1j198R/ls8zebRC$'\n'TgGNagMAAACMSTBGAiEA5nWwoKcAU7g3dhs/5dkq6eaw+yY7T+uJiqKbnmjwkjAC$'\n'IQCARNrs4jaNx5iNFPyObj05olSK710suLl+YbfKe8ihUgFBBM3zuTqCoy/uKAh0$'\n'Kgn5LeWNYpMv/WJvqUsJYT2+/QtuG73EQhswCxN7aqyOaOF8EHN7mLUT93p9G0st$'\n'eWtEUof/////AlA/R9wVAAAAGXapFCOOhZJjttO/Z1siFJighsAM3huMiKwAypo7$'\n'AAAAABepFEsgPEt7f4VFiKFCrGqixxSWvpZVhwAAAAAAAAD/////AUEEYjJpOVJc$'\n'aXeB3CgM2Apdk/GpLtSA4wrfvuvhsbweFhs/BqIi3MpiugRcdTbTox3iVUhCpYon$'\n'BrmWu9/jvMRqjwAAAjQBAAAACxEJBxl2qRQApYwGgX3k4qNc5Y6XjJCDxNbZd4is$'\n'UF5R1hUAAAAAAAROT05FAAAANAEAAAALEQkHGXapFENn/3Vq4y59O99BpXN6HZTH$'\n'Zbh8iKwA4fUFAAAAAAAABE5PTkUAAAA=$'\n'================================================================

EDIT 4: (Final edit, I hope!) Hmmm. I'm not able to reproduce #8. Works for me. Sanity check: Are you using a testnet wallet in that particular example? If you are, PM me and we'll discuss what's going on.

With that said, everything other than #4 and #8 has been handled one way or another. I'll get the rest tomorrow.

[PRab]

Looks like one of my testnet wallets is producing invalid transactions with the latest version (0.91.99.11-beta). Every time I try to send bitcoind disconnects then reconnects and gives the log message "2014-07-20 00:36:46 ERROR: AcceptToMemoryPool : inputs already spent". I was doing some rapid spending/receiving before I did the upgrade, but everything was already confirmed before I shutdown armory to do the upgrade. I'm guessing that doing a "Rescan Database" will clear it up, but I'll hold off doing that in case you guys need some other log/trace data.

[etotheipi]

Looks like one of my testnet wallets is producing invalid transactions with the latest version (0.91.99.11-beta). Every time I try to send bitcoind disconnects then reconnects and gives the log message "2014-07-20 00:36:46 ERROR: AcceptToMemoryPool : inputs already spent". I was doing some rapid spending/receiving before I did the upgrade, but everything was already confirmed before I shutdown armory to do the upgrade. I'm guessing that doing a "Rescan Database" will clear it up, but I'll hold off doing that in case you guys need some other log/trace data.

Strange... if you can still replicate the error can you go back to .9 and test if it's oding the same thing?  I don't think anything changed between .9 and .11 that would've induced that kind of error.

[PRab]

Strange... if you can still replicate the error can you go back to .9 and test if it's oding the same thing?  I don't think anything changed between .9 and .11 that would've induced that kind of error.

Rolled back to .9 and still have the same (broken) behavior. I wonder why I didn't see this before...

Edit:
I can send you the wallet if you like (its testnet).

[fran2k]

Final Testing Version before 0.92 (0.91.99.11-beta)
This will be the released version of 0.92 unless important/dangerous bugs are found (gotta stop polishing and just release it at some point).  Plan to rename this to 0.92 on Tues or Weds.

Installers for version 0.92 (pre-release 0.91.99.11-beta):
  Armory 0.91.99.11-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.11-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.11-beta for RaspberryPi (armhf)


Offline Bundles:
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.11-beta Offline Bundle for RaspbianPi (armhf)

Signed Hashes:
  Armory 0.91.99.11-beta: Signed hashes of all installers


Honestly, not a lot has changed from the .9 testing version except:

• Proper sorting of simultaneous ledger entries now (should've done that like 2 years ago)
• Offline message format upgrade warning when you attempt to create and unsigned transaction from the "Send Bitcoins" dialog (matching the one when you click "Offline Transactions" from the main window)
• Strips extraneous signatures from transactions just before broadcast -- it will carry the extra sigs around with it so you can see who has signed, but the extras are removed when you hit "Broadcast".

Great, I´m testing.

[Muhammed Zakir]

I watched the video. The whole process looks complicated at the moment to me.

I would expect that if I am in a group of people signing a multisign transaction, that the signature-process is happening in the tool.
At the moment it looks like that I have to send the partly-signed transaction with a file over to the next person via E-mail or another messaging system.
From a technical standpoint I undstand that the transaction needs to be signed by all required parties first, before it can be broadcasted.
On the otherhand would it be very hand if the partly signed transaction would automatically show up on the other person's wallet waiting for approval.

Like: "1 Transaction waiting for approval" type of messaging system.

I think DarkWallet will eventually have a P2P connection between parties to sign. However, many Armory users will have their keys in an offline system anyway, so they need some kind of transfer like that. Remember, Armory is targeted to the highest security aware users.

Would there be a way to actally embed transactions in the Blockchain which are not yet valid as they are only signed by one party? So for three signatures three times the miners fee would have to be payed, but who cares. would be awesome to use the already in place network for this. I guess the answer is no, but maybe someone knows for sure.

DarkWallet has a lot of features but still I don't think it has better security than Armory.

Thanks! It is good! So the miners fee is directly proportional to signatures, right? I think this is best wallet for providing escrow services.
Kindly,
      MZ

[etotheipi]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

[Searinox]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Windows 7: Armory pops up in front despite having the option to start minimized to tray checked. And it's quite very annoying. The issue persists with version 0.91.99.11.

[doug_armory]

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

I haven't heard much personally. I've seen a couple of bug reports regarding crashes. One person says they're using the "latest" Armory but hasn't confirmed which exact version they're using (i.e., I don't know if they're using a patched version). Another person was using 0.91.99.8 and said that upgrading to 0.91.99.11 fixed their particular crash issues. Again, I'm not promising anyone any magic bullets, but anecdotal evidence seems to suggest that the OS X build is reasonably stable at this point.

[etotheipi]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Windows 7: Armory pops up in front despite having the option to start minimized to tray checked. And it's quite very annoying. The issue persists with version 0.91.99.11.

I cannot replicate this.  I have tested in both Linux and Windows, and the option works for me.  Please try renaming your ArmorySettings.txt file (in C:\Users\<user>\AppData\Roaming\Armory), and then start Armory again -- it will be like new, asking you to agree to the EULA, etc.  Try setting the option again in the menu and then restart.  Tell me if it works.

[Searinox]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Windows 7: Armory pops up in front despite having the option to start minimized to tray checked. And it's quite very annoying. The issue persists with version 0.91.99.11.

I cannot replicate this.  I have tested in both Linux and Windows, and the option works for me.  Please try renaming your ArmorySettings.txt file (in C:\Users\<user>\AppData\Roaming\Armory), and then start Armory again -- it will be like new, asking you to agree to the EULA, etc.  Try setting the option again in the menu and then restart.  Tell me if it works.

I moved the ENTIRE Armory directory away and let it create a fresh one as if it never ran before. It may be an issue with the Expert UI or something of my particular mix of settings. I am linking a paste of my ArmorySettings.txt, try using these and see if the issue is replicated. http://pastebin.com/Qf2Rb0ZG

[KrakenTrader]

just downloading 0.92 version
 I am keen to try how multisig function works, to be used for escrow service.
When it works as described, I'd consider it as one of the best ways to do escrow.

[drips]

Bug 1:

Replicate:

• make a new transaction, up until the Confirm Transaction screen
• close the confirm screen

Wallet is now completely non-responsive to all button clicks, must be force quit due to the close buttons not working.


Bug 2:

If all internet connectivity is disabled in the settings, outgoing connections are still made regardless.

https://i.imgur.com/QYarjSV.jpg

https://i.imgur.com/dCkurUO.jpg


Bug 3:

https://i.imgur.com/tmTaMul.jpg

Replicate:

• make a transaction
• tick "use existing change address"

Text is squashed, if the window is made bigger the radio buttons don't work properly.

[etotheipi]

About bug 2:  this is intentional.  You can only 100% disable it using --skip-announce-check from the command-line when starting Armory.  We wanted to make it possible to fully disable it, but not too easy either.  The reasoning is that in the case of a major network event (such as a hardfork), it is critical for us to be able to communicate with users (always offline-signed, of course!), to let them know how to deal with it.   A hard-fork can leave open a period of non-consensus that a resourceful attacker could exploit to reverse a transaction. 

This is communicated to you through the settings window, further down where you select the notification levels.  Only critical security notifications will be retrieved from the server at the highest level, but you can fully disable it with the command-line option.

[CircusPeanut]

Bug 1:

Replicate:

• make a new transaction, up until the Confirm Transaction screen
• close the confirm screen

Wallet is now completely non-responsive to all button clicks, must be force quit due to the close buttons not working.

Bug 3:

Replicate:

• make a transaction
• tick "use existing change address"

Text is squashed, if the window is made bigger the radio buttons don't work properly.

What's your version? I have seen bug #1 and #3 in the past, and I believe they are fixed now. I am unable to reproduce them with 0.91.99.11.

[doug_armory]

Bug 1:

Replicate:

• make a new transaction, up until the Confirm Transaction screen
• close the confirm screen

Wallet is now completely non-responsive to all button clicks, must be force quit due to the close buttons not working.

Bug 3:

Replicate:

• make a transaction
• tick "use existing change address"

Text is squashed, if the window is made bigger the radio buttons don't work properly.

What's your version? I have seen bug #1 and #3 in the past, and I believe they are fixed now. I am unable to reproduce them with 0.91.99.11.

Same here. Just tested on OS X, which appears to be what the OP is using. Everything works fine.

[PRab]

I got curious and ran "Rescan Databases" on my testnet wallet that said that the inputs were already spent and it resolved the issue. At least if it comes up again, there is an easy way to recover.

[redphlegm]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Startup & loading on my mac (Mavericks with latest updates) is significantly improved. I can't speak to stability though because it wasn't my main machine and I don't make many transactions on that machine. I'm sort of waiting on the "final" version though before I replace what I have on my main machine.

[redphlegm]

Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them. Say you set up a lockbox on one machine and you gather the public keys from elsewhere. Then the host / organizer machine crashes and there isn't a backup of the data on the machine. With the deterministic nature of regular wallets, this can be addressed with a paper / offsite backup of the deterministic keys. How do you back up the lockbox though or make it so another machine can spend from that multisig address if the organizing / original machine ends up becoming corrupt in some way?

[doug_armory]

Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them.

Your answer is here. Basically, all you truly need are for the private keys to be backed up (e.g., paper backups), although you can back up the lockbox definition and save yourself some setup time. As long as there are enough signing parties, you're good. If there's corruption, the keys will have to be restored.

[redphlegm]

Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them.

Your answer is here. Basically, all you truly need are for the private keys to be backed up (e.g., paper backups), although you can back up the lockbox definition and save yourself some setup time. As long as there are enough signing parties, you're good. If there's corruption, the keys will have to be restored.

Thanks for the prompt response. I actually just happened upon the answer (and have the same link in my clipboard to paste here actually). What about a case where the lockbox definition is lost on the organizing machine and neither / none of the others imported the definition? Is there a way, without the definition, to restore the lockbox? Let's assume the cases of you know the public keys / addresses that were originally used to create the lockbox, you know one key that was used to create the lockbox, and the rare case that you can't remember which key was used to create the lockbox (but maybe you know which wallet was used).

I hope my question here isn't too ignorant.

[doug_armory]

Thanks for the prompt response. I actually just happened upon the answer (and have the same link in my clipboard to paste here actually). What about a case where the lockbox definition is lost on the organizing machine and neither / none of the others imported the definition? Is there a way, without the definition, to restore the lockbox? Let's assume the cases of you know the public keys / addresses that were originally used to create the lockbox, you know one key that was used to create the lockbox, and the rare case that you can't remember which key was used to create the lockbox (but maybe you know which wallet was used).

Know all keys: Just create another lockbox that uses the keys. That's all you need to do.
Know only some of the keys: Uses the ones you do know and keep trying to build with the others. For example, let's say you know that a wallet with 20 addresses in it was used, but you don't know which address was used. You'll have to cycle through the addresses until you find a lockbox that works.
Know no keys: You're out of luck unless you know the wallets used and are willing to try hundreds, thousands, or possibly even millions of address combinations. (3 wallets with 100 addresses each = 100 x 100 x 100 = 1,000,000 possible combinations.)

[etotheipi]

Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them.

Your answer is here. Basically, all you truly need are for the private keys to be backed up (e.g., paper backups), although you can back up the lockbox definition and save yourself some setup time. As long as there are enough signing parties, you're good. If there's corruption, the keys will have to be restored.

Thanks for the prompt response. I actually just happened upon the answer (and have the same link in my clipboard to paste here actually). What about a case where the lockbox definition is lost on the organizing machine and neither / none of the others imported the definition? Is there a way, without the definition, to restore the lockbox? Let's assume the cases of you know the public keys / addresses that were originally used to create the lockbox, you know one key that was used to create the lockbox, and the rare case that you can't remember which key was used to create the lockbox (but maybe you know which wallet was used).

I hope my question here isn't too ignorant.

Ultimately, the list of the public keys is all that matters.  If know what public keys were used, you can recreate the lockbox.  If you just know what wallets were used, you'll eventually figure it out, though it might take a script to do.  Nonetheless you'll get your coins back.  But this should be mostly irrelevant we assume that not all your devices are losing it or getting destroyed, or you might have bigger problems.  As long as one of them still has the definition, you just export-import.

Or backup the multisigs.txt file to save yourself some time.  We just haven't made an option for it because we didn't feel it was necessary (though we'll have some automatic backup features with the new wallets, for saving address/tx labels and lockbox definitions)

[redphlegm]

Got it. Thanks, guys. Much appreciated.

By the way - in the OP you have a dangling

Code:

"[/list]"

[redphlegm]

I found something that one might consider a bug though it's just aesthetics. Mac client 0.91.99.9 running on 10.9.4.

When I start the client, the wallet list is fine:


If I click on a wallet in the list, however, to perhaps just select it or double click for more functionality, the title bar of the list turns blue and it doesn't change back unless I quit and restart the client. Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.

[doug_armory]

I found something that one might consider a bug though it's just aesthetics. Mac client 0.91.99.9 running on 10.9.4.

Thanks. We are aware of that bug. The code we're using in that particular section is still a little shaky. We'll figure something out eventually but definitely not for 0.92. (At this point, the code's basically frozen except for crashes and other showstoppers.)

[CircusPeanut]

Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.

That is in fact a collapsed column that I only found out about recently.

If you go to the Filter List Box below the table in the Transaction tab, and select "Custom Filter", you will get a column that allows you to hide or display ledger entries for selected rows.

[redphlegm]

Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.

That is in fact a collapsed column that I only found out about recently.

If you go to the Filter List Box below the table in the Transaction tab, and select "Custom Filter", you will get a column that allows you to hide or display ledger entries for selected rows.

That's interesting, and curiously enabling that and clicking to view / unview removes the blue hue on the title bar, but the small sliver remains. In any event, it's not a big deal.

Would you, dear devs, say that 0.91.99.11 is RC worthy for 0.92? i.e. is it safe enough to replace the previous version I have running on my main machine?

[etotheipi]

Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.

That is in fact a collapsed column that I only found out about recently.

If you go to the Filter List Box below the table in the Transaction tab, and select "Custom Filter", you will get a column that allows you to hide or display ledger entries for selected rows.

That's interesting, and curiously enabling that and clicking to view / unview removes the blue hue on the title bar, but the small sliver remains. In any event, it's not a big deal.

Would you, dear devs, say that 0.91.99.11 is RC worthy for 0.92? i.e. is it safe enough to replace the previous version I have running on my main machine?

We had actually planned to turn 0.91.99.11 into 0.92 today, but we have some non-code-related things to do before we officially release it.  Unless any critical bugs are found, we will simply be releasing 0.91.99.11 + polishing as 0.92 early next week.   Therefore, I believe the only difference between .11 and the official release is the ugly version number that will be displayed on the main screen

[doug_armory]

We had actually planned to turn 0.91.99.11 into 0.92 today, but we have some non-code-related things to do before we officially release it.  Unless any critical bugs are found, we will simply be releasing 0.91.99.11 + polishing as 0.92 early next week.   Therefore, I believe the only difference between .11 and the official release is the ugly version number that will be displayed on the main screen

Yep. ~97-98% of the code changes are in armoryd, and even the tiny bits that aren't really won't affect a huge majority of people out there. People should upgrade to 0.92 when it comes out, especially if they wish to use armoryd, but 0.91.99.11 is close enough, short of somebody contacting us in the next day or two with a catastrophic bug report.

[doug_armory]

Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

One at a time, although I can imagine a scenario where armoryd could be used to rapidly sign transactions.

Moreover, if we have a 2 out of 7 pool, then if 1 user signs it and sends the file to the balance 6 users and if 2 out of the 6 open it approximately the same time and sign and broadcast, does it send the money twice from the wallet?

No. Classic double spend scenario. One of the transactions would be rejected. It wouldn't matter since the other version went through.

[etotheipi]

Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

One at a time, although I can imagine a scenario where armoryd could be used to rapidly sign transactions.

Moreover, if we have a 2 out of 7 pool, then if 1 user signs it and sends the file to the balance 6 users and if 2 out of the 6 open it approximately the same time and sign and broadcast, does it send the money twice from the wallet?

No. Classic double spend scenario. One of the transactions would be rejected. It wouldn't matter since the other version went through.

Creating new transactions to sign before signing and broadcasting earlier ones is likely to lead to the later ones trying to spend the same coins and being invalidated.  Per lockbox, you can only have one outstanding transaction at a time and know that it will be valid when you sign it.  If we had coin control for lockboxes, it would be possible to do a few sequentially.

A transaction specifies what coins are being spent and where they are going.  Multiple copies of the same transaction are spending the same coins, thus if you try to broadcast a second copy (regardless of whether it's the same signatures or different), it will be rejected as a double-spend. 

[etotheipi]

Finally!  Released 0.92 but had some hiccups in the release process, so just put out 0.92.1.  Update with the secure downloader, or grab them from here:

  Armory 0.92.1 for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.1 for MacOSX 10.7+ (64bit)
  Armory 0.92.1 for Ubuntu 12.04+ (32bit)
  Armory 0.92.1 for Ubuntu 12.04+ (64bit)
  Armory 0.92.1 for RaspberryPi  (armhf)

  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.1 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.92.1: Signed hashes of all installers


If you are owed bounties and haven't sent me your payment address, please PM me.  I should get around to paying those out today (Weds) or Thurs.

Thanks to everyone who helped test the new version! 

[fran2k]

Finally!  Released 0.92 but had some hiccups in the release process, so just put out 0.92.1.  Update with the secure downloader, or grab them from here:

  Armory 0.92.1 for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.1 for MacOSX 10.7+ (64bit)
  Armory 0.92.1 for Ubuntu 12.04+ (32bit)
  Armory 0.92.1 for Ubuntu 12.04+ (64bit)
  Armory 0.92.1 for RaspberryPi  (armhf)

  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.1 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.92.1: Signed hashes of all installers


If you are owed bounties and haven't sent me your payment address, please PM me.  I should get around to paying those out today (Weds) or Thurs.

Thanks to everyone who helped test the new version! 

Awesome, thanks!

[helgabutters]

If you are owed bounties and haven't sent me your payment address, please PM me.  I should get around to paying those out today (Weds) or Thurs.

Hope all is well. I was just wondering if there was any more update to when the bounties will be sent out.

[CircusPeanut]

Hi all,

We are rewarding bug contributors with the following Bounties (0.03 Btc per bounty):

LOL - 1
PRab - 4
PodBayDoors - 1
SimonBelmond - 1
Searinox - 2
TimS - 1

(Note that this does not include Helgabutters who's bounties are being handled separately)

If you think that you are owed a bounty that is not included in this list, please let us know and reference the post with the bug.

For those on this list please post a public address for us to send your reward.

Thanks for everyone's contribution to this project. We really appreciate it and so do all of the Bitcoin Armory users.

[etotheipi]

For those on this list please post a public address for us to send your reward.

Actually, please PM with address since most people don't want it to be public.  Also, I have a few addresses that have already been given to me through email or PM, I'll pass them to you.

[SimonBelmond]

Hi all,

We are rewarding bug contributors with the following Bounties (0.03 Btc per bounty):

LOL - 1
PRab - 4
PodBayDoors - 1
SimonBelmond - 1
Searinox - 2
TimS - 1

(Note that this does not include Helgabutters who's bounties are being handled separately)

If you think that you are owed a bounty that is not included in this list, please let us know and reference the post with the bug.

For those on this list please post a public address for us to send your reward.

Thanks for everyone's contribution to this project. We really appreciate it and so do all of the Bitcoin Armory users.

As I have previously donated to Armory anyway, these 0.03 can be used to fund the next bug-bounty round. THX for everything you guys are providing! By the way, my offer here is still valid for anyone interessted: https://bitcointalk.org/index.php?topic=607046.msg7606568#msg7606568