If you haven't made any changes to the source, I would wipe the folder, clone the repository again, checkout testing, and try again. You shouldn't be getting errors like that while compiling.

Also, did you install all the dependencies listed here? What operating system are you running?

p.s. Etotheipi, you should clean up your github branches, it can be quite confusing determining which one to use.

The branch you actually want is "testing". It was last updated 5 days ago, compared to dev which was last updated 4 months ago.

This seems like a bad idea. Armory will have no way of knowing if the transaction was accepted by the network or not. If you're not connected to any nodes with non-standard fee relay rules (is that even really a thing?), then your transaction silently fails.

What is the benefit of submitting it to blockchain.info over the local instance of bitcoin that you have to be connected to anyway?

It's not that the GUI functionality to add watching only keys is a potential vulnerability, it's that telling users "hey, you received money" when they may not have is.

etotheipi has been resistant to this feature because you wouldn't be able to tell if you inserted the public keys into your wallet or a potential attacker, leading you to think you had receive money but not actually having done so.

It sounds like these were devices with internet access that served as a gateway to devices with only serial access. The internet devices were insecure and allowed attackers access to the serial devices just as they would an authorized user. This is different than the model we're using in that we assume the online device can compromised and are designing a system such that the serial device can cope with that threat.

I haven't updated mine in a while. I don't think it's really necessary unless there are bugs fixed or features added, but most often the changes seem to be in the online functionality.

They keep the first post updated with this status.

I would highly recommend following the guide here to get a cross-compiler set up for the Pi. Compiling on the Pi itself seems like a form of masochism.

You can use the offline_server branch of my fork. It's based on etotheipi's latest testing branch.

You'll have to disable the serial TTY on the Pi. I used this guide. Then compile Armory for the Pi. I used this guide. Finally plug the Pi into your computer (it can be powered by the serial cable), transfer the compiled files (from a USB drive, not over the serial cable!) and run extras/offline_serial_server.py (for me it's /dev/ttyAMA0 and baud rate 115200).

For your online computer, you'll have to be in advanced or expert mode, then you can set the device and baud rate in the settings dialog. Once that is complete, you should see the status change to connected in the bottom right. Now, on the dialog from which you can save an offline transaction, you can also transmit it to the offline device. You'll be prompted for the wallet passphrase if your wallet is encrypted. Enter it on the Pi's keyboard. Once the Pi transmits the signed transaction back to your computer, it will automatically advance to the Broadcast dialog.

It should be pretty easy to use, but I created it so maybe that's just me.

Then how would you know when sending a transaction if you need to include a fee or not?

edit... I hadn't yet read Gavin's first post. That does sound like a much more elegant solution.

I should have saved information from the popup, but upgrading from 0.87 or so on Windows, I was getting a crash immediately on startup. Uninstalling, deleting the ArmoryBitcoin folder, and reinstalling fixed the problem. I've upgraded a few times so were some old files left in there when I deleted it. After reinstalling starts up no problem.

Auto-installation went smoothly! This is actually pretty awesome because I don't have a persistent bitcoin daemon running on my Windows partition.

Oh, and I love the new scanning progress bar with estimated time to completion. Very slick.

I'm really looking forward to Armory persisting its own blockchain data, I'll gladly trade disk space for memory (using 2.5 GB now). Do you have any idea how much faster startup should be? Is it looking like that's going in the next release?

I'm thinking they don't, since I just got this email:


Of course, this is after I imported the key into Armory and sent the transaction with a fee, not sure if that's just a coincidence.

I think the calculation only happens when a node first receives the transaction. Since it didn't meet the minimum priority at the time, nobody relayed it and the only one that knows about it is blockchain.info. Nothing else would make sense, since nodes wouldn't keep invalid transactions around so they could relay them in the future in case they became valid. They just forget about them. That is of course assuming that blockchain doesn't rebroadcast unconfirmed transactions sent through its service.

I interpreted the conditions as meaning one of them had to be met, not all of them, but upon rereading I'm probably incorrect.


Thank you, I'm not sure why I didn't think of that, given that's one of the big benefits of blockchain's wallet model. Blockchain.info might see it as a double spend but the rest of the network doesn't know about the transaction.

There is also this: Its priority is large enough, but since the 6 BTC input was only 1 block old, I don't think the priority was large enough.

So it looks like this transaction was never relayed and will never be included in a block. If this was my own wallet, I would remove the transaction manually and create another one with a fee. Since it's a blockchain wallet, what can be done about this?

I understand this and shouldn't have even brought up the change issue. But since when does bitcoin prioritize based on individual output amounts instead of entire transaction amounts? As in, why would it ignore the 6.2 BTC output when determining that the other one is "too small"? I don't think that's how it works.

From the Wiki:


Given that the larger input was very recently confirmed, it makes sense that the transaction is a low priority. But not being included in a block for over a day seems out of the ordinary. Granted, I always pay transaction fees. With the obvious exception of this time, since Blockchain's Android app wanted me to pay 0.005, so I hit cancel, and then it sent the transaction without a fee.

Because the buyer is given the confirmation code in advance, and the seller is only given it after they release the funds.

That should matter, that's just the change output, the other is for 6.2 BTC.

Piuk,

Can you tell me what's going on with this transaction? Is it really such a low priority that it hasn't been included in more than 100 blocks, or is something else going on?

https://blockchain.info/tx/fc6fe646edd319624053e4589f880e3461382b61fff0310380879febdc3aff2a