Armory - Discussion Thread

[bitpop]

As far as I know armory doesn't use rpc like that, it reads the database natively and has its own parser which you could borrow

[po0kie]

I think all the needed stuff is in the ArmoryQT Heartbeat.
But I am not really aware which functions are necessary to be called to make it "temporarily sync" until new confirmations
arrive.

Or maybe I am totally wrong

[etotheipi]

Hi!

First of all: Amazing work done by Armory Dev's!

I am working with the Daemon (extending it at moment to support Tx Offline Signing, and Broadcasting)

And i got a Little problem at the moment, maybe some of the Devs can point me to the right direction to get it working.

The Broadcast is nearly ready to use in ArmoryD, the problem I got is:
New Transaction Requests  over the same SourceAddress  of the previous Tx  will fail until the BDM gets notified about Confirmations
from BitcoinD.

Its like he want to spent the same TxInputs and then the Tx will fail in Broadcast. I saw  ArmoryQT  maintaining a combinedLedger.
(appending ZeroConf Ledger Entries to the combinedLedger)
But I have not see any relation to the BDM with the combinedLedger (maybe i am missing something, Its the first Project i am touching python.)

Or How ArmoryQT get it working to not fail on next Tx’s when the previous Tx’s isn’t already +1 Confirmation?
It seems to me that ArmoryQt “makes in some way a manual sync” to be able to realize a next TX.

Any point to direct me where I can follow the needs?

Thanks!

poOkie, I'm not sure what exactly the problem.  It sounds like you might be running into the issue of making multiple offline tx and trying to sign them without first broadcasting one of them.  Armory currently can't handle this situation, and you will have to create-sign-broadcast a tx before you can create the next tx (you can create the next tx, though it will probably be invalid).

Btw, there's a script the in extras directory called "cli_sign_txdp.py" which has example code for you.  You may have found that, or may have already reimplemented it.  Just wanted you to see it.

[po0kie]

Yeah thats exactly what I am doing.
I am creating a queue for pending Tx's

I Get tge first Item (when no other Tx is in Work)
create a unsigned -> pass it to another worker make it Signed -> and get back to the other woker to make the broadcast.
after the broadcast I get the next item in queue and so on.

It works if the queue waits to start with next item (to create unsigned) until it gets at least 1 confirmation then there is no problem
but if I get on to the next item to mak an unsigned (1 minute after previous broadcast) then this happens:



The exact error occurs here:
class PyTxIn(object):
   def __init__(self):
      self.outpoint   = UNINITIALIZED
      self.binScript  = UNINITIALIZED
      self.intSeq     = 2**32-1
      self.isCoinbase = UNKNOWN

   def unserialize(self, toUnpack):
      if isinstance(toUnpack, BinaryUnpacker):
         txInData = toUnpack
      else:
         txInData = BinaryUnpacker( toUnpack )

      self.outpoint  = PyOutPoint().unserialize( txInData.get(BINARY_CHUNK, 36) )
      scriptSize     = txInData.get(VAR_INT)
      if txInData.getRemainingSize() < scriptSize+4: raise UnserializeError

       #values: ? txInData.getRemainingSize() = 45
       # ? scriptSize + 4 = 95

it raises an UnserializeError.

It does not happen if I select another Address of the wallet.

It should be something with the txoutlist (staying out of sync)??

[etotheipi]

Yeah thats exactly what I am doing.
I am creating a queue for pending Tx's

I Get tge first Item (when no other Tx is in Work)
create a unsigned -> pass it to another worker make it Signed -> and get back to the other woker to make the broadcast.
after the broadcast I get the next item in queue and so on.

It works if the queue waits to start with next item (to create unsigned) until it gets at least 1 confirmation then there is no problem
but if I get on to the next item to mak an unsigned (1 minute after previous broadcast) then this happens:



The exact error occurs here:
class PyTxIn(object):
   def __init__(self):
      self.outpoint   = UNINITIALIZED
      self.binScript  = UNINITIALIZED
      self.intSeq     = 2**32-1
      self.isCoinbase = UNKNOWN

   def unserialize(self, toUnpack):
      if isinstance(toUnpack, BinaryUnpacker):
         txInData = toUnpack
      else:
         txInData = BinaryUnpacker( toUnpack )

      self.outpoint  = PyOutPoint().unserialize( txInData.get(BINARY_CHUNK, 36) )
      scriptSize     = txInData.get(VAR_INT)
      if txInData.getRemainingSize() < scriptSize+4: raise UnserializeError

       #values: ? txInData.getRemainingSize() = 45
       # ? scriptSize + 4 = 95

it raises an UnserializeError.

It does not happen if I select another Address of the wallet.

It should be something with the txoutlist (staying out of sync)??

Coincidentally, I just ran into a problem with this in another context.  It does seem that the new code sometimes fails to get the tx properly from TheBDM when the tx is not yet in the blockchain.  It should work, and has worked before (before 0.90), but it may have broken during the upgrade and I didn't notice it.  I will have to verify that the zero-confirmation transactions can be properly retrieved from TheBDM before they are mined.

[po0kie]

Oh ok perfect. good to know, was getting crazy the last 3 days
Do You go to notify here on this thread when got news about the fix?
Do you think it will get fixed before release of 0.91? Or directly within 0.91?

Thanks!

[etotheipi]

Oh ok perfect. good to know, was getting crazy the last 3 days
Do You go to notify here on this thread when got news about the fix?
Do you think it will get fixed before release of 0.91? Or directly within 0.91?

Thanks!

Probably 0.91.

[Corelianer]

+0.1 BTC from me for the good work set just now to 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv

[Kluge]

Fwiw, https://bitcoinarmory.com/get-armory mentioned a couple times in OP gives 404.

[tazdas]

Hi

Not sure if this is the right thread to report bugs or report problems, but I am having lots of problem running armory.

After block chain synchronization, Armory just hangs . I have tried deleting all armory files and uninstalling it but same thing after new DB Armory install and DB sync/construction and importing the wallet.

Initially armory worked fine but as I got more transactions in my wallet it became slower and now its just handing

Armory version = 0.90 Beta
Bitcoin version = 0.8.6

Windows 7 pro x64

Armory log shows the following:


2014-01-22 01:21 (INFO) -- armoryengine.pyc:12479 - Reading blockchain, pct complete: 98.8
2014-01-22 01:21 (INFO) -- armoryengine.pyc:12479 - Reading blockchain, pct complete: 99.3
2014-01-22 01:21 (INFO) -- armoryengine.pyc:12479 - Reading blockchain, pct complete: 99.8
2014-01-22 01:21 (INFO) -- ArmoryQt.py:4475 - Dashboard switched to "Scanning" mode
2014-01-22 01:21 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:ScanWithWallets
2014-01-22 01:21 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:Auto, State:NewUserInfo
2014-01-22 01:21 (INFO) -- ArmoryQt.py:3780 - Switching Armory functional mode to "Scanning"
2014-01-22 01:23 (INFO) -- ArmoryQt.py:4465 - Dashboard switched to fully-online mode
2014-01-22 01:23 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-01-22 01:23 (INFO) -- ArmoryQt.py:3780 - Switching Armory functional mode to "Online"
2014-01-22 01:23 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-01-22 01:23 (INFO) -- ArmoryQt.py:4465 - Dashboard switched to fully-online mode
2014-01-22 01:23 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-01-22 01:23 (INFO) -- ArmoryQt.py:3780 - Switching Armory functional mode to "Online"
2014-01-22 01:23 (INFO) -- ArmoryQt.py:3838 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-01-22 01:23 (INFO) -- ArmoryQt.py:1913 - Syncing wallet: G37XXX
2014-01-22 01:23 (ERROR) -- armoryengine.pyc:12346 - BDM was not ready for your request!
Waited 20 sec.
2014-01-22 01:23 (ERROR) -- armoryengine.pyc:12347 -   getattr   name: scanRegisteredTxForWallet
2014-01-22 01:23 (ERROR) -- armoryengine.pyc:12348 - BDM currently doing: Passthrough (43010396)
2014-01-22 01:23 (ERROR) -- armoryengine.pyc:12349 - Waiting for completion: ID= 43010396
2014-01-22 01:23 (ERROR) -- armoryengine.pyc:12350 - Direct traceback
2014-01-22 01:23 (ERROR) -- armoryengine.pyc:12353 - Traceback:

[btcsql]

Armory is stuck at Block 281532 even though Bitcoind is up to date, any ideas? Nothing non-obvious in the logs either.

Edit: just deleted the database folder in Armory and restarted, fixed itself.

[eggdescrambler]

Is it possible to have bitcoin Armory use an external blockchain rather than downloading the whole blockchain on my computer?
It would be nice to have that option.  At some point, it won't make sense to download terabytes of the blockchain and should be left to specialized miners/servers offering that service. 

[bitpop]

Is it possible to have bitcoin Armory use an external blockchain rather than downloading the whole blockchain on my computer?
It would be nice to have that option.  At some point, it won't make sense to download terabytes of the blockchain and should be left to specialized miners/servers offering that service. 

Then use electrum

[goatpig]

Is it possible to have bitcoin Armory use an external blockchain rather than downloading the whole blockchain on my computer?
It would be nice to have that option.  At some point, it won't make sense to download terabytes of the blockchain and should be left to specialized miners/servers offering that service. 

We plan on implementing that eventually.

[Peter Todd]

I can't speak for the Armory devs, but one nice thing about implementing stealth addresses in Armory is that it already has the machinery to scan the blockchain; you could easily use stealth at the highest privacy level where any stealth tx that's sent could be going to you. (zero-filtering)

It's something to consider about Armory in general: because it can work so easily with a local full-node you always have excellent privacy with regard to the contents of your wallet. All the queries are local, so info on what coins are in your wallet never leaves your machine. That's much better than SPV clients like Android Wallet where every peer you connect to learns statistical info narrowing down your addresses to within about one in 10,000 or so, or Electrum which currently just tells peers what addresses are in your wallet.

I'm very interested in this feature.  It's just that it still sounds very theoretical at the moment.  I'm also concerned about how much computation it will be to track the addresses ... ECDH calculations aren't cheap.  I guess I'm still in a waiting mode, implementing other things while I wait for this to be ironed out (I don't have much to contribute to the discussion, though I have spent a lot of time thinking about how to get the same benefits without all the ECDH calcs).

By my standards, stealth addresses are pretty concrete. But yeah, part of why I was interested in working with someone was to nail down some of the implementation issues in a real-world client, speed being one of them. My basic idea was to have a bandwidth/speed/privacy tradeoff, and there's some interesting ideas being discussed right now on what's the best way to do that.

One key implementation question is can the Armory codebase handle addresses where to pay them you have to make a transaction with not just one, but two specific txouts?

Peter:  Btw, I'm working on P2SH support right now.  You will be able to test it on 0.91-dev in the next couple days.  In fact, it seems to be working right now, on the p2shout branch -- you can try it right now, though I wouldn't do anything other than testnet.  

As part of the update, I modified the PyTxDistProposal::createFromTxOutSelection() method to take any arbitrary list of script-value pairs, instead of just hash160 values.  Right now, it will error out if you supply it something other than an P2PubKeyHash or P2SH, but that could be modified locally to create a tx with any arbitrary output scripts.  As long as all the inputs are standard UTXOs, you can create such a tx and sign it no problem (have fun getting it mined, though).

Excellent! Sorry for the late reply, but I finally got a chance to try that branch out. Looks fine to me, although I see the odd IndexError on the console, not sure if it's related:

(ERROR) Traceback (most recent call last):
  File "/home/pete/src/bitcoin/BitcoinArmory/qtdialogs.py", line 9301, in showContextMenuTx
    idx = self.addrBookTxView.selectedIndexes()[0]
IndexError: list index out of range

[etotheipi]

By my standards, stealth addresses are pretty concrete. But yeah, part of why I was interested in working with someone was to nail down some of the implementation issues in a real-world client, speed being one of them. My basic idea was to have a bandwidth/speed/privacy tradeoff, and there's some interesting ideas being discussed right now on what's the best way to do that.

One key implementation question is can the Armory codebase handle addresses where to pay them you have to make a transaction with not just one, but two specific txouts?

Once we have an address format and a recipe for converting/calculating the correct values, it will be "easy."  Sending to two txouts is not complex at all, it's identifying them which may take a little work, since the code base currently assumes everything it needs to know about a TxOut is contained in that TxOut.  But of course, I'll make it happen if this is a popular idea.

Excellent! Sorry for the late reply, but I finally got a chance to try that branch out. Looks fine to me, although I see the odd IndexError on the console, not sure if it's related:

(ERROR) Traceback (most recent call last):
  File "/home/pete/src/bitcoin/BitcoinArmory/qtdialogs.py", line 9301, in showContextMenuTx
    idx = self.addrBookTxView.selectedIndexes()[0]
IndexError: list index out of range

Nice timing, I just merged a whole bunch more changes into 0.91-dev.  I think most things are functional, including sending to and displaying P2SH addresses.  If you have scripts that spend P2SH outputs, please try it out, since I don't yet have a way to test if my P2SH TxOuts are valid (though they are so simple, I don't know how I'd get it wrong, but of course nothing beats seeing it work).

The error looks like you somehow right-clicked to get a context menu without selecting an address in the addr book to show.  Perhaps you right-clicked in an empty area of the address book?  Either way, it's nothing to worry about.

[cp1]

Is there a way to import multiple wallets at once, without rescanning in between?   Can I just copy the .wallet file to my armory directory?  I'm in the process of reinstalling my OS and switching to 0.9-beta and it's taking 10 minutes to rescan between wallet imports.

[bitpop]

Is there a way to import multiple wallets at once, without rescanning in between?   Can I just copy the .wallet file to my armory directory?  I'm in the process of reinstalling my OS and switching to 0.9-beta and it's taking 10 minutes to rescan between wallet imports.

Yes just put in directory once

Or do it offline mode

[cp1]

I figured, just didn't want to take a chance of something going wrong.

[picobit]

Is there a way to import multiple wallets at once, without rescanning in between?   Can I just copy the .wallet file to my armory directory?  I'm in the process of reinstalling my OS and switching to 0.9-beta and it's taking 10 minutes to rescan between wallet imports.

That is perfectly safe - I have done it several times.