Topic: Armory - Discussion Thread - page 229. (Read 521693 times)

The blockchain-wallet scanning should be O(log(n)) in the number of addresses in your wallet.  If you have the RAM to try it, I'd be interested to see how long it takes to do the scan and collect the balances, but I would guess it's less than 5s.  As for the wallet format:  there are no arbitrary limits on how big the wallets can be.  I have had 500 addresses in one of my wallets before, without problem -- there are no artificial limits.  Perhaps you will be able to help me find the breaking point for wallet sizes.  

I'm having a problem with PyQt and py2exe in Windows.  I have a MSVC++ runtime error when trying to install the pywin32 module, which linked but not actually needed by my software.  So I can comment out the imports and the software runs fine, but py2exe complains that it needs it in order to make the executables.  it's going to take a little bit more work (and maybe switching systems), before I get an executable made.   I spontaneously got an exe built once (so I know it works), but for some reason I couldn't repeat it...

For now, I still have some dev left before officially making exe's... maybe I shouldn't have posted so soon  (remember, releasing next week)    But I'll put up build instructions tonight or tomorrow, and plan to have a Windows exe built by next week.  For now, I still have some pretty important bugs to quash before I would trust this software with anything but testnet coins...

This is EXACTLY what I needed to be able to move forward with one of my projects.

Two questions:
1)  How well does it handle wallets with many thousands of generated addresses?  Say, 50-100k addresses in a single wallet file?
2)  When do we get a Windows exe?

Oh god! This is beautiful!

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.

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!

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

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)..

Looking very good!

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.

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.

"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)

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).

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.

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.

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

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

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.


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...


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.

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.

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

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

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

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

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

Can someone explain "Import/Sweep Addresses" please?