Armory - Discussion Thread

[etotheipi]

99% agreed, with the caveat that point 1 will be 100% true the
moment etotheipi plonks an mmap('blk0001.dat') somewhere in
there: right now, anything that gobbles up 1.5G or RAM to send
one BTC isn't usable in the real world.

It's not quite that simple, but it's close.  I already got this working in the mmap branch in Linux and started testing on a Ubuntu 10.04 VM with 1GB of RAM.  But I got a bit more testing there, and get it ported to Windows, too (requires a preprocessor branch).   Hopefully I'll have all that done and implemented in the next month!

[terrytibbs]

How's about you go back 5 posts and read the authoritative answer on
the topic.

I see the post on the JSON-RPC interface, and apologize for not noticing it earlier. See below on how my point regarding a merchant-specific API still stands.
Perhaps I was not clear on this earlier.

Also: there's a whole host of features in Armory that would be essential
on a merchant site : offline txs and multi-wallets to name a few.

Offline wallets are useful to merchants, but would obviously never be connected to the website directly. I never said Armory wouldn't be useful to merchants, I said I believed it would never (never is a strong word, let's say "in the near future") have an API for merchant-specific interaction.

So, next time, get brain in gear before dumbly applying pressure
to caps lock key.

Ad hominem attacks? Classy!


I feel we are digressing from the topic on hand, but I'd like to sum up by saying that, and this is with etotheipi's own words, that Armory is a "client". It is not a daemon. It is not a server. It is a client. While it may be or become useful to merchants, it is, in its current incarnation, a client.

It will probably never be able to reach the speed of the compiled C++ daemon.
I'm also uncomfortable seeing Red Emerald compare Armory with bitcoind: "[...] Armory will be far better than bitcoind." That is like comparing apples to oranges. It does not compute.

If you would like to continue this discussion, please create a new topic, or send me a PM. I feel at least I've littered this thread enough. Sorry!

[Red Emerald]

It will probably never be able to reach the speed of the compiled C++ daemon.
I'm also uncomfortable seeing Red Emerald compare Armory with bitcoind: "[...] Armory will be far better than bitcoind." That is like comparing apples to oranges. It does not compute.

If you would like to continue this discussion, please create a new topic, or send me a PM. I feel at least I've littered this thread enough. Sorry!

Once armory can handle the block chain without bitcoind and has a JSON-RPC, it won't be apples to oranges any more...

[Red Emerald]

It will probably never be able to reach the speed of the compiled C++ daemon.
I'm also uncomfortable seeing Red Emerald compare Armory with bitcoind: "[...] Armory will be far better than bitcoind." That is like comparing apples to oranges. It does not compute.

If you would like to continue this discussion, please create a new topic, or send me a PM. I feel at least I've littered this thread enough. Sorry!

Once armory can handle the block chain without bitcoind and has a JSON-RPC, it won't be apples to oranges any more...

Mmmh.

Does Armory implement any of the p2p mechanics ?

Not yet.  Right now it lets bitcoind handle all of that.  I think this was a smart move since it dramatically reduces the amount of code needed to start.

etotheipi has a lot to work on.  Right now Armory is a good (but alpha) client.  It's goal is to be much more.

Also, if the python is too slow (which is not a problem worth dealing with right now), a library like libbitcoin could be used.

[etotheipi]

(1) Armory does use custom C++ blockchain code under-the-hood:  but it's only for reading and scanning the chain ridiculously fast.  Those methods will modified to be more appropriate for a production client -- it was originally was developed as an fun experiment in ultra speed-optimization, before the blockchain was 500 MB large, and then adapted when I started developing the client.   I specialize in data-structures, and at the time of writing the library, my focus was on speed optimization (and I succeeded), but not space-optimization.  That will change and I look forward to doing it... and doing it really well

(2) A lot of the robustness in Armory comes from leveraging bitcoin-qt/bitcoind for networking -- which implements all the state-of-the-art Bitcoin networking so I don't have to.  It is in my plans to merge an existing networking base into Armory, not re-implement it.  It could be 2-6 months worth of work to re-implement all the networking, and in the end it will be worse.  Plus, if 50% of users use program A and 50% use program B, then it's way too easy to end up with a blockchain fork -- which is a obviously sub-optimal.   

I'd really love to see the main devs isolate their networking code so that can be used for integration into other clients (like this one).  Maybe that's what libcoin is for.   The devs have done an amazing job with the security and networking robustness, and I think it's a good thing for others to be able to use that to avoid having to spend 3+ months reimplementing...

[etotheipi]

So, going back to one of my earlier questions ... is the 'send from'
feature (like the coderr patch in this thread : https://bitcointalk.org/index.php?topic=24784.0)
anywhere on your list ? Is it hard to pull-off at the code level ?

I'd donate generously to see that happen ...

I'm working on a code example for you, that will allow you specify a list of addresses and a list of [recip, amount] pairs, and it will create a signed transaction with minimum acceptable  transaction fee.  As I look through the code, it's not trivial to make it happen, but it's not a lot of code, either -- you just have to string together the right set of calls.   If you have a more-specific request, I'll adapt to it.

I've been told many times that I should do some of that anonymity stuff.  I probably will eventually... 

[cypherdoc]

Armory is getting dangerously close to being useful

And the insult of the year award goes to... znort987!

Not meant as an insult in any way.

Great potential, great and fast progress, but as
of today, featurewise, not yet a match for the
satoshi client.

elaborate.

[cypherdoc]

anything that gobbles up 1.5G or RAM to send
one BTC isn't usable in the real world.

Opinions are nice, let me share mine. Armory is hands-down, without a doubt, the absolute best Bitcoin client in existence. All my Bitcoins are now on Armory wallets.

The security provided by offline transactions is priceless to me, and if it was the ONLY difference between Armory and the Satoshi client, it would be enough for me.

Offline transactions work for the average user right now! I wish I could say the same for P2SH.

Armory could use 16 GB of ram and I would upgrade my computer in order to be able to use it, because the security provided by offline transactions is priceless.

Plus, being able to view my balances and transactions using offline wallets without worrying a bit about security is downright convenient.

When the real world is full of hackers and thieves, any client without offline transactions isn't usable in the real world. 

this is exactly right.

[Kluge]

Disabling the minimum fee still requires >.005BTC to send. I wanted to consolidate a wallet (the sending wallet contains .004BTC) out of OCD tendencies and ignore the fee (as I'm unable to pay it), but was prevented from doing so on the basis that I cannot cover the fee (even though I set it @ 0BTC).

[cypherdoc]

Disabling the minimum fee still requires >.005BTC to send. I wanted to consolidate a wallet (the sending wallet contains .004BTC) out of OCD tendencies and ignore the fee (as I'm unable to pay it), but was prevented from doing so on the basis that I cannot cover the fee (even though I set it @ 0BTC).

minimum fee is 0.0005 BTC.

eto already said you can modify the program to 0 fee.  you just might get stuck tho.

[etotheipi]

Disabling the minimum fee still requires >.005BTC to send. I wanted to consolidate a wallet (the sending wallet contains .004BTC) out of OCD tendencies and ignore the fee (as I'm unable to pay it), but was prevented from doing so on the basis that I cannot cover the fee (even though I set it @ 0BTC).

So it turns out that while I originally advertised i can do actually zero-forced tx fees, I can't *actually* force it to do it.  Since you are transmitting your tx through one satoshi client, which has a min tx fee for such transactions, it will not forward it and is DOA.  So I can't actually do zero fees if the satoshi client wouldn't accept it (but Armory has the appropriate fee "schedule" built into it, so it will always give you a good fee "requirement."

For reference, if the tx has any output less than 0.01, it requires a fee of 0.0005.  If it has low priority (sum of BTC*numConfirmations of each input), then it will require a fee of 0.0005.  If the final transaction is too big, it will require a fee based on how big it is.  And that is 0.0005.  Not 0.005.   So yes... if you have exactly 0.0004 BTC there will be no way to spend it.

The satoshi client would do the same thing.  If it really bothers you, I'll send you 0.01 coins to compensate you for your troubles

[Kluge]

Disabling the minimum fee still requires >.005BTC to send. I wanted to consolidate a wallet (the sending wallet contains .004BTC) out of OCD tendencies and ignore the fee (as I'm unable to pay it), but was prevented from doing so on the basis that I cannot cover the fee (even though I set it @ 0BTC).

So it turns out that while I originally advertised i can do actually zero-forced tx fees, I can't *actually* force it to do it.  Since you are transmitting your tx through one satoshi client, which has a min tx fee for such transactions, it will not forward it and is DOA.  So I can't actually do zero fees if the satoshi client wouldn't accept it (but Armory has the appropriate fee "schedule" built into it, so it will always give you a good fee "requirement."

For reference, if the tx has any output less than 0.01, it requires a fee of 0.0005.  If it has low priority (sum of BTC*numConfirmations of each input), then it will require a fee of 0.0005.  If the final transaction is too big, it will require a fee based on how big it is.  And that is 0.0005.  Not 0.005.   So yes... if you have exactly 0.0004 BTC there will be no way to spend it.

The satoshi client would do the same thing.  If it really bothers you, I'll send you 0.01 coins to compensate you for your troubles

Had I read the error message entirely, I wouldn't have wasted your time.  I did have .004BTC, and it demanded .0005BTC fee, which I was trying to ignore. I can send .0035BTC with .0005BTC fee, no problem, and that satisfies my desire not to look at a balance of .004BTC in a wallet. Sorry about that. 

[cypherdoc]

For reference, if the tx has any output less than 0.01, it requires a fee of 0.0005.  If it has low priority (sum of BTC*numConfirmations of each input), then it will require a fee of 0.0005.  If the final transaction is too big, it will require a fee based on how big it is.  And that is 0.0005.  Not 0.005.   So yes... if you have exactly 0.0004 BTC there will be no way to spend it.

do u mean that if i want to send 1 btc, for instance, if one of the input addresses has <0.01 in it, then i will HAVE to pay a fee of 0.0005?

is this why sometimes i notice i can send a tx w/o any fee and other times am forced to pay 0.0005?  i didn't know these restrictions existed.

[etotheipi]

For reference, if the tx has any output less than 0.01, it requires a fee of 0.0005.  If it has low priority (sum of BTC*numConfirmations of each input), then it will require a fee of 0.0005.  If the final transaction is too big, it will require a fee based on how big it is.  And that is 0.0005.  Not 0.005.   So yes... if you have exactly 0.0004 BTC there will be no way to spend it.

do u mean that if i want to send 1 btc, for instance, if one of the input addresses has <0.01 in it, then i will HAVE to pay a fee of 0.0005?

is this why sometimes i notice i can send a tx w/o any fee and other times am forced to pay 0.0005?  i didn't know these restrictions existed.

It's an output of less than 0.01.  It's creating "dust spam".  The main goal is to prevent someone from spamming the network with millions of tiny transactions.  

If someone tries to convert 1 BTC into 10,000,000, one-satoshi outputs they break the size limit.  If they try to send out 10,000,000 transactions of 1 satoshi each, they must pay 0.0005 for each one.  If they split coins into 0.01 increments to avoid the dust-fee requirement, they have to keep resending the same coins over and over, but then the priority criteria  will require a 0.0005 fee because all subsequent transactions will use really young coins ("priority" of each input:  BTC*numConfirmations;  a transaction can only be free if the sum of the priorities exceeds 144 which is one BTC after one day).  

There are extra, dynamic, factors based on the current number and size of existing transactions queued up in the next block, but it's pretty much irrelevant at the moment since the network doesn't even come close to filling up blocks.

I have the full set of rules in the calcMinSuggestedFees() method in armoryengine.py.  That doesn't take into account the dynamic blocksize considerations but it guarantees that your tx will be included on the next block that has space, which is pretty much all of them given the current transaction volume.

If you are wondering why some things require fees and other don't: it's kind of random ... if you have to combine 30 inputs to send 1 BTC, you will exceed the size threshold and pay a fee.  Or if it's a few inputs a combined priority of less than 144:  but if you wait two hours later, the combined prioirty breaks through then can be free.  In both cases, you don't realize that it's happening:  you just try to send 1 BTC, and you don't know if it has to combine hundreds of inputs, use young coins, or it could even [accidentally?] create a change output that is dust.  That's why it appears random.

The Armory algorithm takes into account all these factors, and will try to optimize the SelectCoins algorithm to minimize transaction fee and anonymity.  If you have a lot of coins, there may be thousands of different ways to construct a given transaction.  Armory gives equal weight to "avoid transaction fee" and "link as few input addresses as possible".  In the future, I will have an option to allow the user to select what they would like to optimize -- perhaps they're willing to pay a mandatory fee if it links less input addresses and makes the change output indistinguishable from the recipient output.

Fwhew!  I explained a lot more than you were expecting!  I guess I don't have enough to do, these days  (just kidding, I'm working feverishly on RAM-reduction.. just hitting a few snags)

[cypherdoc]

your willingness to explain simple questions to us non coder/mathematicians is why i am willing to help you financially.

i'll also say that the ease and speed with which you solve bugs and incorporate features many here have asked for is also a huge plus for Armory.

[fornit]

your willingness to explain simple questions to us non coder/mathematicians is why i am willing to help you financially.

in my opinion thats not just a good character trait. its a feature in armory. with its extensive explanations and tooltips armory has about 6700 words in distinctive strings. the satoshi client doesnt even have a quarter of that.
etotheipi may consider offline transactions the most important innovative feature of armory. i think helping users to understand what they are doing is just as important.

[cypherdoc]

your willingness to explain simple questions to us non coder/mathematicians is why i am willing to help you financially.

in my opinion thats not just a good character trait. its a feature in armory. with its extensive explanations and tooltips armory has about 6700 words in distinctive strings. the satoshi client doesnt even have a quarter of that.
etotheipi may consider offline transactions the most important innovative feature of armory. i think helping users to understand what they are doing is just as important.

very true.

[etotheipi]

So, going back to one of my earlier questions ... is the 'send from'
feature (like the coderr patch in this thread : https://bitcointalk.org/index.php?topic=24784.0)
anywhere on your list ? Is it hard to pull-off at the code level ?

I'd donate generously to see that happen ...

znort987,

I spent some time putting together a script that will work with all versions of armoryengine.py:  It works takes in a wallet object, a list of input addresses in that wallet, a list (recipient,value) pairs, the fee you are willing to pay, and then a change address (which can be none, and the wallet will generate a new address to use for change).   It will even prompt you for your password if the wallet is encrypted.  It is heavily commented for educational purposes, and has lots of print statements so it looks about 3x the length it actually is!   But you can reuse this code everywhere, so really it was just a matter of me spending the time to create a good example script for others...

-- First 100 lines is the actual, reusable function:  takes inputs, loads blockchain, does calculations and error checking, prompts you if there's not enough fee, and prints out a shitload of information about your wallet and then returns the unsigned transaction it is creating.

-- After that is the "main" function which actually uses it.  It loads the wallet and creates inputs/outputs, executes the above function, then signs it with the wallet.  It then displays the signed transaction both in raw hex (which can be copied directly into http://bitsend.rowit.co.uk/) and the BIP 0010 format which can be copied into Armory "offline transactions" as if it was generated on an offline computer.  

-- Alternatively, I could add a method to send it right there, but Armory networking relies on an event loop to be running, and for such a small script, I figured there was enough there already to keep you entertained for a while

Here's the code -- createTxFromAddrList.py:

Code:

from armoryengine import *
from getpass import getpass


def createTxFromAddrList(walletObj, addrList, recipAmtPairList, \
                                          fee=0, changeAddr=None):
   """ 
   Create an unsigned transaction.  This method expects a wallet,
   a list of addresses in that wallet, and then a list of recipients and
   amounts to send each one.  

   !!! YOU MUST SPECIFY ALL BITCOIN VALUES IN SATOSHIS !!!
   You can either write it out explicitly -- 150000000
   Or use floats and convert to long      -- long(1.5*ONE_BTC)

   You must also specify an address to which you want change sent.  It will 
   only be used if necessary (i.e. if you don't specify your recip list to 
   exactly match inputs minus fees)
   
   If no change address is specified, the next unused address will be 
   retrieved from the walletObj
   """
   
   if not TheBDM.isInitialized():
      # Only executed on the first call if blockchain not loaded yet.
      print '\nLoading blockchain...'
      BDM_LoadBlockchainFile()  # can add optional arg for blk0001.dat location


   # Check that all addresses are actually in the specified wallet
   for addr in addrList:
      addr160 = addrStr_to_hash160(addr)
      if not walletObj.hasAddr(addr160):
         raise WalletAddressError, 'Address is not in wallet! [%s]' % addr
   

   print '\nUpdating wallet from blockchain'
   walletObj.setBlockchainSyncFlag(BLOCKCHAIN_READONLY)
   walletObj.syncWithBlockchain()
   print 'Total Wallet Balance:',coin2str(walletObj.getBalance('Spendable'))
   

   print '\nCollecting Unspent TXOut List...'
   # getAddrTxOutList() returns a C++ vector<UnspentTxOut> object, which must 
   # be converted to a python object using the [:] notation:  it's a weird 
   # consequence of mixing C++ code with python via SWIG...
   utxoList = []
   for addr in addrList:
      addr160 = addrStr_to_hash160(addr)
      unspentTxOuts = walletObj.getAddrTxOutList(addr160, 'Spendable')
      utxoList.extend(unspentTxOuts[:])
   
   # Display what we found
   totalUtxo = sumTxOutList(utxoList)
   totalSpend   = sum([pair[1] for pair in recipList])
   print 'Available:  %d unspent outputs from %d addresses: %s BTC' % \
                  (len(utxoList), len(addrList), coin2str(totalUtxo, ndec=2))

   # Print more detailed information
   pprintUnspentTxOutList(utxoList, 'Available outputs: ')


   #############################################################################
   # IF YOU WANT TO CHANGE THE PRIORITIZATION OF HOW COINS ARE SELECTED:
   #        It's not dynamically customizable, yet.  But you can
   #        go into armoryengine.py and look for the WEIGHTS list
   #        around line 4550.  Change the values to change the 
   #        optimization.  
   #############################################################################

   # PySelectCoins() assumes that the remaining will be sent to a change addr
   print 'Selecting coins based on unspent outputs, recipients, fee...'
   selectedUtxoList = PySelectCoins(utxoList, totalSpend, fee)

   print 'Checking that minimum required fee is satisfied for this tx...'
   minValidFee = calcMinSuggestedFees(selectedUtxoList, totalSpend, fee)[1]

   if minValidFee>fee:
      print '***WARNING:'
      print 'This transaction requires a fee of at least %s BTC' % coin2str(minValidFee)
      print 'Sending of this transaction *will fail*.  Will you increase the fee?'
      confirm = raw_input('Increase Fee [Y/n]:')
      if 'n' in confirm.lower():
         print 'ABORTING'
         return None
      fee = minValidFee
      selectedUtxoList = PySelectCoins(utxoList, totalSpend, fee)

   # Convert address strings to Hash160 values (and make a copy, too)
   recip160List = [(addrStr_to_hash160(pair[0]), pair[1]) for pair in recipList]

   # Add a change output if necessary
   totalSelect = sumTxOutList(selectedUtxoList) 
   totalChange = totalSelect - (totalSpend + fee)
   if totalChange < 0:
      print '***ERROR: you are trying to spend more than your balance!'
      return None
   elif totalChange!=0:
      # Need to add a change output, get from wallet if necessary
      if not changeAddr:
         changeAddr = walletObj.getNextUnusedAddress().getAddrStr()
      recip160List.append( (addrStr_to_hash160(changeAddr), totalChange) )

   print 'Creating Distribution Proposal (just an unsigned transaction)...'
   print [(hash160_to_addrStr(r),coin2str(v)) for r,v in recip160List]

   txdp = PyTxDistProposal().createFromTxOutSelection(selectedUtxoList, recip160List)

   return txdp
   
   
   
################################################################################
if __name__ == '__main__':

   walletFile = 'armory_29KADwa1D_.wallet'
   if not os.path.exists(walletFile):
      raise FileExistsError, 'Wallet file does not exist! [%s]' % walletFile
   wlt = PyBtcWallet().readWalletFile(walletFile)

   # List of addresses in wallet, which you are willing to use for this tx
   addrList = ['1dyRSCSJdRiPgGYNTSE31Lodvs3Peiiqx', \
               '131t9NSPV3U1DdyQsEEcEzyyYsWrAcm1ZX']
   
   # Send money to these three outputs (change will be added if/where necessary)
   recipList =[('12V6i8PHhxyYWSEeYsXNr9kzwca1GrW5T8',  long(0.2*ONE_BTC)), \
               ('14CDNme1pFJxLKitdSMqTNETPeLzs1V4RD',  long(0.5*ONE_BTC)), \
               ('16GsZYhzJiv5BHTQaosrwpSpf9Unw3eLuC',  long(1.1*ONE_BTC))   ]
   
   # Works with or without a change address specified
   #sendChangeTo = '151kQbcEdBDehW5gt3fahrHwfBBtEjSSAx'
   sendChangeTo = None
   
   # Remember, must specify amounts in SATOSHIs
   print 'Creating Unsigned Transaction...'
   txdp = createTxFromAddrList(wlt, addrList, recipList, 50000, sendChangeTo)
   txdp.pprint()
   
   print 'Transaction created, now sign it...'
   if wlt.useEncryption and wlt.isLocked:
      passphrase = SecureBinaryData(getpass('Passphrase to unlock wallet: '))
      wlt.unlock(securePassphrase=passphrase)
      passphrase.destroy()


   print 'Signing transaction with wallet...'
   wlt.signTxDistProposal(txdp)
   
   print 'Transaction is fully signed?', 
   print txdp.checkTxHasEnoughSignatures(alsoVerify=True)
   
   print 'Preparing final transaction...'
   pytx = txdp.prepareFinalTx()

   print '\nRaw transaction (pretty):'
   pprintHex(binary_to_hex(pytx.serialize()))
   
   print '\nRaw transaction (raw hex, copy into http://bitsend.rowit.co.uk):'
   print binary_to_hex(pytx.serialize())
   
   print '\nSigned transaction to be broadcast using Armory "offline transactions"...'
   print txdp.serializeAscii()

[runeks]

Yay! Just made my first offline transaction. It works perfectly, though Armory popped up with a message on my online computer saying the transaction didn't get broadcast and that I can find information about the transaction in failedtx.bin. But the Satoshi client received the transaction fine and it's been picked up in a block: http://blockexplorer.com/tx/a090caf70a778ee7393e33c1283311b332ec92271fbe719a3a2030d82dbbc1fe#o0

This appeared on the command line:

Code:

Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 3598, in createTxDPAndDisplay
    dlg = DlgConfirmSend(self.wlt, self.origRVPairs, self.txValues[1], self, self.main, False)
IndexError: list index out of range
Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 3598, in createTxDPAndDisplay
    dlg = DlgConfirmSend(self.wlt, self.origRVPairs, self.txValues[1], self, self.main, False)
IndexError: list index out of range
Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 3598, in createTxDPAndDisplay
    dlg = DlgConfirmSend(self.wlt, self.origRVPairs, self.txValues[1], self, self.main, False)
IndexError: list index out of range
Coin Selection:  (Total =         0.50000000 BTC)
    Owner Address                                  TxOutValue      NumConf       PriorityFactor
    1CcBVdAtFzbXSjjWsyeGyjXmip3Jjot3s5             0.50000000 BTC            4                 0.01
50000000
49950000
   Distribution Proposal :  4pTAVT7g
   Transaction Version   :  1
   Transaction Lock Time :  0
   Num Inputs            :  1
      Value: 50000000
      SrcScript:   76a9147f50b3aadc7c7df11e7afb4cbb4cbabbe4d8bac688ac
      Sig0 = ""
   Num Outputs           :  1
   Recipient:         0.49950000 BTC 1KpSwovbYxcdDHCqgyaRV2SYW9uLTbm21z
f9beb4d9
Added new blocks to memory pool: 1
New Block! : 171677
f9beb4d9
Added new blocks to memory pool: 1
New Block! : 171678
Signature 0 is valid!
Signature 0 is valid!
Signature 0 is valid!
Signature 0 is valid!
Pretty tx:  Transaction:
   TxHash:    a090caf70a778ee7393e33c1283311b332ec92271fbe719a3a2030d82dbbc1fe (BE)
   Version:   1
   nInputs:   1
   nOutputs:  1
   LockTime:  0
   Inputs: 
      PyTxIn:
         PrevTxHash: 039004796f230e6112bd4bf15127a0cc557ec4909393590c9600fa16d22ed4df (BE)
         TxOutIndex: 1
         Script:     (4930460221009e9898165e2ea654986cd9231ab2b083fc2acf30352220a08831)
         Sender:     1CcBVdAtFzbXSjjWsyeGyjXmip3Jjot3s5
         Seq:        4294967295
   Outputs: 
      TxOut:
         Value:    49950000 ( 0.4995 )
         Script:   OP_DUP OP_HASH (1KpSwovbYxcdDHCqgyaRV2SYW9uLTbm21z) OP_EQUAL OP_CHECKSIG
None
Raw serialize tx:  0100000001dfd42ed216fa00960c59939390c47e55cca02751f14bbd12610e236f79049003010000008c4930460221009e9898165e2ea654986cd9231ab2b083fc2acf30352220a08831a19447f69c320221004a00a5b7d3eb15a30bb2ae65faf86b73dcdb20dbc1cc1352fe05aa58d63f81b6014104d283456638942d43ad27c5049a3bfa7cee66f2d16f06d53ffc64a40d3f1eff10fd72370f78935b8cf455bdcf07b20d1b38ae3db403b0d0e1e19efd1cb73b6486ffffffff01302dfa02000000001976a914ce6b78db1f2fab5a2e93f55a6cb30296e5cad13488ac00000000
Sending Tx, a090caf70a778ee7393e33c1283311b332ec92271fbe719a3a2030d82dbbc1fe
Done!

EDIT: Here's failedtx.bin: http://minus.com/mJsFxZDo1#

[etotheipi]

And, this is me putting my money where my mouth is: a7218dd222b7565ac00c93208b5ce9e7c1b9e1894ec31f5bc62d92e35d96c352

Thank you for this awesome, awesome work.

Edit: one minor request ... it would be great if you could add this to the git tree

znort987,

Thanks so much!  Drop me an email so I can at least send you the encryption seminar, and I will send you other rewards as appropriate, if you want!   I actually already added the file to the git tree under the "migratewallet" branch.  It was because I just happened to be on that branch and it will be merged into master soon (as soon as I get some feedback from others about the wallet-migration!).    How did you get that donation address, btw?  It used to be in my signature, but then I changed it for Armory funding and didn't think anyone still had it!  (I was going to put it back after crowdfunding was over).

Yay! Just made my first offline transaction. It works perfectly, though Armory popped up with a message on my online computer saying the transaction didn't get broadcast and that I can find information about the transaction in failedtx.bin. But the Satoshi client received the transaction fine and it's been picked up in a block: http://blockexplorer.com/tx/a090caf70a778ee7393e33c1283311b332ec92271fbe719a3a2030d82dbbc1fe#o0

It sounds like you're using version 0.55.  I had accidentally switched the endianness of a variable somewhere that prevented Armory from detecting that the tx was accepted, even though it already hit the network.  Please upgrade to 0.60...and try the wallet migration   (though 0.56 fixes that error, too).  Glad to finally get some more feedback about offline transactions working!  Please let me know if there's anything I can do to improve it!