Armory Version 0.77-alpha! (Testing Release)I need testers and I need feedback! Please help test 0.77! Armory 0.77-alpha is a major-bugfix release. There was a series of bugs in 0.76 causing serious performance issues if you have a lot of transaction activity with your wallets. In some cases, Armory was almost unusable. It was inefficient operations done on every new transaction on the network -- now the processing is efficient, and only performed on new blocks and transactions involving one of your wallets. Also, there was a problem with one of the install scripts on actual Debian systems (not just Debian-like systems such as Ubuntu). I think it's fixed, but I haven't had a chance to try it yet. Download the testing release (likely to be the full release...)http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77_Win64.msihttp://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77_Win32.msi (offline only!) http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.7-1_amd64.deb (Ubuntu 11.04+, 64-bit) http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.6-1_amd64.deb (Ubuntu 9.04-10.10, 64-bit) http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.7-1_i386.deb (Ubuntu 11.04+, 32-bit) http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.6-1_i386.deb (Ubuntu 9.04-10.10, 32-bit) Next version will be 0.80-BETA! IMPORTANT:Performance on Windows is degrading rapidly. Blockchain size is accelerating (mostly due to SatoshiDice) and wreaking havoc on Windows systems because the windows-mmap-equivalent is crap . I am half done with a once-and-final, will-work-on-any-system upgrade to the blockchain utilities. Once I finish this, it should be able to run on WinXP-32bit with 512 MB of RAM! Until then, Windows users will have to suffer through long load times on 64-bit-only.
|
|
|
|
If you compile the CppBlockUtils for Armory, you can do a lot with a very simple python script: >>> from armoryengine import *
>>> priv = hex_to_binary('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa')
>>> binAddr20 = convertKeyDataToAddress(priv)
>>> print hash160_to_addrStr(binAddr20)
'19YCGbqXnsaTNTinE7EzjYS2shhv7BSQw1'
It is a royal pain to compile the CppBlockUtils in Windows, but it is quite easy in Linux. Just follow the instructions on my Building Armory from Source page. Perhaps I will add a download to a precompiled CppBlockUtils.so/.dll/.pyd/.whatever for users that want to access armoryengine without compiling anything. |
|
|
|
So code up a prototype:
+ Implement code that computes and publishes 'balance blocks' and 'balance block hashes'. Convince a couple people with extra download bandwidth to run it.
+ Modify one of the bitcoin implementations to download the latest 'balance block' from some trusted place at startup, and use it if transactions/blocks can't be found in the traditional block database.
+ Extra credit/paranoia : query a couple of trusted places for the balance block hash, and make sure it matches the hash you got.
+ OR: randomly spot-check the balance block by requesting blocks in the traditional way, and make sure the balance block doesn't list any outputs as unspent that are actually spent.
You don't want bitcoin address balances, there are no addresses way down deep inside. You need to know which transaction outputs have not yet been spent, and the value of those outputs.
I'm not excited about this proposal, because I think it is solving a problem that doesn't need solving yet, and my priorities for bitcoin continue to be wallet security and network stability, not making it quicker for newbie solo miners to get a full blockchain so they can start validating transactions/blocks.
Gavin, If your re-read my proposal on the other thread, the proposal does enable you to get the entire unspent-txout-list for any address, with only a few kB from the network (after you have the headers). This means that you only download a couple kB from the network for each script/address in your wallet and you can operate fully without trusting anyone or anything except for the headers. Hash160 addresses used more than once will have the same script hash and thus be aggregated into a multi-node sub-merkle-tree. BIP 16 and other creative scripts used once will be leaf nodes represented by only a single-node sub-merkle tree (well it would just be a single value, not a tree). This isn't for miners... this is for lightweight users. It means that I can import an address on my phone wallet and get a full list of unspent outputs with only the headers plus a few kB from the network -- you only need the master-merkle branch (which is O(log(N)) where N is the number of unique scripts/addresses in the blockchain) and the sub-merkle tree (which is the number of unspent txouts for that script/address). That's a huge improvement for Bitcoin as a whole, when even crappy smartphones can be 99% fully operational, using only block headers and a few kB from the network. (I say 99% because they can't do 100% of the verification needed for mining, but they can at least verify that the inputs of a zero-confirmation-tx are valid and unspent without relying on any other service). It's always been an assumption in my mind that lightweight nodes will be second-class citizens in the BTC world. But if this can be made to work, computationally, I believe even lightweight nodes can be as secure as full nodes. And of course, you get the 90%+ compression. And it's all opt-in -- client developers can just ignore the second chain if they want. The remaining uncertainties are: (1) How complex will it be to maintain a separate blockchain and all that stuff, and (2) what is the compute complexity/optimizations of building & updating such a blockchain? |
|
|
|
i had it on my pc and worked the first time but now it won't work at all. i will clean the pc and will try again. but let us know when the new improved version will be released will be a pleasure using it
Absolutely! Honestly, I'm anxious to get it together, but the changes are big and scary, and I acquired a minor addiction to Diablo III which has temporarily affected productivity. Luckily, I'm getting bored of D3 and will be back on track again soon!  I expect the new version will be testable in a couple weeks, and a full beta release by the end of June. |
|
|
|
etotheipi i love armory client but the 32 version must be done to work online. i think many users will use it as an active wallet. also i don't know for some reasons my armory 32 client won't install on a virtual os. i got an error saying the software wasn't installed correctly and to reinstall the application
The next update will work on all systems, with any amount of RAM. I'm completely re-doing the blockchain utilities, without memory-mapping, because of how unreliable it is on Windows, and likely to stop working on Linux 32-bit by the end of the year. That will be the end of arbitrary system requirements (besides having to have Satoshi client running), and also enable me to start doing a fast-startup version. I compile and test Armory it on a WinXP-32bit VM. And I just tested it on a Win7-32bit VM. It installs fine for me in both. I'm curious what could be causing it to fail on your system... does your system have a non-standard setup? |
|
|
|
I tried to create new wallets. It simply dies with "Illegal instruction" no matter it is encrypted or not. It dies even I click "receive bitcoin". However, it could show the existing addresses without dying.
I also tried to run as root. Since I did not use it with root before, there is no wallet. However, it still has the same problems
So I believe there is nothing wrong with my wallets. Do you have any idea where the message "Illegal instruction" comes from? Is it somewhere in Armory source code, or from a 3rd party package?
In the worst case I have to reinstall the OS but I want to try to fix it first
I have actually never seen that error, and it's definitely not part of Armory code. "Invalid Instruction" sounds like an assembly/low-level-language error. Perhaps it comes from the crypto++ library... ? There are three core dependencies for Armory in Linux: python2.X, python-qt4 and python-twisted. I suppose there could be issues in one of those. But, of course, installing those results in a tree of 60 other dependencies... so there could be an issue with any one of them. Have you tried removing all your wallets and starting a completely fresh, wallet-less Armory, and then creating new wallets? I'm wondering if one of your existing wallets is causing an issue on load that doesn't show up until later (a poisoned wallet). Please email or PM me to continue this discussion. One of us can feed the info back into the thread if we figure it out.... |
|
|
|
first of all, i'm using ubuntu 11, and I'm already starting armory as suggested. Everything seems normal except a few GTK-Warning about pixmap at the beginning
no, my label is very short so that's irrelevant
I tried to delete one of my wallets (which contains no BTC at all). When I try to restore by paper backup, the "Illegal instruction" death happens again. When I tried to type one wrong character in the root key field, it first shows Checksum error, then illegal instruction death. When I tried to put all "a"s in the root key and chain code, it just shows "Checksum fix failed" and won't die.
As long as I still have the correct paper backup, I suppose my BTC is 100% safe, right?
Thanks!
Yes. So far, no one has lost any money with my program (at least no one has reported it), and I've never had a hint of a problem with paper backups. So, the odds are good your money is still safe I see now that you are having the problem on multiple wallets, which leads me to believe something went awry with your system, an encryption library, and/or the Armory installation itself. But you said you reinstalled with the newer version, so it's probably not the Armory installation. And all the encryption/signing stuff is compiled in, so I don't think that would be it... Can you make a new, encrypted wallet, and see if it works as expected? Unencrypted wallet, too. I am done for tonight, but I'll continue this conversation tomorrow. I'm anxious to figure out what's going on... |
|
|
|
I have some wallets in an offline machine. It worked perfectly before. Today, however, I find that it keeps returning "Illegal instruction" and dies after I key in correct passphrase for any wallet, no matter I am trying to make a paper backup or to sign an offline tx. I was using 0.7.5 and have updated to 0.7.6 but the problem is still here. What can I do? Thanks! By the way, I still have all paper backup Absolutely! Email me your shipping info and I'll send it out.
I don't suppose you used an exceptionally long wallet description/label, did you? I found a terrible bug in the wallet-IO code that causes something similar, which was fixed in 0.76. But if you were in 0.75 when you changed the label, it would permanently corrupt the wallet! Also, how many addresses do you think you used in the wallet? Regardless, I recommend that you go to the Armory home dir (/home/user/.armory or C:\Users\username\AppData\Roaming\Armory) and backup all the wallet files into another directory or to a USB drive. Then delete the original and restore from paper backup (you can't restore a wallet if you have an existing one with the same wallet-ID, so you must delete the old one first). "Import Wallet" --> "Restore from Paper Backup". Also, what OS are you in? If it's Linux, you might be able to extract an error message for me (just open a terminal and start Armory with "python /usr/share/armory/ArmoryQt.py" instead of through the menu). This is very concerning! I hope we can get it figured out. |
|
|
|
Meaning I can know in advance whether the incoming transaction (API or form) is up to par with my requirements, at least based on what I've read so far. Ok, I'll start investigating the technicalities of this. Thanks to everyone commenting here Why would someone use this service instead of just broadcasting that TX to the network ? Because broadcasting the message to the network [as I understand it] requires the user to be connected to at least one peer in the network, meaning a different kind of protocol to handle. Having a service that will broadcast your transactions to the network for a small fee (if the transactions are not small ones) requires you to compile and sign a transaction, and send it to the broadcasting service via HTTP, very straight forward for client-side clients and thin clients. I can get on the Bitcoin network, find 3 peers and broadcast my transaction to all 3 then disconnect. In less than one second. There is no need for an external service, unless you are offering something extra, like anonymity. |
|
|
|
Hmm the more I think about this the more I think it could work.
In reality, you only need to store the most recent balance block and subsequent transaction blocks. As long as you have block headers for all previous balance blocks, you can be assured that noone can cheaply spoof a fake balance chain due to the high cost of each proof of work. You wouldn't even need old transaction block headers, and you could easily bootstrap a new node just by sending them (1) the balance block headers (2) the most recent balance block (3) all transaction blocks that occurred after the most recent balance block.
This would cut storage requirements massively.
I just need to find some free time so I can code this up
I had grand plans of pioneering ideas like this. And this might be the other half of the solution to the other scalable-blockchain thread (which I expanded upon, and d'aniel linked above: https://bitcointalk.org/index.php?topic=52859.msg885838#msg885838). Complexity is a problem though... creating a new blockchain with the networking, etc, is not a trivial task (or maybe it is, since there's so many other merged-mining chains to use as a template). Also, I don't know what the compute-complexity of the balance trees are. I'm going to have to spend some time with pencil&paper on this one... At least the chain itself will be small once it's running... On the upside, if it is feasible, it would be totally worth it. It would completely enable lightweight nodes to get on the network and verify their own balances and unspent-output lists without downloading even the pruned blockchain -- they'd only need the headers of the main chain and balance chain, and one merkle branch per address (a few KB). I had kind of looked past the idea because I assumed it was going to cause a hard fork, but using a second chain seems to solve that elegantly... |
|
|
|
|
This is most interesting!
I actually purchased a couple USB-to-serial cables and a null-modem converter and had started to play around with this myself. I got as far as determining that it would work, for $25 in cables, and when I get done with some other crazy priorities, I plan to develop and integrate a serial-port interface into the GUI for the hardcore users. It's a promising idea for filling in the "optimal" usability-security curve...
Unfortunately, Armory code is extremely well-commented, but there's not a lot of top-level documentation for using it. Again with the priorities...most users are using Armory instead of developing with it, so I haven't spent much time on the developer documentation. However, there is a lot of example code in the extras/sample_armory_code.py file, which shows a whole bunch of different ways to access the armoryengine tools from python. Loading & querying the blockchain, reading wallets, scanning for balances, iterating over all blocks/txs/txins/txouts. It needs to be cleaned up a bit, but obviously it is usable since Armory is built with it.
And, I'm always willing to help other developers dig in. Please PM or email me if you have any questions about leveraging specific functionality with the library. I would be pleased if someone else was able to expand the functionality like this while I work on some of the more critical stuff (like making sure Armory still works at all, after the blockchain exceeds 2 GB...)
|
|
|
|
By the way, just for reference the block in the main chain with the lowest difficulty is: Block with the lowest difficulty:
Block Num: 125552
Block Hash: 00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d
Equiv Difficulty: 35,987,768,035
Equiv Diff bits: 67.07 That block would've been valid even if the network difficulty was 35,900,000,000 (yes, billion), even though the actual difficulty was 244,000. That may seem ludicrous, but it's actually on par with the approximately 2^68 hashes that the network has done up until now. The last part of it (the 67.07) says that if you were to do 2^67.07 hashes, you'd have a 50% chance of finding a hash just as good... |
|
|
|
Updated! Looks like SD finally went on a lucky streak and are in the black for once! +1100 BTC is not too shabby!
Also, they are now responsible for 122 MB of blockchain and more than 50% of transactions since Apr 18, 2012.
bleh -- we need to look into transaction pruning... I have always believed that this should be a priority, but many devs I've talked to insist that it's not. I wouldn't mind pioneering this in Armory if I can ever get networking-independence... I believe I came up with a solid way to not only prune, but also allow lightweight nodes to verify balances without downloading the entire chain! Don't want to derail this thread, but I appended it to the Scalable blockchain thread. I wouldn't mind seeing some more discussion about it (mine, as well as other proposals). |
|
|
|
|
Updated! Looks like SD finally went on a lucky streak and are in the black for once! +1100 BTC is not too shabby!
Also, they are now responsible for 122 MB of blockchain and more than 50% of transactions since Apr 18, 2012.
|
|
|
|
|
You're going to need Diablo III accounts to handle the transfers of the D3 gold. That puts you at risk of getting banned, getting stuff confiscated, etc.
You might consider just holding the BTC and letting the players do the money transfer. That's a lot less risk for you. But I don't know the details of transferring gold in D3...
|
|
|
|
|
Absolutely! Email me your shipping info and I'll send it out.
|
|
|
|
Any chance I can order a shirt for BTC? I know you had some trouble with the first batch of shirts, but if thats all sorted out, I would like one.
Absolutely. There's a list of donation levels and rewards on the Armory Donation Page. I'll happily take into account previous donations if you think it's a little steep (in your case, I know you donated...twice?... already?) Unfortunately, the shirts ended up being kind of expensive -- future advice: pick a logo that doesn't require full-color to be rendered properly, that probably doubled the cost of the shirts despite being tiny little thing on the breast. :-/ |
|
|
|
Uses just under 2GB of memory here, initial load <20seconds. This is however on a dedicated server with 128GB of memory  I cant really complain about that. You got me beat for sure. My macbook air loads it in anywhere from 60 - 90 seconds depending on how much other stuff I am doing. It still locks up at 100% CPU for a few seconds when new blocks are found in both Mac and in a linux VM on mac. Windows and native linux don't seem to have the problem FYI: the next release of Armory will be 0.80- BETA, and will have no more RAM requirements at all. The initial startup will still be scanning the blockchain, but the program will only store references to file data, and retrieve it on demand. Technically, that's what MMAP is supposed to do, but the mmap-equivalent in Windows is pretty terrible. I would complain that I am being forced to change the architecture based on Windows alone, but I suspect Linux 32-bit might stop working once blockchain is 4 GB, anyway... And the semi-regular freezes in 0.76 will be fixed as well. I'm 98% confident that it's due to table sorting, even when you didn't explicitly sort any tables. Performance like this has never been an issue, and it doesn't need to be. I just got have to a little work to get the "correct" solution in there. Hoping to have all this for 0.80-beta, but it might be a while before I get it done, so don't hold your breath |
|
|
|
Users don't want to go out and purchase some weird currency prone to theft, and install potential malware on their system, just so they can pay a stranger over the internet for items that may never be sent.
exactly, that's why everything (including storing the bitcoins) would be handled by the exchange. users just have to keep his login password safe Oh, I misunderstood. I thought the service was simply for letting users post and bid on things and handle the cash themselves. If you're talking about a service, with customer support, then you'll have to take some profit in order to sustain non-trivial costs of maintenance and handling user issues/complaints, etc. And you risk violating Blizzard EULAs unless you plan to be completely detached from the game and only handle the money side. But then that means you have no way to verify whether the seller actually transferred the items to the buyer. Have fun arbitrating disputes... In the end, Blizzard is being greedy, but I don't think there's a legit way for competition to step in, even if they could get away with it legally. On the other hand, if we're talking Diablo II and all sales are between strangers trusting each other over the internet, then Bitcoin fills the niche pretty well. But I think Blizzard has firmly undercut any potential competition on this one... |
|
|
|
|
To add to this ... I think the idea is fantastic if people are already using Bitcoin and the RMAH didn't exist. Unfortunately, neither of these are true, and thus the idea is DOA.
Users don't want to go out and purchase some weird currency prone to theft, and install potential malware on their system, just so they can pay a stranger over the internet for items that may never be sent.
Relative to that, 15% fee seems completely fair for the 100% scam-proof, easy-to-understand method of just using the RMAH. I think 15% is ludicrous actually... Blizzard is being ridiculously greedy. But they'll get away with it because they know how desperately users want to be able to buy and sell items to other users, and they know users will pay it.
|
|
|
|
|
Show Posts
