Armory - Discussion Thread

[Nachtwind]

Pretty awesome... looking forward testing it..

One thing "Multi wallet" does that also include "multi blockchain"? What i alook for is a single client to hold my BTC, LTC and so on wallets...

[bitcoinbetas]

totally sick 

[Stemby]

 

Chapeau

[Tuxavant]

Super awesome! Look forward to seeing a donation address..

Can someone explain "Import/Sweep Addresses" please?

[BinaryMage]

Incredible! Much thanks for your hard work. I look forward to trying it out.

[Matoking]

Super awesome! Look forward to seeing a donation address..

Can someone explain "Import/Sweep Addresses" please?

Sweeping takes all the bitcoins from the supplied private key and the address and sends them into your wallet, without adding a new address into the wallet.

Importing imports the private key into the wallet, adding a new Bitcoin address, with all funds already associated with it.

Also, there is a donation address in the Github repository's README file:
https://github.com/etotheipi/BitcoinArmory/blob/master/README

[jim618]

Congratulations on your bitcoin client.
That is a lot of lot of work !

[minorman]

Sweet. I wanna try the beta!
- and donate from it when it works!

[etotheipi]

Thanks for all the compliments.  I've been looking forward to this moment for a while    So much that I can't believe I botched the donation address I usually keep in my signature!  (I tried changing it and forgot to restore the address).

Feel free to donate now:  1Gffm7LKXcNFPrtxy6yF4JBoe5rVka4sn1, but I'm definitely more interested in having you donate from the software itself.  If it works well enough to donate, then we're both happy!

I still need to work out some lingering bugs and interface issues.  I have tested the hell out of most of the stuff under-the-hood, and it just needs to be prettied up on the user-interface side.  Once I finish implementing and testing the offline-wallet interface, I'll try to post instructions for those that want to run it themselves.  I plan to make binaries in Windows (though I am struggling with py2exe issues right now), and Ubuntu should only be a few command-line calls (I have a bare VM setup to test that this is true).  Of course, these things never work out as smoothly as I hoped, and I know it's going to be a pain to support multiple OS's... but I suppose that's part of the fun!

If you're interested in helping me test right now... well, I'll make a post tonight or tomorrow with initial build instructions.  Once I have the offline interface working, I'll try to make binaries and post them on my (future) webpage.

As you all have noted, this is a heavy program.  I understand not everyone will be able to use it.  But those than can... well I think you will enjoy it  I plan to spend half of my immediate development activities (after alpha) on creating a file-based blockchain, but it might be a while before I can get it implemented and tested.  But no doubt:  I will be keeping the full-RAM implementation in there, it will be modified to scan the blockchain in batches (so no huge RAM reqt) and also could be easily ported to some kind of server as people have suggested.   I would love to see the full-RAM implementation used in a server:  with nothing but a blk0001.dat file, I can scan the entire blockchain and collect the balance/unspent-outputs of an address/wallet in less than 1s.  From a cold boot, it's probably 15-20s with all the file ops and blockchain organization ops.

[etotheipi]

Very cool.
Finally my 16GB will be of use .
What about bulk generation of addresses?

I'm not sure what you mean by "bulk generation."  The deterministic wallet feature will generate an infinite number of addresses, but it is kind of slow, because each step in the sequence requires ECC operations to be performed on the CPU.  I believe it will extend the sequence at about 100 addr/sec.

awesome  
can you add a option to download the blocks but dont check them and only check the blocks from the last week/month/user defined time

Right now, there is no blockchain downloading-- it leaches completely off the Satoshi client and its blockchain file.  

On that note:  I should've mentioned that this client does no blockchain validation.  The assumption is made, that if the data made it into the longest blockchain, it is valid.  I let miners do the work so I don't have to.  However, for zero-confirmation transactions, I might add a check to make sure that the previous output is at least in the blockchain.  But, of course, no one should really ever be trusting zero-conf transactions...

Pretty awesome... looking forward testing it..

One thing "Multi wallet" does that also include "multi blockchain"? What i alook for is a single client to hold my BTC, LTC and so on wallets...

Unfortunately, I do not have multi-network support.  The network has to be specified at runtime, and then everything after that is hard-coded.  However, I was surprised to see how painless it was to switch between main-network and testnet, so you could probably add your own network parameters (genesis hash, magic bytes, network port), and run a separate instance of Armory.  I'm not sure it would be any more resource intensive than if I had them all integrated into the same interface... but I recognize it's not as convenient to run multiple instances.  Unfortunately, this feature is not on my radar in terms of near-term improvements.

[finway]

So i guess i need to compile .cpp file with SWIG,right?
but how?

Code:

C:\Documents and Settings\admin\BitcoinArmory>python bitcoinarmoryqt.py
********************************************************************************

Loading BitcoinArmory Engine:
   BitcoinArmory Version: 0.50
   PyBtcAddress  Version: 1.00
   PyBtcWallet   Version: 1.00
Detected Operating system: Windows
   User home-directory   : C:\Documents and Settings\admin\Application Data
   Satoshi BTC directory : C:\Documents and Settings\admin\Application Data\Bitc
oin\
   Satoshi blk0001.dat   : C:\Documents and Settings\admin\Application Data\Bitc
oin\blk0001.dat
   BitcoinArmory home dir: C:\Documents and Settings\admin\Application Data\Bitc
oinArmory\
***ERROR:  C++ block utilities not available.
           Make sure that you have the SWIG-compiled modules
           in the current directory (or added to the PATH)
           Specifically, you need:
                  CppBlockUtils.py     and
                  _CppBlockUtils.pyd
Traceback (most recent call last):
  File "bitcoinarmoryqt.py", line 33, in <module>
    from btcarmoryengine import *
  File "C:\Documents and Settings\admin\BitcoinArmory\btcarmoryengine.py", line
285, in <module>
    TheBDM = Cpp.BlockDataManager().getBDM()
NameError: name 'Cpp' is not defined

[Meni Rosenfeld]

Very cool.
Finally my 16GB will be of use .
What about bulk generation of addresses?

I'm not sure what you mean by "bulk generation."  The deterministic wallet feature will generate an infinite number of addresses, but it is kind of slow, because each step in the sequence requires ECC operations to be performed on the CPU.  I believe it will extend the sequence at about 100 addr/sec.

It means I can choose a label (say "My Bitcoin address"), hit the "generate 1000 addresses" button, and obtain a list of 1000 addresses I can use, labeled "My Bitcoin address 1" through "My Bitcoin address 1000", which I can easily copy in order to paste elsewhere. MultiBit does something like this as far as I understand.

On that note:  I should've mentioned that this client does no blockchain validation.  The assumption is made, that if the data made it into the longest blockchain, it is valid.  I let miners do the work so I don't have to.

This may fly for blocks buried deep enough in the chain. But for recent blocks you need to check they are actually valid before propagating them further. Otherwise you get into a situation that nobody does any checking because he trusts that everyone else will do the checking and only feed him clean data.

But, of course, no one should really ever be trusting zero-conf transactions...

I disagree, there are certainly situations where 0-confirm transactions are to be trusted (notable example is paying for a latte).

[etotheipi]

On that note:  I should've mentioned that this client does no blockchain validation.  The assumption is made, that if the data made it into the longest blockchain, it is valid.  I let miners do the work so I don't have to.

This may fly for blocks buried deep enough in the chain. But for recent blocks you need to check they are actually valid before propagating them further. Otherwise you get into a situation that nobody does any checking because he trusts that everyone else will do the checking and only feed him clean data.

But, of course, no one should really ever be trusting zero-conf transactions...

I disagree, there are certainly situations where 0-confirm transactions are to be trusted (notable example is paying for a latte).

"Deep enough" is the standard 6 blocks.  If the rest of the world is building off a blockchain with your transaction 6 blocks deep I'm happy to accept it.  If you flood my node with 100% dishonest connections and start sending me poisoned blocks... well there's nothing the Satoshi client with full node-validation can really do with that, either.  As long as you have 1 honest node out of 100 connections, you will get the longest chain.

As for 0-conf transactions, you are allowed to trust them as much as you want, but I won't encourage it.  All you need is 1 dishonest node out of 100 connections to start sending you invalid transactions.  They can even send you transactions that would appear valid, but since my node doesn't check&forward them,  I don't know that they weren't sent to any miners and won't actually be included in the blockchain.  The only way to avoid this is with full-validation, but that's not something that any lite-client will be doing.

However, since Armory connects through the Satoshi client, all data is filtered through it's full-validation behaviors.  So you can trust the 0-confirmation transactions a bit more than you could on a real, light node, but I still wouldn't trust it too much.  I mostly use it for confirmation that an expected payment entered the system, but there's too many things that can go wrong with 0-confs.  Even 1-confirmation transactions have holes that could be exploited by determined (there's some posts on 1-conf exploits I participated in a while ago... I can dig them up if you are super-interested).  

In terms of risk in accepting transactions, as a function of the number of confirmations, I would apply the following ranking (normalized by zero-confimation risk)

Code:

0:  100%
1:   30%
2:    3%
3:    2%
4:    1%
5:    1%
6:    1%

That's not just exponential decay... there's just extraordinarily fewer options for an attacker once the tx is 2 blocks deep.  That's also why I change the text color from light gray to not-so-light-gray after 2 confirmations  (but you can't hold me responsible for things going wrong if you don't wait for 6)


Finway: Check out the Using_Armory.README file for more information about how to compile -- or wait for me to post specific/updated instructions.  There might be more hints in the PBE block-explorer demo thread  (but you need to add a few things, like python-twisted, etc).

[maaku]

This may fly for blocks buried deep enough in the chain. But for recent blocks you need to check they are actually valid before propagating them further. Otherwise you get into a situation that nobody does any checking because he trusts that everyone else will do the checking and only feed him clean data.

That's what the Satoshi client does, which this client interfaces with. All he's doing is trusting that the Satoshi client is doing its job.

[Meni Rosenfeld]

This may fly for blocks buried deep enough in the chain. But for recent blocks you need to check they are actually valid before propagating them further. Otherwise you get into a situation that nobody does any checking because he trusts that everyone else will do the checking and only feed him clean data.

That's what the Satoshi client does, which this client interfaces with. All he's doing is trusting that the Satoshi client is doing its job.

Sure, but isn't the plan to make it standalone at some point? If the "no validation" is only supposed to remain while it uses the Satoshi client then it's not a problem.

[kwukduck]

Looking very good!

[etotheipi]

Sure, but isn't the plan to make it standalone at some point? If the "no validation" is only supposed to remain while it uses the Satoshi client then it's not a problem.

You are right:  once I sever the umbilical cord to the Satoshi client, it will not do block-validation.  However, I don't see this as a problem.  The entire future of Bitcoin will revolve around lite-clients which don't have block-validation, and I don't have a problem having my program be one of them.  However, it's not out of the question to do some kind of validation on zero-conf transactions, but it's not my first priority.  As I said before:  it's up to you to pick your own "comfort level" with 0 and 1-conf transactions, but if you wait for 6 like is globally suggested on the network, all types of nodes should have equal confidence.

The only thing to take away from this is that once Armory has standalone networking, those zero-conf transactions should be treated even more cautiously than on a full node.  I'm more focused on having rock-solid wallet management, instead of real-time operational details like this (it's just a matter of priorities)..

[Greed]

Excellent work, if I do so say so myself. Is it possible to run it without a GUI via the terminal / command line?

[etotheipi]

Excellent work, if I do so say so myself. Is it possible to run it without a GUI via the terminal / command line?

You can get to 90% of the functionality of Armory via a python shell (loading the blockchain, creating wallets, importing keys, getting blockchain data, scanning addresses, getting unspent-output lists, crypto ops, etc)., but you have to know what calls to use.  You can get some hints from unittest.py, which contains most of the unit-tests for the project.
 
However, while the low-level code is well-commented, I haven't really done any high-level documentation of how to do high-level stuff -- for now you'll have to settle for looking at unittest.py until I get around to making a walk-thru of the high-level interface.  If you want pure-python without any external dependencies, go look at PyBtcEngine which should work without any of the C++/SWIG stuff (it's my own project I forked Armory from a couple months ago, when I had to take the leap from pure-python to hybrid).

From there you can make all kinds of scripts, or setup a simple socket/IO interface to pipe commands to and from a running server.  There's a lot of possibilities... and for now I'll work on build-instructions and try to post them tonight so that all these committed people have a chance to get up and running tonight   I guess pre-alpha is the new alpha!

[O_Shovah]

Thanks you a lot for all your efforts.All your projects apear astounding to me.

I have never worked with python before only C++. But ill make shure to give it a try making this code run on windows.

The Xeon quad core and 64GB of ram shall be doing their job

I send you a Donation. Such dedication has to be rewarded.(At least i may help to keep your girlfriend patient;) )

Keep up the work. Is already a great project and for shure will flourish further.