|
Blockchain.info allows you to send transactions that don't fulfill the minimum fee. If you are lucky they get confirmed within a day or two, but they may get stuck.
|
|
|
|
I have question about my private key and public key - where I can peep them in program (I can see them when I do paper backup - first 72 marks its my private key - root key, and second 72 marks is a public key - chain code, right ?)?
The root key and the chain code are not the same thing. The root key together with the chain code allows Armory to generate an essentially infinite sequence of private and public keys (this is used in ordinary wallets). The first public key together with the chain code allows Armory to generate all the public keys, but not the private ones (this is used in watch-only wallets, they only contain the public keys, so you can see the BTC but not spend them) Also when I do a digital backup my addresses are not backup? Cause why there is another options to backup my individual keys? Could you explain it to me? If I don't do a backup of my addresses I lose the money in them?
Both the digital and paper backups that Armory produces contain the root key and the chain code, so the backup protects all keys that Armory has generated in the wallet, and all keys Armory will generate in the future. The backup of "individual keys" is only for the very special case that you have manually imported keys into you wallet that are were not generated by Armory. That is a rare thing to do (and rarely a good idea). |
|
|
|
|
The Armory wallets unfortunately do not encrypt the bitcoin addresses it generates. So the value of the wallet can be seen by anyone getting hold of the file. It is rumoured that a new format is on its way which addresses this shortcoming.
By the way: The original Bitcoin client has the same problem.
|
|
|
|
I'm testing 89.99.14 on a Xubuntu system.
In the paper backup only the Root Key shows. The Chaincode is missing.
I had a hard time to understand where things should go in the Paper Backup Verify step and dearly missed an example until I realized that half of the information is missing.
You should choose one of the newer paper backup formats when you restore. One of them only has a root key, that should be the one matching newer paper backups of newer wallets (where the chain code is derived from the root key). |
|
|
|
This transition caused the entire string of transactions dependent on it to get held up for many hours, costing untold amounts of money. It seems that transactions such as this questionable one should be excluded from shared send activity, especially during periods of known high load.
While I welcome all thoughts and responses, I'm hoping for an official blockchain.info take on my observations.
I agree, such a transaction should be excluded from being reused in shared send. I have no clue if that is practically possible. NEVER use shared send or similar for time critical stuff, they do not guarantee that the money come back out quickly (indeed with the old mixed send, they mentioned that it could take a while). Instead, make an extra wallet, do a shared send to that wallet today, and then use that wallet next time you send. Also, it is unlikely that blockchain.info see you post, they are badly undermanned compared to the size of their operation (but then apart from shared send it is basically free). You should contact their support directly, that increase the chance that they see this issue. |
|
|
|
I got 3 non-confirming transactions, age 1-9 hours now. Standard fee settings. Is there anything I can do to speed things up or is there a problem with the blockchain wallet?
Unfortunately, blockchain.info sometimes make transactions without a fee, if it judges that a fee is not strictly necessary (at least the iPhone app often does that). They can take forever to confirm, I recently had one taking slightly more than two days! There is very little you can do; i had planned on waiting till in vanished from the memory pools of the net and then double-spend the coins by importing the private keys into Multibit. But fortunately it finally confirmed. For this reason I usually use the advanced setting and specify a fee myself. Imagine doing a face-to-face localbitcoin transaction and the other guy insisting to wait for the first confirmation  |
|
|
|
https://codereview.qt-project.org/#change,62937seems to have a patch that is working to solve the 10.9 Modal sessions issues on Mac. EDIT: the current build script is using a precompiled version of Qt, targeted at Mountain Lion. Maybe try building Qt from scratch (using the homebrew formula for inspiration) and adding this patch. etotheipi found that patch a few days ago. I already modified the build script to build Qt from source. Requires the git head and 2-3 patches just to compile. Unfortunately only to find out that the patch you referred to makes no difference. My guess is that the patch does not solve the actual problem, but only the symptom, and that the real trouble is elsewhere (possibly in OS X and not in Qt). |
|
|
|
|
OS X 10.9 Users:
Please disable App Nap for Bitcoin-Qt and Armory, otherwise they go to sleep as soon as their windows are covered. In particular, if Bitcoin-Qt is sleeping, Armory will not work properly.
Right-click on the app, select Get Info and disable App Nap. App Nap was introduced in OSX 10.9, so it should not be a problem on older OSX'es.
|
|
|
|
So i should keep an encrypted digital backup in hot medias and unencrypted digital backup and paper wallet on cold medias. Got it!
+1 No, +1000  |
|
|
|
Heh, ironic you mention that. Because not long ago I had it the way you just mentioned, and people were pissed off that it looked like the whole thing was starting over from scratch. Especially when they interrupted the initial DB build and restarted it. I changed it from what you just requested, due to popular demand Admittedly, maybe I can change the behavior when you're mostly synchronized already, versus in the middle of the huge DB build operation... You clearly need two progress bars One showing percent of total progress, the other showing percent of todays progress. |
|
|
|
I just looked at the site, and tried to work out how their BTC/USD futures work. Here is there description: BTC futures of 796 Exchange have, compared to the general futures, significantly improved the varieties in the concept, special BTC futures varieties are customized according to the features of and the market demand for BTC to provide the users with bilateral leverage trading services, herewith the BTC-related investment channels are greatly enriched. Floating leverage setting is applied to 796 Exchange's BTC futures, and BTC is taken as margin and pegged to US Dollars. In the event of a BTC price at USD100, going LONG is equivalent to twice the leverage whilst selling SHORT is equivalent to 4 times of the leverage; In the event of a BTC price above USD100, the leverage will be amplified in proportion accordingly; In the event of a BTC price below USD100, the leverage will be minified in proportion accordingly.
Margin for BTC futures is calculated at: 50% of long position; 25% of short position. Each time where there is a fluctuation of USD1.00 of the BTC price corresponding to 1 BTC, the volatility of gains/losses will be 0.01BTC. In case of loss up to 96% of the margin, that is, the long positions in case of a BTC price fall of USD48 or the short positions in case of a BTC price rise of USD24 will lead to margin calls, in such events, the margin of the positions in this direction will get lost. Did this make sense before it was run through Google Translate? If so, can anyone explain what it means. I would really want to see an equation that tells me how much I gain/loose by a certain movement in price (and which price is behind this). |
|
|
|
Try to forward Port 8333 in the VPN settings?
Thanks Moebius and Eternity for your suggestions! I will try that. Sometimes it works through the VPN, sometimes it doesn't. |
|
|
|
Oh, that's right... I do remember having to do some special stuff on OSX with the print dialog. But I seem to remember that it was fixed with the OSX-specific code... I guess not?
The print dialog works for me (OS X 10.9) - and at some point it started to work for me in 10.8, too. |
|
|
|
If I created a partition on the hard disk on my macbook and put the offline armoury wallet on that so that the online line + offline armoury were running on the same computer, would that work? Would that be as secure as a separate device?
Thanks for the answers so far.
(I did try searching for answers to this question but couldn't find them).
No, but it would still be significantly more secure than an online wallet. An eventual virus or trojan would need to move itself to the "offline" partition to get your password or private keys next time you boot into that partition. That is of course trivial to do, but it does require that the malware is specifically written to do just that. The mass-distributed bitcoin stealing software is less likely to pull this off. The same goes for having the "offline" wallet on a virtual machine with an encrypted disk - safer and less convenient than an ordinary online wallet, less safe but more convenient than a truly offline wallet. EDIT: The more I think about the "two partition scheme", the less I like it. It is probably a fairly standard feature of most malware writing kits to include code that infects any other partitions/disks present on the infected machine. So the bitcoin stealing malware will quickly make it to the not-so-offline partition. And since it runs on the same hardware as the online machine, the malware also has access to the network card (although it is hopefully unconfigured) and might offload the data it has stolen. |
|
|
|
There also seems to be an issue with LevelDB and OS X. Armory crashed, and could not restart, it claimed that the database was corrupted. It could start in offline mode, and I could ask it to rebuild the database, but unfortunately Armory looks at the database before rebuilding it, and it then crashes. Removing the database directory works, of course. -INFO - 1384414404: (BlockUtils.cpp:1570) SetBtcNetworkParams
-INFO - 1384414404: (BlockUtils.cpp:3580) Executing: doInitialSyncOnLoad_Rebuild
-INFO - 1384414404: (BlockUtils.cpp:3604) Number of registered addr: 998
-WARN - 1384414404: (leveldb_wrapper.cpp:31) ***LevelDB Error: Corruption: no meta-nextfile entry in descriptor
-ERROR - 1384414404: (leveldb_wrapper.cpp:168) Failed to open database! DB: 1
I suspect it is a LevelDB problem rather than an Armory problem, for Bitcoin-Qt had reported database corruption a few hours earlier, and I have also seen Bitcoin-Qt report that on my previous MacBook. EDIT: Yes, there are leveldb corruption problems: https://code.google.com/p/leveldb/issues/detail?id=197 |
|
|
|
|
When running the Satoshi client (Bitcoin-Qt) while I have VPN enabled (Mullvad), the client often does not get new blocks. It quickly gets eight connections to the network, but apparently none of them hand out any blocks. I have heard that there are many "leaching" servers by now, perhaps if I get one of them it refers me to its peers, and behind a VPN no-one else can find my client.
Is there anything I can do to avoid this?
|
|
|
|
It might have been answered before but I have a question about the "Relayed by IP" field.
I understand whatever ip address it shows has no meaning, but if it says "Relayed by IP : Blockchain.info", does it mean 100% sure that the transaction has been performed though blockchain.info's online wallet feature ?
Probably not. It could also have been performed through their API. There are websites (and probably wallets) that broadcast transactions by sending them through blockchain.info's API, I am 90% sure they also show up as relayed by blockchain.info. |
|
|
|
I've been testing it and everything works fine, only problem is that some fonts are cut (see pics below). This problem existed on my system on all previous OSX builds/versions of Armory. Did any OSX user find a fix for this?
Yes, it is somewhat annoying. It usually goes away if you grab one of the corners of the window, then it resizes. I looks like all fonts grow in size the first time the window gets focus, some windows (those with scrollbars) handle it better than others. Just an update from me, I have built most the database, it says I have about 13mins but considering how long this took, I would say about ~4 more hours. But it is going and no problems so far!
OSX 10.9
Yes, it took many hours for me too (three or four year old MacBook, OS X 10.  . But then restarting is much faster than it used to be - except that today it looks like it decided to rescan all the transactions (estimated: 30 min). Edit: That smiley was supposed to be version 10.8 |
|
|
|
Thanks for your replies. I find that absurdly expensive. The cost of 'hedging' is too high to use it.
It is indeed quite expensive! But then Bitcoin is extremely volatile, so if you hedge against a risk that risk is unusually large (hence the high price of hedging) or if you are speculating the potential gain is large. But I agree that the price has become absurd. As the price increases, the contracts become smaller and smaller (measured in BTC) while the fee stays the same. |
|
|
|
My Mac version is 10.9 . Can you help me to get armory version for mac/osx10.9 ?
I think we will have to wait for the next release before we see an installer for Mavericks. Alan is working on it. |
|
|
|
|
Show Posts
