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

You can also disable armory from running bitcoind itself and run bitcoin-qt separately.

Thank you, pankkake.

EDIT (original text removed to avoid confusion): Ah, I get it now.

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

Yes, but when I open armory, I don't have a GUI loaded of bitcoin-qt. Can I view the number of connections from the Armory GUI? If not, what is the recommended way to I launch Bitcoin-Qt's GUI without opening a 2nd instance?

EDIT: This is what I see when I try to open Bitcoin-Qt while Armory is already running:

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

Armory uses bitcoin-qt, so it's the same number.

N00b here. Search was unsuccessful. Is there a way to view the number of connections when using Armory, like is possible with Bitcoin-Qt?

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

If you want to examine the tx directly, you can load the tx into armoryengine and do something like this:


You'll get a higher-level overview of what's in the tx from the first pprint command, and then a hex breakout of the raw tx from the second command (if you feel like digging into the raw tx bytemap).  It's not pleasant, but if broadcasting is failing, it's probably invalid and you need to figure out why.

Doesn't work there either. There's something about their binary format that no other tool seems to like.

I never got around to implementing that, because I wanted the user to be able to examine the transaction before they click broadcast, but a raw transaction doesn't have all the info it needs (refer to SIGHASH_WITHINPUTVALUE discussion).  I probably should've put something in there anyway with a warning, but I never got around to it.

I suggest using https://blockchain.info/pushtx

Sometimes Coinbase forgets (apparently) to broadcast a transaction, even though it shows up in their own blockchain browser.

It will show you the transaction in binary or json formats. Anyone know how to convert one of those formats into something that can be pasted into the Armory offline transactions window and broadcast?

Here's a random example:

https://coinbase.com/network/transactions/b7697479993e54eb6594d607904e3a9c65692124f9b9bcba5a16bb5affe173fc

I opened the binary file in Okteta (hex editor) and tried copying it to the clipboard as a variety of formats, but none of them worked.

That turned out to be a bug that made it's way into the released version, but doesn't affect performance or functionality at all.  It should be fixed in the testing version, and will not be there for the next version ... but the worst thing it does is make the logs harder to access/read.  It's unrelated to the crashing.

---

Just to keep things consistent, there was a reddit post asking if Armory was dead.  Here's my response:

Did you try completely reinstalling? That doesn't seem like a text encoding issue.

It is getting worse with time unfortunately, the last time this crash-before-initialize was right after other crash, when I needed access to my bitcoins asap Maybe it is unrelated to unicode bugs...BTW, i had log full of this messages
Tens of these messages by second...

It's extremely annoying, but I've never had it crash that soon.

etotheipi, what about this "non-US" bugs, random crashes on my Linux is very annoying:
I think that made Armory almost unusable for me, sometimes Armory can`t even process blockchain before it crashes

@etotheipi: can the view on blockchain.info option go to the https site rather than http

For those interested, I got a few more quotes in the paper today.  This time USA Today!

http://www.usatoday.com/story/news/politics/2013/08/26/bitcoin-virtual-currency-regualtions/2702653/

There is a "Copy Raw Tx (Hex)" button on the "Sign and/or Broadcast Offline Transaction" window.  You could look for that button in the python code and copy what it's doing.  I'd look it up for you, but I'm on my phone.   I believe that you have a "TxDP" object which represents the signed transaction, and you do something like "txdp.prepareFinalTx()".   That should give you a raw binary transaction in the form that all other nodes on the network recognize.

On that same window is the "Broadcast" button which also should lead you to how I implement broadcasting to the connected bitcoind/-qt instance.  If you already have a running instance of Armory, it should be easy (because it's already connected), but it may take some work if you're writing an isolated script.

I have been working in the "ramreduceleveldb" branch for the past couple months.  I've been heavily distracted, so progress hasn't been as voluminous as I'd hoped, but progress is being made (see a few posts up about the most recent unit tests I passed).  I ran into issues with the new DB stuff being bottlenecked by SatoshiDice addresses and 1VayNert, but I should have the updates for that soon and then will start integrating the new DB stuff into the python layer.  For reference, this first version will use a lot of HDD space -- probably 1.7X the blk*.dat files -- but will provide instantaneous arbitrary address lookup (balances and UTXO sets).  This was the easiest to implement, and when this is done I'll be in a good position to implement much lighter variants. 

We've just started integrating armory / armoryd into our new site (for offline cold storage stuff) - is there some reference code for broadcasting a newly signed transaction? (or converting it into standard bitcoind format and then we can broadcast from there)

also - how come the github code hasnt been updated for a while - there are loads of small fixes that could have been merged - do you have a private dev branch that you work from instead?

I should mention that the timings are artificially inflated due to the fact that it destroys and rebuilds a testing database on every test.  This means there's quite a bit of hard disk I/O involved in just the SetUp and TearDown procedures, and executing a small batch of writes comes with huge overhead.  It will not take 0.6 seconds to add 5 blocks to the DB when doing a full database build...

With re-org handling implemented, I will start benchmarking DB building on much larger data sets (more than 5 blocks).  And then I'll see what has to change to hook this up to the GUI.  The upside is that nearly all the interfaces are the same, so the GUI probably won't see much change (other than not having to wait for startup and importing wallets).  The downside is that some stuff did change:  I added C++ support for compressed keys, multi-sig and P2SH.  This means I need a translation layer for the old wallets to work right until the new wallet format is complete.

But yeah... progress...