OK! I have it running on a TrueCrypt container on a removable drive! So... what command line parameter specifies the location of the config file? My goal is to make a portable version with the command line parameters fully defined. Of course I want to read any docs explaining the parameters.
See the bottom of the "troubleshooting" page: http://bitcoinarmory.com/download/troubleshooting/Not sure how it ended up there. It might've gotten reshuffled with the new website. |
|
|
|
By the way: in case you didn't subscribe to the other thread: I finished the last major feature/bug. Armory now properly saves all its data between loads. On my system, managing Bitcoin-Qt/bitcoind myself, I can close and reopen Armory in 19 seconds! and 260 MB of RAM. There still a lot of missing optimizations, but this is no doubt the most usable version yet. Please try it out! https://bitcointalk.org/index.php?topic=299684.0
|
|
|
|
My bad. Sorry for the scavenger hunt! Put in LOGERROR calls, which will guarantee it gets written out to the log file: LOGERROR('***BLKDIR VARIABLE:')
LOGERROR('***Type: %s' % str(type(blkdir)))
LOGERROR('***Size: %d' % len(blkdir))
LOGERROR('***Value: %s' % str(blkdir))Breaking them out like that will also make sure the type() is printed even if len() or str() throws an error. It didn't crash until bitcoind had downloaded the blockchain. (INFO) ArmoryQt.py:1346 - Setting netmode: 1
(INFO) armoryengine.py:12324 - Setting online mode: True (wait=False)
(INFO) armoryengine.py:13249 - Go online requested
(INFO) armoryengine.py:12766 - Called __startLoadBlockchain()
(ERROR) armoryengine.py:12808 - ***BLKDIR VARIABLE:
(ERROR) armoryengine.py:12809 - ***Type: <type 'unicode'>
(INFO) armoryengine.py:10353 - Connection initiated. Start handshake
(ERROR) armoryengine.py:12810 - ***Size: 22
(ERROR) armoryengine.py:12811 - ***Value: F:\bitcoin_data\blocks
(ERROR) armoryengine.py:13274 - Error processing BDM input
(ERROR) armoryengine.py:13275 - Received inputTuple: GoOnlineRequested [13, 40873630, False]
(ERROR) armoryengine.py:13276 - Error processing ID (40873630)
(ERROR) armoryengine.py:13277 - ERROR:
Traceback (most recent call last):
File "G:\armory_testing\ArmoryStandalone_0.89.99.2_win_all\ArmoryStandalone\library.zip\armoryengine.py", line 13260, in run
File "G:\armory_testing\ArmoryStandalone_0.89.99.2_win_all\ArmoryStandalone\library.zip\armoryengine.py", line 12812, in __startLoadBlockchain
File "CppBlockUtils.pyc", line 1230, in SetBlkFileLocation
TypeError: in method 'BlockDataManager_LevelDB_SetBlkFileLocation', argument 2 of type 'string'
So, it looks like the string is of the wrong type. None of the characters are non-ASCII, so it shouldn't be that hard to convert. In fact, there was no error when it printed the value of "str(blkdir)" which means it was safely cast to a string. I don't know why you ended up with a unicode value, but I do know that the simply putting in that cast is not a good general solution. Though it should work for you right now... For now just cast the "unicode" object to a string. I'll put that in the next version, since it is strictly an improvement over the current code (which will fail unless it's a string, anyway). But I need to put more effort into the unicode handling there... probably one of need to call "toPreferred()" to get it to work with arbitrary path vars. |
|
|
|
I'm trying to set up the new Armory and Bitcoin-QT to run completely off a flash drive. Oh!! BTW thanks for the new Armory! I actually can run it now!  So what is the difference between the --datadir and --satoshi-datadir command line calls? --datadir is the Armory home directory to use --satoshi-datadir is the [/i]Bitcoin-Qt/bitcoind[/i] home directory to use (which should match the "-datadir" flag you give to Bitcoin software if run it manually) Thank you sir! I will report back to you soon on the totally flash drive test. BTW The flash drive is a TrueCrypt container. What kind of flash drive are you using? The Bitcoin and Armory directories together will probably consume 30 GB of disk space, and of course will grow with the blockchain. Just a reminder. |
|
|
|
I'm trying to set up the new Armory and Bitcoin-QT to run completely off a flash drive. Oh!! BTW thanks for the new Armory! I actually can run it now! So what is the difference between the --datadir and --satoshi-datadir command line calls? --datadir is the Armory home directory to use --satoshi-datadir is the Bitcoin-Qt/bitcoind home directory to use (which should match the "-datadir" flag you give to Bitcoin software if run it manually) |
|
|
|
I appreciate the RAM reduction effort happiness (numbers look GREAT!), but the message signing thing is really bugging me ATM. The unencrypt/re-encrypt didn't work with BTC-qt 8.3 or 8.5, so I had to export my addresses to blockchain, which I would really like to avoid. Anything else that can be done?
A bounty was claimed with a new message signing algorithm to be integrated into Armory. It includes code to be backwards compatible with Bitcoin-Qt. But this current upgrade (RAM-reduction) was so significant, that I couldn't fit everything into it. I have enough to worry about. Once I officially release it it, I'll start tending to the other important-but-less-critical upgrades like unicode issues, message signing, tx size limits, etc. |
|
|
|
If I want to try it out on OS X I have to compile it myself. I assume it is in a branch in git ?
It's the "testing" branch. There is Level DB source code in the project, though, no clue if it compiles on OSX... |
|
|
|
As you all have probably heard by now, Armory just got a huge injection of funds. Obviously, we didn't get the money to just "give it away", but I see that what Mark is doing is a huge benefit to Bitcoin, even if it ultimately doesn't work. And if it does work, Armory would use it pretty much immediately. As such, I think it make sense for Armory to commit some funding to this project. I really want to see this idea explored, for the benefit of Bitcoin (not just because I originally came up with it  ). Armory Technologies, Inc. is pledging 50 BTC for this. The only catch is that we don't actually have 50 BTC available right now (only USD), but we should have it available some time next week and I will send it then. Please email/PM me to pester me about it in a week if you don't see it. Looking forward to seeing what you can do with another few months! |
|
|
|
|
Fixed rescan-on-every-load bug!
Version 0.89.99.3-testing (link is in the top post)
It turns out that it wasn't waiting for the block data manager to finish writing the wallet histories to the database before killing it. The time between calling and killing was enough to write out a couple hundred addresses -- if you had more than that, it wouldn't finish in time, and Armory would detect a bunch of new addresses every load requiring a rescan.
Therefore, all features I wanted to be in this release are implemented now. I've pretty much decided to freeze the feature set, and just focus on bugs and polishing.
One other bug that I noticed: there's a pretty long freeze on every new block. Again, it's one of those efficiencies/optimizations that can be improved later. The "usability" impact of that bug is a lot less than requiring 6 GB of RAM!
|
|
|
|
print '***blkdir var:', type(blkdir), len(blkdir), '"'+str(blkdir)+'"' It doesn't seem that print dumps the text into the log file and windows doesn't show the standard output stream (even if started from command line). My bad. Sorry for the scavenger hunt! Put in LOGERROR calls, which will guarantee it gets written out to the log file: LOGERROR('***BLKDIR VARIABLE:')
LOGERROR('***Type: %s' % str(type(blkdir)))
LOGERROR('***Size: %d' % len(blkdir))
LOGERROR('***Value: %s' % str(blkdir))Breaking them out like that will also make sure the type() is printed even if len() or str() throws an error. |
|
|
|
Let's do this! https://bitcointalk.org/index.php?topic=299684.0Please don't use it with large amounts of money yet. It's probably still chock full of bugs, but I've done quite a bit of internal testing and feel pretty good about the major features. Besides fixing the rescan-on-every-load issue, the feature set is frozen. I'd like to fix what's in it, rather than add anything new. A whole bunch of less-critical things (unicode fixes, message signing, tx size limits), will go into the next version (and that next version will not take 3 months to release ). Please discuss bugs & general observations in that other thread, to not clutter this one!Can we run with a remote Bitcoin instance with this version, or maybe next version? I have a server which runs a persistent node and it would be great to only have one copy of the block chain (Armory's) on my main desktop. Not yet. That will be 100x easier to implement now, but I wanted to minimize the interface changes on this update, since there was enough turbulence with the new database engine. So it still uses the local blk*.dat files like the 0.88.1 did (though it doesn't crash on blk*.dat file splits anymore!). But now that it won't start any operations until Bitcoin-Qt/bitcoind is sync'd, and it's maintaining it's own blockchain database, it should be straightforward to upgrade it. Especially, because I was careful to make sure that the operations did not depend on the contents/structure of the blk*.dat files in anyway -- it reads them once, and then 100% of ops after that is based on its own DB. It should even handle switching to a different set of blk*.dat files between loads, as it redetects the blocks every load (part of the headers-first implementation). Also, I'm slightly concerned about any anti-DoS measures built into Bitcoin-Qt/bitcoind which might cause unexpected issues for the user. For instance, if I restart a few times, and constantly disconnect, reconnect, and download tons of data, over and over, it might just blacklist the Armory instance. I don't expect that to happen, but I always expect something silly to crop up and eat another week of my life |
|
|
|
I'm still quite curious how that error is cropping up. If you are ambitious, you can close Armory, unpack the library.zip file inside that directory, then modify armoryengine.py. When you are done, re-zip it and overwrite library.zip. Then it should use the new code when you run ArmoryQt.exe. This works for everything except ArmoryQt.py which is the entry point for the app, so it treats that file differently. But all the other python files should be modifiable in that way mentioned. They are all .pyc files rather than .py files. I assume there is some kind of compile step. Do I need to set a home directory too? Ack, forgot about the .pyc thing. I forgot that py2exe puts the already-byte-compiled python code in there. However, it doesn't require .pyc files. Simply copy in the pre-compiled armoryengine.py and delete the .pyc. Make the modification to the .py file, and my previous instructions should work (sorry, it's been a while since I've done this). If you want to spend any significant amount of time modifying code, etc, and you are a patient person, we just gave all the MSVS projects a complete overhaul and should be much easier to get working, now (and uses the free version of MSVS 2012). Still not trivial, but if you have any interest in spending a lot of time in Armory source code (C++ or python), it would be worth the effort. |
|
|
|
Ahh ok. I am still getting this error: (ERROR) ArmoryQt.py:646 - 8 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:651 - File mempool.bin does not exist. Nothing deleted.
(ERROR) armoryengine.pyc:13270 - Error processing BDM input
(ERROR) armoryengine.pyc:13271 - Received inputTuple: GoOnlineRequested [13, 87485194, False]
(ERROR) armoryengine.pyc:13272 - Error processing ID (87485194)
(ERROR) armoryengine.pyc:13273 - ERROR:
Traceback (most recent call last):
File "armoryengine.pyc", line 13256, in run
File "armoryengine.pyc", line 12808, in __startLoadBlockchain
File "CppBlockUtils.pyc", line 1230, in SetBlkFileLocation
TypeError: in method 'BlockDataManager_LevelDB_SetBlkFileLocation', argument 2 of type 'string'
(ERROR) ArmoryQt.py:646 - 9 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:651 - File mempool.bin does not exist. Nothing deleted.
(ERROR) armoryengine.pyc:13270 - Error processing BDM input
(ERROR) armoryengine.pyc:13271 - Received inputTuple: GoOnlineRequested [13, 43561706, False]
(ERROR) armoryengine.pyc:13272 - Error processing ID (43561706)
(ERROR) armoryengine.pyc:13273 - ERROR:
Traceback (most recent call last):
File "armoryengine.pyc", line 13256, in run
File "armoryengine.pyc", line 12808, in __startLoadBlockchain
File "CppBlockUtils.pyc", line 1230, in SetBlkFileLocation
TypeError: in method 'BlockDataManager_LevelDB_SetBlkFileLocation', argument 2 of type 'string'
(ERROR) ArmoryQt.py:646 - 10 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:651 - File mempool.bin does not exist. Nothing deleted.
(ERROR) armoryengine.pyc:13270 - Error processing BDM input
(ERROR) armoryengine.pyc:13271 - Received inputTuple: GoOnlineRequested [13, 48373466, False]
(ERROR) armoryengine.pyc:13272 - Error processing ID (48373466)
(ERROR) armoryengine.pyc:13273 - ERROR:
Traceback (most recent call last):
File "armoryengine.pyc", line 13256, in run
File "armoryengine.pyc", line 12808, in __startLoadBlockchain
File "CppBlockUtils.pyc", line 1230, in SetBlkFileLocation
TypeError: in method 'BlockDataManager_LevelDB_SetBlkFileLocation', argument 2 of type 'string'
I started the program with this shortcut "G:\armory testing\ArmoryStandalone_0.89.99.2_win_all\ArmoryStandalone\ArmoryQt.exe" --datadir=G:\armory testing\ArmoryStandalone_0.89.99.2_win_all\ArmoryStandalone\datadir Maybe, I need to use forward slashes? If you are modifying the target of a shortcut, I believe bot '/' and '\' are fine. If you are running from a git/cygwin shell, you have to use forward slashes '/' or else it interprets the backslashes as escape characters. I'm still quite curious how that error is cropping up. If you are ambitious, you can close Armory, unpack the library.zip file inside that directory, then modify armoryengine.py. When you are done, re-zip it and overwrite library.zip. Then it should use the new code when you run ArmoryQt.exe. This works for everything except ArmoryQt.py which is the entry point for the app, so it treats that file differently. But all the other python files should be modifiable in that way mentioned. If you've got a problem with line 12808 in armoryengine.py, try adding the following to line 1280 7: print '***blkdir var:', type(blkdir), len(blkdir), '"'+str(blkdir)+'"' Also make sure you are running with --debug. The next testing round, I should probably turn on all debugging output by default. |
|
|
|
Could it be a unicode issue? Do you have non-ASCII characters in your paths? Unfortunately, the error does not explain what the expected and supplied data types were. But it wouldn't surprise me if "type 'unicode'" was one of those...
The issue is that if the %HOME%/Desktop directory doesn't exist, then there is an error and it doesn't check any more locations. I think the code here needs to check if the path exists before checking if path/*.* exists. I will try the re-download. There's two different problems. The $(DESKTOP) issue is one that is a simple bug I can fix. The app shouldn't crash because it can't find the desktop folder. The other problem is it trying to set the new LevelDB directory, which it attempts to create as os.path.join(ARMORY_HOME_DIR, 'databases') It appears that the result of that operation is getting passed to the SWIG'd C++ code, and throwing an error. Either because it's expecting a string and got something else, or we passed a string and it was expecting something else. I would get it's the first problem, and that os.path.join is returning a unicode output that is not handled properly. |
|
|
|
[edit3] It crashes after around a minute When it crashes, it doesn't kill the bitcoin daemon. I have to manually use "bitcoind stop" to stop it (or kill the process). guardian.exe doesn't appear to be in the .zip file. (ERROR) armoryengine.pyc:10973 - Could not find guardian script: G:\armory testing\ArmoryStandalone_0.89.99.2_win_all\ArmoryStandalone\guardian.exe
(ERROR) ArmoryQt.py:1271 - Failed to setup SDM
Traceback (most recent call last):
File "ArmoryQt.py", line 1268, in startBitcoindIfNecessary
File "armoryengine.pyc", line 11105, in startBitcoind
File "armoryengine.pyc", line 10974, in getGuardianPath
FileExistsError
(ERROR) ArmoryQt.py:646 - 6 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:651 - File mempool.bin does not exist. Nothing deleted.
(ERROR) armoryengine.pyc:13270 - Error processing BDM input
(ERROR) armoryengine.pyc:13271 - Received inputTuple: GoOnlineRequested [13, 35672076, False]
(ERROR) armoryengine.pyc:13272 - Error processing ID (35672076)
(ERROR) armoryengine.pyc:13273 - ERROR:
Traceback (most recent call last):
File "armoryengine.pyc", line 13256, in run
File "armoryengine.pyc", line 12808, in __startLoadBlockchain
File "CppBlockUtils.pyc", line 1230, in SetBlkFileLocation
TypeError: in method 'BlockDataManager_LevelDB_SetBlkFileLocation', argument 2 of type 'string'
(ERROR) ArmoryQt.py:646 - 7 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:651 - File mempool.bin does not exist. Nothing deleted.
(ERROR) armoryengine.pyc:13270 - Error processing BDM input
(ERROR) armoryengine.pyc:13271 - Received inputTuple: GoOnlineRequested [13, 3242000, False]
(ERROR) armoryengine.pyc:13272 - Error processing ID (3242000)
(ERROR) armoryengine.pyc:13273 - ERROR:
Traceback (most recent call last):
File "armoryengine.pyc", line 13256, in run
File "armoryengine.pyc", line 12808, in __startLoadBlockchain
File "CppBlockUtils.pyc", line 1230, in SetBlkFileLocation
TypeError: in method 'BlockDataManager_LevelDB_SetBlkFileLocation', argument 2 of type 'string'
[/edit3] Okay, I left out guardian.exe by accident. I just uploaded a new zip file right now with it in there. If you download the zip file again, it should be there this time. guardian.exe is responsible for killing bitcoind if Armory doesn't do it. So that addresses two of your issues. I'll look into the "SetBlkFileLocation" issue. Could it be a unicode issue? Do you have non-ASCII characters in your paths? Unfortunately, the error does not explain what the expected and supplied data types were. But it wouldn't surprise me if "type 'unicode'" was one of those... |
|
|
|
Windows XP PRO AMD Athlon X2 5200+ 300GB HDD 4 GB RAM I know, it's kinda crappy.  Well, I want it to be supported on such systems. So this is a good test. I wonder if it's an issue with Windows XP. For instance, I bet if I setup the new build environment in Windows XP, it would be forward compatible with Win7 and Win8, but not the other way around (it's being built on Win7-64bit right now, but as a 32-bit app). I assume your Windows XP system is 32-bit... correct? |
|
|
|
I can't seem to get it to work. This is what appears in the text log: Traceback (most recent call last): File "ArmoryQt.py", line 21, in <module> File "psutil\__init__.pyc", line 85, in <module> File "psutil\_psmswindows.pyc", line 15, in <module> File "_psutil_mswindows.pyc", line 12, in <module> File "_psutil_mswindows.pyc", line 10, in __load ImportError: DLL load failed: The specified procedure could not be found. ?  Can you post system specs? If others have this same problem, it would be nice to try to correlate it with specific system configurations. I just tested it on one of my non-dev windows machines and it works. But I also have python installed, which shouldn't matter (since this is a standalone package), but it might. So I can half-verify it working on Windows 7-64bit with python pre-installed. |
|
|
|
Let's do this! https://bitcointalk.org/index.php?topic=299684.0Please don't use it with large amounts of money yet. It's probably still chock full of bugs, but I've done quite a bit of internal testing and feel pretty good about the major features. Besides fixing the rescan-on-every-load issue, the feature set is frozen. I'd like to fix what's in it, rather than add anything new. A whole bunch of less-critical things (unicode fixes, message signing, tx size limits), will go into the next version (and that next version will not take 3 months to release ). Please discuss bugs & general observations in that other thread, to not clutter this one! |
|
|
|
Armory version 0.89.99.16-testing:On my Linux system, I have 2,300 addresses and probably 1,000-2,000 transactions. It takes 24 sec to startup Armory on mainnet when I manage Bitcoin-Qt myself and it's already sync'd. And 290 MB of RAM at steady-state. Latest version contains fragmented backup tester and Bitcoin-Qt-compatible message signing! (and verification). ----- GPG-signed hashes of all installers (using the Armory Offline Signing Key) Armory 0.89.99.16-testing: Signed hashes of all installers ----- WINDOWS Armory 0.89.99.16-testing for Windows Vista, 7, 8 (Both 32- and 64-bit)----- Mac/OSX Armory 0.89.99.16-testing for Mac/OSX 10.8 and 10.9----- Ubuntu/Debian (packages are signed directly with offline GPG key using dpkg-sig) Armory 0.89.99.16-testing for Ubuntu/Debian 10.04-64bit Armory 0.89.99.16-testing for Ubuntu/Debian 10.04-32bit Armory 0.89.99.16-testing for Ubuntu/Debian 12.04-64bit Armory 0.89.99.16-testing for Ubuntu/Debian 12.04-32bit----- Ubuntu/Debian Offline Bundles Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 10.04-32bit Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 10.04-64bit Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 12.04-32bit Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 12.04-64bitThanks to picobit, we have a working testing release for OSX. It appears like it might work on a much wider set of OSX systems, too! (For reference, picobit basically gave me a recipe for building a portable Armory app, he didn't actually build it himself -- the package was built on my OSX system). [note: there are bugs in 10.9/Mavericks that may make it unusable...gotta wait for Apple to fix it]
New features in 0.89.99.X (to be 0.90-beta when released):- RAM usage and startup time reduction: RAM reduced to less than 300MB, and startup time typically under 60 seconds after initial DB build!
- Persistent database: Armory now maintains its own blockchain database for fast startup. Make sure you have space to duplicate the blockchain (will be reduced in a subsequent version; this way was easier for now).
- Full MacOSX support*: thanks to picobit for the builder, though the Apple+PyQt bugs prevent full usability in 10.9. Until Apple pushes an update, it may not be very usable on 10.9.
- New Backup Center: Better organization and description of backup options. Includes unencrypted digital backups, now.
- Fragmented Backups: Shamir's Secret Sharing (M-of-N secret splitting); balance your physical security and redundancy. Create up to 5-of-6 backups in Standard & Advanced modes. Up to 8-of-12 in Expert mode. Fragments are also deterministic for a given M value. For example, if you make a 3-of-5 backup, you can later make a 3-of-7 and the first 5 will be the same as the 3-of-5 (but you will get different fragments if you do 2-of-N or 4-of-N!)
- SecurePrint: Paper backups optionally encrypted with code on screen to prevent private key exposure to printer and other network devices. SecurePrint code should be identical across all backup types for a given wallet
- Half-sized paper backups: The chaincode is now derived from the private key, meaning only two lines of data for wallets created with the new version of Armory. Yet, all backup features work with older wallet without a hitch -- they'll all show four lines (if you don't believe me, prove me wrong and collect your 0.04 BTC!)
- Paper backup tester: test any kind of paper backup before you bury it in your backyard. Includes subset testing of fragmented backups.
- Message Sign & Verify: Finally Bitcoin-Qt-compatible signing and verification. Will have a new ASCII-armored version like PGP signing, soon
- Fixed broadcasting non-std signatures: Older versions of Armory produced signatures that have non-standard padding. If an older version is used on your offline system, you can't broadcast those signed transactions with 0.88.1 online. This version will fix the padding and broadcast successfully
- Improve *nix Makefile: Improved Makefile that should work out of the box on most Linux distros once the proper depedencies are installed. See the osx_picobit directory for compiling on OSX.
The new sequence of operations executed by Armory (with auto-bitcoind) is outlined below. The times are what I've observed in my testing on Linux Mint 64-bit with regular HDD (no SSD), and a Windows 7-64bit VM running on that same HDD. - (1) Start bitcoind (using "--datadir" supplied on the command line)
- (2) Download/update blockchain (same as previous version, may take 4-16 hours)
- (3) Process all headers and determine longest chain ("headers-first" is new feature of Armory, will help with lite-node implementation later)
- (4) Build database of raw blockchain data from the blk*.dat files produced by bitcoind/-qt (30-90 min).
- (5) Scan database for transaction data relevant to your wallets (Linux: 5-20 min, Windows: 20-45 min)
Step 4 (building the DB) is done only once. There is no reason to do it again (besides updating for new blocks), unless the user explicitly requests it using the " --rebuild" flag. Step 5 also is only done once, unless you import or restore addresses or wallets. Doing so will initiate a rescan of the blockchain to find the transaction history. You can force a rescan using the "--rescan" flag. Known Issues: - Unicode everything Ugh. Will work on that after it works for US users. The next version will get some unicode-TLC (it will mostly be a bug-fix and polishing release, with nothing major except for message signing)
- There are some DB consistency issues that may lead to a lot of DB rescanning and sometimes rebuilding. If you always shutdown cleanly and don't interrupt Armory while it is updating, you will avoid that and it will start up quickly. However, there does not appear to be any danger in having this happen, it's just inconvenient.
- Occasionally a zero-confirmation tx disappears when it is included in a block, instead of sticking around and getting one confirmation. Restarting should fix it (even without a rescan!)
- Occasionally a crash with a "Partial StoredTx" error in the log file. Please PM me if you observe this error. I suspect I know the problem, but it would help to have someone who actively has it so I can test fixes
Instructions for building on Ubuntu/Debian: This is just a copy of the build instructions on the website, but has an extra step to check out the "testing" branch instead of the "master" branch (which is still 0.88.1). Just copy the following commands into a terminal one-by-one. In Linux, you can simply highlight text using the mouse, then middle-click in the terminal (and press enter after each one). It works between just about any two applications running in Linux, but it's especially important in the Linux terminal because Ctrl-C has a different meaning there. (NOTE: do not copy the '$' symbols) $ sudo apt-get install git-core build-essential pyqt4-dev-tools swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted python-psutil
$ git clone git://github.com/etotheipi/BitcoinArmory.git
$ cd BitcoinArmory
$ git checkout testing
$ make
$ python ArmoryQt.py
|
|
|
|
|
For now you have to use 10.04, but there's a link to the download on the website where you get the bundle, too.
It's been almost two years since I started the whole offline bundle thing, and it does seem to make sense to upgrade the whole thing to 12.04. It's a lot of work to support a new offline bundle target, but it' fairly easy once I figure out the dependency tree and get it integrated my build/release process.
It just hasn't been high on the priority list, and 10.04 is going to have a wider array of hardware "compatibility" than 12.04 (i.e. it will probably still work on laptops made in 2001, and doesn't really matter if it doesn't recognize the WiFi card of a new 2014 laptop.
|
|
|
|
|
Show Posts
