|
Extend the address chain for that wallet, it should recompute the highest used address index.
|
|
|
|
Armory 0.93 does not work for me, I though it was due to Armory being on a fuse NTFS partition on Debian ( thread), but even on an ext4 partition it fails to sync and also fails at building the database  . Force your bitcoin folder with --satoshi-datadir, the path auto detect is failing somehow. |
|
|
|
Goatpig,
Thanks for introducing me to testnet coins. I didn't know valueless Bitcoins existed for the purpose of testing. My question to you or anyone in this forum is whether or not it is possible to be scammed with testnet coins. Lets say I purchase 20 bitcoins from some fellow living in Alaska and I live in New York. Is there any way possible the fellow in Alaska can scam me by sending me 20 testnet bitcoins and not real Bitcoins? I'm asking this because I am a newbie and I would like to learn how to tell the difference from Testnet coins and Bitcoins and avoid possibly getting scammed. Any comments welcome.
Testnet and mainnet are 2 independent networks with separate magic words and chains. Testnet addresses are not valid on mainnet and vice versa. The addresses don't even starts with the same prefix (1 for mainnet, n and m for testnet) Also, to receive payments, you have to provide the payer with an address first. Unless you give them a testnet address and expect testnet coins, you won't be getting any testnet coins. |
|
|
|
nvm, fixed.
when is the 0.93 update going to work with my OS?
You mean the 32bit part or the 12.04 part? We got some fixes incoming soon that will get Armory going again on 12.04 among other things. For x86 support you'll have to wait for the next subversion. |
|
|
|
why is my blockchain stuck?
still with Armory 0.92.3 and Bitcoin Core 0.9.3 in Ubuntu 12.04 LTS 32 bit.
Care to elaborate? |
|
|
|
The latest version has memory leaks, badly. It consume 15.8 GB of my 16 GB Windows memory, every time.
What's Armory's RAM usage? I think you are confusing RAM used by the process and in use memory pages. The OS won't shy away from filling that up when a lot of access is performed on mmap'ed files, which will happen a lot during a DB scan. That doesn't mean the RAM is in use, it means the OS is chugging unused RAM to shuffle file data in and out of it. If a process was to ask for more RAM it would get priority over this memory. The OS has no reason to empty this memory once Armory is done scanning. For all it knows, Armory just asked for intensive access to this data, so the OS expects it will again. Unless other processes start asking for more RAM or Armory is closed, the OS will keep these unused pages filled with the DB's mmap'ed files. I think you are correct. It's probably not a memory leak, ArmoryQt itself only uses 300M, on top of bitcoind's 500M. However it's still scary to see so much memory being mmap'd, rarely have I seen this before. Thanks for pointing that out. If you restart Armory it shouldn't be mmap'ing as much memory. Next version will be a lot tamer on that front, and I also may just close and reopen the DB just to flush out the mmap data after the scan is over. For now you'll have to deal with the scary numbers =P |
|
|
|
The latest version has memory leaks, badly. It consume 15.8 GB of my 16 GB Windows memory, every time.
What's Armory's RAM usage? I think you are confusing RAM used by the process and in use memory pages. The OS won't shy away from filling that up when a lot of access is performed on mmap'ed files, which will happen a lot during a DB scan. That doesn't mean the RAM is in use, it means the OS is chugging unused RAM to shuffle file data in and out of it. If a process was to ask for more RAM it would get priority over this memory. The OS has no reason to empty this memory once Armory is done scanning. For all it knows, Armory just asked for intensive access to this data, so the OS expects it will again. Unless other processes start asking for more RAM or Armory is closed, the OS will keep these unused pages filled with the DB's mmap'ed files. |
|
|
|
Yes. I am using 32 Bit version of Ubuntu.
Then, can I continue using the 0.9.2.3?
How can export armory's wallet to another computer with a 64 bit version and then install the 0.93 version?
Thank you very much for your help.
You should stick to 0.92.3 if you intent to use a x86 OS to get Armory online with. To export wallets you have to use the Backup tool with each of your wallets. Go to the Properties dialog of each one of your wallet and pick "Backup This Wallet" (or "Export Watching-only Data" if it's a WO) from the left side menu. Then use the import tool on your other instance of Armory (top left corner button on the main lobby) |
|
|
|
While I cannot get it to CRASH from scratch, both the fresh startup with no DBs and subsequent startups all do the same thing 100%: They build the DB in "silence" with the status part of the UI unresponsive, then, at some point during the Armory DB building part, they stop progressing for no apparent reason around 19-20GB size, while the disk activity continues to be intense. Once they reach that, they stay there indefinetly. Subsequent restarts of the app will show Armory catch up with the extra few blocks that popped up on the network during that time, but once they get back to building the Armory DB they again stop and they remain that way, best I've checked, for at least 6 hours. Since the initial 20GB are built in less than 2 hours, I doubt the remaining 9GB of Armory DB are actually taking that long.
The other thing to point out, again with 100% occurrence, is closing the Armory once it is in this state. The UI says a big "Preparing to shut down" on the main page, but remains stuck at that stage while still using the HDD. It takes a second go to the File -> Quit Armory for it to close, and then it does it in a few seconds. Usually when an app cannot shut down it doesn't "try harder" the second time you ask it, it either eventually does it from the initial command or it doesn't at all and has to be killed through forced end task, but in this case Armory actually requires me to issue the Quit Armory option twice in order to close.
I have checked my task manager and can find no phantom armory/bitcoind/guardian processes, so it's also not the case of a previous lingering process. I really am confused.
Ok so, do the original thing I asked for: wipe your log files and database folder on either of your machines, let it start fresh all the way up to the point where it gets stuck. Then kill the process and give me the logs. I think that'll yield some interesting data. |
|
|
|
|
Machine Arch : i686
Are you using a 32 bit version of Ubuntu? 0.93 doesnt support x86 anymore. You have to wait for 0.93.1 for the revived x86 support
|
|
|
|
No, they each downloaded the blockchain independently from scratch. I don't know if I can replicate that crash, it was a one-off oddity. It had run for 24h+ building the blockchain then armory db without a single crash and I restarted it repeatedly, it crashed once then didn't when I relaunched it. I'll see what I can do. Since you're only asking questions despite seeing both machines' logs I'm guessing the logs were of no help?
The logs don't have the one good hint I was hoping for. On the other hand I didn't pick that the error is not deterministic at first. That's an interesting point on its own. I was under the impression the error was occurring 100% under the "right" conditions, which is why I hoped a fresh log + fresh db folder would really outline the exact error. Have you seen any pattern in the bug appearance? What would you say is the failure to success ratio? If you can't get it to fail when it's starting from scratch then just report it and that's about it. I'll have to get my clue from some other vector. |
|
|
|
Ok, what about this then: Same copy of the blockchain on both machines?
Also, pick whatever machine, delete the databases folder and the log files, start Armory and let it run till it crashes, then post the fresh logs. |
|
|
|
|
Sweet baby jebus.
This log file is too big already, I can't make much sense of it. Sorry for you wasted effort but I'll have to redo this:
1) Delete your log files. You'll find them here: /home/yo/.armory/databases
Delete both armorylog.txt and armorylogcpp.txt
2) Start Armory, let it run until it fails
3) Grab those 2 fresh log files and post them on pastebin and post the links here.
|
|
|
|
--datadir=E:\Program Files (x86)\Armory\Data_Armory Is this your "system" program files? Can't have the datadir in a restricted folder EDIT: Laptop now also got stuck with a 20.0GB Data_Armory folder. That's two different machines.
Same copy of the blockchain on both machines? Can I see the other log file? |
|
|
|
I don't know if this has already been brought to developers' attention, but here: When signing a tx (from simulfunding, or any unsigned tx really), occasionally it fails and returns this lovely message in the log: 2015-02-24 15:27 (ERROR) -- Traceback (most recent call last):
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/MultiSigDialogs.py", line 2716, in doSign
self.doSignForInput(idstring, nIdx)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/MultiSigDialogs.py", line 2936, in doSignForInput
ustxi.createAndInsertSignature(pytx, addrObj.binPrivKey32_Plain)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/Transaction.py", line 1275, in createAndInsertSignature
derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/Transaction.py", line 1235, in createTxSignature
raise SignatureError('No PubKey that matches this privKey')
SignatureError: No PubKey that matches this privKey
This doesn't happen often but I thought I'd report it anyway We're aware of this one. Didn't work a fix for 0.93 but will most likely have one for .1 |
|
|
|
Thanks to all who posted in my thread. I seem to be getting conflicting information. Therefore, I think the best thing to do is to experiment using both techniques and learn for myself what is the best approach to moving bitcoins stored in Coinbase.com / Blockchain.info / Circle.com over to Armory cold storage on my offline PC. Thanks again for all of your comments.
If you're going to experiment, consider Testnet. |
|
|
|
I'm assuming I shouldn't be seeing the "Armory is incompatible with Bitcoin Core 0.10+" message in the announcements tab of the dashboard - given that I'm running 0.93 release :-)
It's under the heading "All available notifications" - not sure if that's supposed to mean that it includes notifications that don't apply to me (but if this really is the intended behaviour then may I respectfully suggest that you reconsider your UI design here)
roy
The annoucement/downloader is kind of all over the place right now, sorry about that. I think what you are getting a version agnostic warning about Core 0.10 when it was only meant to hit 0.92.3 and earlier. We'll get it under control eventually. |
|
|
|
|
Show Posts
