|
I'm fairly certain that we have a working armoryd.py on the 0.91-dev branch. That branch is experiencing a little turbulence, but we've been pretty good about making sure things run before we push to it.
That branch has the updated armoryd.py. Feel free to try it and report any issues.
|
|
|
|
is it usefull for armory to run bitcoind with txindex=1 ?
Greets
mmh, no idea? No, I believe txIndex=1 allows you to query arbitrary transactions from bitcoin-qt/bitcoind, but Armory doesn't use that. Armory only uses it for the raw blockchain files, and to forward transactions to the network. It doesn't matter whether Bitcoin-Qt indexes arbitrary transactions. Armory will create it's own tx index after scanning the raw blk*.dat files. |
|
|
|
Here is what happens
I downloaded and installed "Version 0.90-beta for Ubuntu/Debian 12.04-64bit" on Ubuntu 13.10 64bit
Installed bitcoind and everything else it asked for using the button in the app
It starts just fine, creates a wallet and downloads the blockchain.
Once it did that i closed the app.
When I tried to start it later, nothing happens when clicking on the icon. Literally nothing.
The offline and testnet icons start it just fine.
I reverted to factory settings from the offline version. But starting the normal Amory icon after that does the same. Nothing.
Sometimes after restart Ubuntu says there has been system error though.
The ubuntu install is fresh and with minimal stuff installed, so it should be clean and not a problem with something else.
Is it just me?
Try starting it from the command line. Just open a terminal and type "python /usr/lib/armory/ArmoryQt.py". If it fails to load, you'll see some information about why. You can post the output here. |
|
|
|
Heres my take.... Use Armory, create your wallet(s) etc, https://bitcoinarmory.com/Then do a "paper backup" of it. The backups are "Deterministic" meaning they only have to be backed up once and will always work. ... IMPORTANT: Make sure you can remember the password, and that you KNOW you will remember it in 20 years, if you are unsure, then carve at least a hint into the ingot as well. Armory paper backups are explicitly unencrypted. The vast majority of people using the paper backups is because they forgot their wallet password. If you need physical security, use Armory's "fragmented backup" feature to create multiple pieces and store them separately. |
|
|
|
The bottom line, some people are fully aware of what they are doing and just want to use a receive address they used before. This is an obvious advanced bitcoin client here, please don't turn around and say you are looking out for the new bitcoin users and their practices. If I want to use another address, I'll pick one. I can see the very paranoid, overly security conscious people worried about this, but their also the ones that won't even use online banking because they're afraid their account will get hacked. Being overly paranoid and secretive puts you into certain positions you have to deal with, and if you are hiding something that's a whole new story.
This isn't a conspiracy theory. No one is stopping you from reusing addresses. But it's not the default behavior because the privacy implications are egregious. It absolutely is our job to set sane defaults, and users that know what they're doing can deviate from it. This topic has been discussed endlessly, everywhere. It's generally accepted best practice that you don't reuse addresses unless you have an explicit reason to. It is discouraged, but there are reasons to do it (such as donation addresses). There's a reason every Bitcoin client is moving towards BIP 32 -- so they can employ best practices without the issues with backups. If you don't like it, then go ahead and reuse your addresses. |
|
|
|
|
We changed that fee to 0.0001 in the latest version, but some people ended up with explicit 0.0005 from the previous version, so the "default" did not update. So you might have to go to file->settings and modify the default there.
|
|
|
|
People complaining about fees is recurrent. However, the Armory team has no power on that front. This discussion doesn't belong here.
If you want to allow for no minimum fees, you can modify the code. It is actually quite a simple modification.
To reiterate what goatpig said, because it needs to be repeated: Armory does not have control over network fees. Bitcoin-Qt/bitcoind implements a set of fee rules to prevent spam, and Armory must follow those rules or the transaction will literally be DOA. It's because all transactions that Armory broadcasts, must go through your local instance of Bitcoin-Qt, which will refuse to forward the transaciton if it doesn't have sufficient fee. For that reason, Armory is stuck with Bitcoin-Qt rules. You can modify the code to reduce the fee, but you'll just be rejected. You have to modify both Armory source code and Bitcoin-Qt source code if you want to do this. Fees are complex, but they're there for a reason. The current fee for most tx is 0 or 0.0001. I manually set the fee to zero, and about 19/20 of my transactions make it to the network. Occasionally, the tx doesn't meet the allowFree() criteria and Armory asks you to include the correct fee based on Bitcoin-Qt rules. You can't override that behavior because your transaction will be rejected 100.0% of the time if you do (unless you modify the Bitcoin-Qt source code). |
|
|
|
Thanks for the reply but can you elaborate maybe step-by-step as I'm stilling trying to learn my way around. It sounds like I access the wallet offline, click "backup individual keys" then create a paper backup of that info. Which boxes should I check there to ensure I have all the information I would need in the future to access the coins in this wallet? The options in that window are below.
Address String
Private Key (Plain Base58)
Private Key (Plain Hex)
Public Key (BE)
Imported Addresses Only
Include Unused
Include Paper Backup Root
Thanks Again I'm still trying to learn my way around.
We get this question occasionally and I think it's crazy. Any version of Armory ever created can restore your wallet and/or let you access your private keys to be exported. Regardless of the availability of github (which is very reliable, btw), you only need one person in the entire world who's got an old installer in the downloads folder. And if Bitcoin is valuable enough, someone will make it available. It's not like there's going to be billions of dollars behind Armory wallets and everyone in the world will spontaneously delete all copies of Armory code/installers that ever existed (and github deletes the repo). Look at DVDDecryptor, and SSHSecureShell 3.2.9. Those are two pieces of software that I use that stopped being developed 10+ years ago, yet the last version created is still easily available on the internet. I don't see how a program holding huge amounts of money would not survive. In reality, github will keep it forever, anyway, along with anyone who ever cloned the repo. |
|
|
|
|
Luckily, one of the things I'm doing in 0.91-beta is fixing all the issues with Armory that cause it to slow down when huge wallets are loaded. One of those things is the fact that the main thread processes new blocks, and freezes everything while it's processing. If it takes more than 20s, then you can end up with this error. If we stick it in another thread, and don't update the GUI until it's done, then it doesn't matter how many addresses you have, you will just be notified of new blocks with a delay.
Also, there's just some missing optimizations that lead it to be so slow, anyway. Those will be fixed first.
Finally, I may be able to disable the unclean shutdown thing. It just occurred to me that I can rewrite all the address history only after each block when it's in a good state. If it crashes during a block processing, it will restore the previous state. And Armory will rescan the last 2016 blocks anyway.
|
|
|
|
|
We are working on creating a system where you can generate a deterministic wallet and use the root public key as a form of identity, but you don't give out the chaincode so no one knows how to compute your addresses. But you can generate addressees and provide proof that it was derived from the root key, without revealing the chaincode or any other addresses. This would be far superior to green addresses.
|
|
|
|
Re-using addresses to me is a good feature of bitcoin. Why are programs trying to stop that? When you have a donation address, a payment address, an address just associated with your company you would want people to know that address. Let the user make up their mind and do what they want instead of the program, right? Almot %90 of the users here paste their personal bitcoin address in their signature. It is more of a common practice to re-use addresses then anything and when a program or someone tries to just change that, questions will be asked....hence an entire thread. Address reuse is privacy pollution. And that should up to the user to do with what he/she wants to do with his/her privacy. Why would other people care what I do? Because it's not expected of the user to know how to optimize their own privacy. It's up to us to set sane defaults and educate users about what they sacrifice by deviating from that. Unfortunately, Bitcoin privacy is pretty bad and reusing addresses pretty much completely deanonamizes you. Every one you interact with can see you r entire history and balance. It's pretty atrocious. Not only that, but by doing that you damage the privacy of everyone that interacts with you. It's in everyone's best interest to discourage address reuse, especially when the software uses deterministic wallets and backups are not an issue |
|
|
|
Would it be unsafe to disable such behavior? I frequently have breaker trip on line main PC is on (which "hot" Armory is on), resulting in a rather high frequency of rescans.
Probably safe. It was in my plans for 0.91 to investigate that. It was done out extreme caution, because of risks associated with incomplete transaction histories (when the history is close enough to correct that it looks correct, but it's actually not correct). However, I suspect it can be done. |
|
|
|
There is a inefficiency with address creation.
In order to calculate address 101, you need address 100, so they have to be created in sequence.
Assuming you only have 100 addresses, then, when creating address 110, it has to calculate 101, 102 up to 110.
If you have 100 addresses and you ask for 1000 more, it will create them in the following order
Create(101), creates 101
Create(102) creates 101 and then 102
Create(103) creates 101, 102 and then 103
...
Create(1000), creates 101, 102, 103, ...., 999 and then 1000
What it should do is just run create(1000) and use the 900 addresses created. However, it loops, through create(101) to create(1000).
If you ask for 100 addresses at once, it has to calculate around 5000 addresses due to this system. If you ask for 500, then it calculates 125000 addresses.
This might be fixed in 0.9, but it means that you must ask it for addresses in short steps.
I think unlocking the wallet might help.
This has been a known issue for a while. The modularization of the code made it difficult for me to avoid the N 2 runtime for address generation -- it really wasn't that hard to fix, but I had other priorities. On that note, goatpig went ahead and fixed it in his branch, so it should appear in 0.91. |
|
|
|
Hello.
I've switched to Armory few days ago and I love all the features and the looks. But it's kind of annoying how long it takes to get it up and running.
I'm using Asus i7 laptop with 6GB RAM and Ubuntu, and when I open up Armory it takes a long while. The 'Sync with Network' part takes few minutes, but 'Bulidng Databases' goes on for aeons. I needed to do one little transaction this morning, but it took it more than an hour to get fully loaded, but then I had to leave home and turn laptop off, so my transaction still isn't made. It's really annoying.
Is it working as it should be?
Or maybe I should use feature-rich Armory as my main BTC stash, and then use something like Multibit with 0.1-0.05 BTC on it for day-to-day transactions?
The latest version of Armory will rescan the blockchain if there's an unclean shutdown. You can avoid having to do all the rescanning if you make sure to close it with the "X" in the corner, or "File"->Quit before turning off the laptop. |
|
|
|
|
Wallets created with 0.90 no long need the chaincode. It's now derived from the root key. It was determined that randomized chaincodes (and the need to backup more data) was unnecessary from a security perspective. Even Armory's root key by itself is overkill in terms of entropy.
On windows, the 32-bit version works the same as the 64-bit version, so there was no need to maintain & release separate versions anymore. You can use the posted version on either one.
|
|
|
|
Okay, mandatory 12 hour timeout. Please no more discussion on this topic. |
|
|
|
If you feel offended by my remark; it's a coward thing to defend someone on their behalf. It's pathetic. And besides, I have the right to complain and he takes it seriously, not you. Obviously you don't understand "customer service". I assume you're from India working at Customer Service department? If so then that explains.
How many open-source projects do you know that have no revenue yet offer free, one-on-one customer service? We respond to as many customer service emails as we can because we want to help people use the software. I want people to have a good experience. But we lose a lot of productivity from it -- we could get a lot more done if we didn't respond, and I don't think anyone could blame us for that. But we're here trying to help anyway. If that is unsatisfactory to you, please use the another piece of software. On that note, I just saw your email and will get back to you as soon as I can. |
|
|
|
|
As usual, some other high priority stuff jumped in front of us. But it's so close to being done, maybe CircusPeanut can spend an hour making sure that there's a commit that includes the latest armoryd.py and the refactored code that it needs. I'm pretty sure we have it, it's just a little disorganized.
|
|
|
|
|
Handling multiple source wallets for a single transaction was too complex and not common enough to support. So all transactions you sign much have all inputs from the same wallet.
|
|
|
|
|
Show Posts
