Bitcoin Forum
February 17, 2020, 03:52:43 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 [126] 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 ... 231 »
  Print  
Author Topic: Armory - Discussion Thread  (Read 520987 times)
Sc@rF@c3
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
September 06, 2013, 06:30:07 PM
Last edit: September 08, 2013, 02:45:14 AM by Sc@rF@c3
 #2501

Armory 0.88.1, 64bit, Win7, 16GB ram, i7 1st gen.
I don't know if this has been reported
I recently deleted my wallet and restored it.

Now Armory hangs at 98% - 15 seconds every day.
A close and restart gets it working again.

I don't have debug info.

I ran the installer and repaired the installation, fingers crossed, it has not shown any errors since.
100% First Deposit Bonus Instant Withdrawals Best Odds 10+ Sports Since 2014 No KYC Asked Play Now
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1581954763
Hero Member
*
Offline Offline

Posts: 1581954763

View Profile Personal Message (Offline)

Ignore
1581954763
Reply with quote  #2

1581954763
Report to moderator
1581954763
Hero Member
*
Offline Offline

Posts: 1581954763

View Profile Personal Message (Offline)

Ignore
1581954763
Reply with quote  #2

1581954763
Report to moderator
payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
September 07, 2013, 01:43:10 AM
 #2502

Then repeat this mantra: " VMWare does not turn my PC into the computing equivalent of Doctor Who's more-capacious-on-the-inside space ship telephone booth "

haven't tried it, but when you're just talking RAM, a virtual pc should be able to have 64 GB of ram, with the vm actually having it as a file somewhere, no?

i'm aware that it would be incredibly slow
Carlton Banks
Legendary
*
Offline Offline

Activity: 2632
Merit: 2198



View Profile
September 07, 2013, 12:56:03 PM
 #2503

Then repeat this mantra: " VMWare does not turn my PC into the computing equivalent of Doctor Who's more-capacious-on-the-inside space ship telephone booth "

haven't tried it, but when you're just talking RAM, a virtual pc should be able to have 64 GB of ram, with the vm actually having it as a file somewhere, no?

i'm aware that it would be incredibly slow


I think this depends on your virtualisation software, certainly any version 8 or less VMWare software doesn't have a hypervisor swap-file scheme like this, but perhaps the newer releases do.

Vires in numeris
chrisrico
Hero Member
*****
Offline Offline

Activity: 496
Merit: 500


View Profile
September 07, 2013, 07:46:05 PM
 #2504

Then repeat this mantra: " VMWare does not turn my PC into the computing equivalent of Doctor Who's more-capacious-on-the-inside space ship telephone booth "

haven't tried it, but when you're just talking RAM, a virtual pc should be able to have 64 GB of ram, with the vm actually having it as a file somewhere, no?

i'm aware that it would be incredibly slow


When your computer needs more memory than it actually has, Windows uses a file on your hard drive as virtual memory (Unix uses a swap partition). As you state, it's incredibly slow. So no, using a VM doesn't benefit you at all.
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 07, 2013, 07:52:43 PM
 #2505

Then repeat this mantra: " VMWare does not turn my PC into the computing equivalent of Doctor Who's more-capacious-on-the-inside space ship telephone booth "

haven't tried it, but when you're just talking RAM, a virtual pc should be able to have 64 GB of ram, with the vm actually having it as a file somewhere, no?

i'm aware that it would be incredibly slow


When your computer needs more memory than it actually has, Windows uses a file on your hard drive as virtual memory (Unix uses a swap partition). As you state, it's incredibly slow. So no, using a VM doesn't benefit you at all.

I'm not 100% convinced of that.  The issue is not slowness (well, it is an issue), but that these systems may be running out of RAM.  For instance, it just can't be run on 32-bit because of the lack of address space.  But if you virtualize a system that runs 64-bit OS with 16 GB of RAM (using 14 GB of disk), it may be possible to actually run it even though it takes 3 hours to sync. 

I'd be interested to see someone try it, though I would bet 2:1 that it still doesn't work at all.  But I can see why it might work.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
chrisrico
Hero Member
*****
Offline Offline

Activity: 496
Merit: 500


View Profile
September 07, 2013, 09:41:42 PM
 #2506

I'm not 100% convinced of that.  The issue is not slowness (well, it is an issue), but that these systems may be running out of RAM.  For instance, it just can't be run on 32-bit because of the lack of address space.  But if you virtualize a system that runs 64-bit OS with 16 GB of RAM (using 14 GB of disk), it may be possible to actually run it even though it takes 3 hours to sync. 

I'd be interested to see someone try it, though I would bet 2:1 that it still doesn't work at all.  But I can see why it might work.

Can you run a 64 bit VM on 32 bit hardware? That doesn't seem right.

Anyway, the original question was whether setting up a VM would help alleviate the problem of only have 2GB of memory, as the VM could "have" 64GB. The answer is of course no. Smiley
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 07, 2013, 10:02:43 PM
 #2507

I'm not 100% convinced of that.  The issue is not slowness (well, it is an issue), but that these systems may be running out of RAM.  For instance, it just can't be run on 32-bit because of the lack of address space.  But if you virtualize a system that runs 64-bit OS with 16 GB of RAM (using 14 GB of disk), it may be possible to actually run it even though it takes 3 hours to sync. 

I'd be interested to see someone try it, though I would bet 2:1 that it still doesn't work at all.  But I can see why it might work.

Can you run a 64 bit VM on 32 bit hardware? That doesn't seem right.

Anyway, the original question was whether setting up a VM would help alleviate the problem of only have 2GB of memory, as the VM could "have" 64GB. The answer is of course no. Smiley

From stackoverflow:

Quote
You can't run a 64-bit VM session on a 32-bit processor. However, you can run a 64-bit VM session if you have a 64-bit processor but have installed a 32-bit host OS and your processor supports the right extensions.

It's my understanding that every desktop/laptop CPU under the sun is 64-bit by now, even though many people still run 32-bit OS.  So it is most likely possible to do this. 

Yes, slow as dirt.  Painfully slow.  But it might actually, eventually work, instead of seg-faulting when it hits 94%.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
September 08, 2013, 02:11:09 AM
 #2508

Bug:

Alienware laptop, 32 bit OS, Ubuntu 12.10, 16 GB ram, I7 1st gen.

Armory  0.88.1 launches fine but self crashes after about 5 minutes.
Roy Badami
Hero Member
*****
Offline Offline

Activity: 564
Merit: 500


View Profile
September 08, 2013, 12:07:23 PM
 #2509

I'm not 100% convinced of that.  The issue is not slowness (well, it is an issue), but that these systems may be running out of RAM.  For instance, it just can't be run on 32-bit because of the lack of address space.  But if you virtualize a system that runs 64-bit OS with 16 GB of RAM (using 14 GB of disk), it may be possible to actually run it even though it takes 3 hours to sync. 

I'd be interested to see someone try it, though I would bet 2:1 that it still doesn't work at all.  But I can see why it might work.

Can you run a 64 bit VM on 32 bit hardware? That doesn't seem right.

Anyway, the original question was whether setting up a VM would help alleviate the problem of only have 2GB of memory, as the VM could "have" 64GB. The answer is of course no. Smiley

From stackoverflow:

Quote
You can't run a 64-bit VM session on a 32-bit processor. However, you can run a 64-bit VM session if you have a 64-bit processor but have installed a 32-bit host OS and your processor supports the right extensions.

It's my understanding that every desktop/laptop CPU under the sun is 64-bit by now, even though many people still run 32-bit OS.  So it is most likely possible to do this. 

Yes, slow as dirt.  Painfully slow.  But it might actually, eventually work, instead of seg-faulting when it hits 94%.

There's a bit more to it than that.  To run 64-bit VMs your CPU also needs to support Intel VT (Virtualization Technology) or the AMD equivalent, and VT has to be enabled.  Most CPUs do support VT, but I believe Intel doesn't include it on some of their low-end CPUs.

But having a VT-capable CPU isn't enough - VT needs to be enabled, and this is normally done by the BIOS.  Often VT isn't enabled by default, but there is a BIOS setting to enable it.  But if your computer manufacturer chose not to provide a means of enabling VT then you may be out of luck, even if your CPU has the requisite capabilities.

roy
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 08, 2013, 04:08:49 PM
Last edit: September 08, 2013, 04:19:26 PM by etotheipi
 #2510

fsck yeah!


Balances are now pulled from the DB without rescanning!

I still have plenty left to do (like testing zero-conf tx that never touch the DB), and stop/start/restart/crash DB operations.  And of course, figure out that stupid LevelDB+Windows disaster...

(for instance, I just noticed that when you a receive a tx, it only updates the wallet, not the main ledger, and if a new block comes it that doesn't include it [yet] it disappears)

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 08, 2013, 06:21:35 PM
 #2511

Bug:

Alienware laptop, 32 bit OS, Ubuntu 12.10, 16 GB ram, I7 1st gen.

Armory  0.88.1 launches fine but self crashes after about 5 minutes.

(Cypher sent me more details over email)  That crash is happening in a location I've never seen before (isMineBulkFilter).  Can you export a log file and email that to me?  The only thing that comes to mind that would cause that is:

(1) Corrupted wallet, leading to bad address string which is crashing the code that identifies when tx belong to your wallet
(2) Malformed/corrupt blockdata in your blk*.dat files (does this happen during scanning or after scanning is done?)

I'll tell you more when I see the log file.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
September 08, 2013, 06:48:21 PM
 #2512

Bug:

Alienware laptop, 32 bit OS, Ubuntu 12.10, 16 GB ram, I7 1st gen.

Armory  0.88.1 launches fine but self crashes after about 5 minutes.

(Cypher sent me more details over email)  That crash is happening in a location I've never seen before (isMineBulkFilter).  Can you export a log file and email that to me?  The only thing that comes to mind that would cause that is:

(1) Corrupted wallet, leading to bad address string which is crashing the code that identifies when tx belong to your wallet
(2) Malformed/corrupt blockdata in your blk*.dat files (does this happen during scanning or after scanning is done?)

I'll tell you more when I see the log file.


happening after successfully scanning chain.  sent you an email.
halfawake
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500


View Profile
September 09, 2013, 03:35:55 AM
 #2513

fsck yeah!


Balances are now pulled from the DB without rescanning!

I still have plenty left to do (like testing zero-conf tx that never touch the DB), and stop/start/restart/crash DB operations.  And of course, figure out that stupid LevelDB+Windows disaster...

(for instance, I just noticed that when you a receive a tx, it only updates the wallet, not the main ledger, and if a new block comes it that doesn't include it [yet] it disappears)

You're pulling the balances from the DB now without rescanning?  That's great news, sounds like it'd be much more performance efficient than the current technique.  Good work.

BTC: 13kJEpqhkW5MnQhWLvum7N5v8LbTAhzeWj
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 09, 2013, 03:38:07 AM
 #2514

fsck yeah!
...
Balances are now pulled from the DB without rescanning!

I still have plenty left to do (like testing zero-conf tx that never touch the DB), and stop/start/restart/crash DB operations.  And of course, figure out that stupid LevelDB+Windows disaster...

(for instance, I just noticed that when you a receive a tx, it only updates the wallet, not the main ledger, and if a new block comes it that doesn't include it [yet] it disappears)

You're pulling the balances from the DB now without rescanning?  That's great news, sounds like it'd be much more performance efficient than the current technique.  Good work.

Indeed, the new design constructs a master database that hold and tracks all balances of all addresses, though it will be upgraded in the future to hold a much lighter subset of that after this version is stable.  The goal, of course, is to avoid the constant rescanning and the memory usage of the current version which stores just about nothing on disk except your wallet.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 09, 2013, 04:16:54 AM
Last edit: September 09, 2013, 05:18:03 AM by etotheipi
 #2515

Anyone in Linux want to help?  It's the ramreduceleveldb branch.   I know there's a variety of loose ends with the current implementation, but it wouldn't be a bad idea to get a few people trying it out and, especially get the database built so they'll be ready to test the more-stable version.  But there's still a ton of stuff that appears to work, and so I'd like people dig into the parts of the application that I haven't gotten to yet.  Like I just realized I've done minimal testing of importing and sweeping.  

I know that zero-confirmation transactions are a mess.   They disappear when included in a block, and only reappear on a restart (but that's pretty darned fast, now).   And the timestamps on the C++ logging (new!) are broken and spit out garbage where it would print the current time.  There may also be some infrastructure left in for "The blockchain needs to be rescanned, do you want to go offline for a few minutes to do this?", even though the "rescan" is instantaneous now.  

If you do help run/test, please take note of the following:

(1) What extra packages did you have to install?  I think libleveldb is one, which will install boost.  Looking for the minimal apt-get install packages that will fetch everything else needed to upgrade.
(2) How long does it take to build the DB?  NOTE: there's actually two steps to building the DB: one is writing the raw blocks to the DB, the other is actually walking through those blocks and updating the DB with spentness info, and building histories for each address.  The system currently does not give you any real indication that the first step is happening (though it should on the command line, if you run with --debug).  Until I fix that, it may not be obvious that anything is happening... and that first step usually takes like 45 min!  
(3) How much space does the new .armory/databases directory use?  I've seen widely different results, and I think it has to do with seemingly-random times that leveldb decides to do DB compactions.  My first test left me with an 18 GB databases dir.  A more recent had it at 25 GB.  I'm wondering how widely this varies.
(4) This is an excellent opportunity to try out the new backup center.  This version already has all the backup stuff merged, so you can try out fragmented backups and SecurePrint.
(5) Just take lots of notes.  Feel free to only use it on testnet, or use it on mainnet but run it with "--datadir=testdir" which will leave your current wallets and settings untouched.


Almost there!

EDIT:  I think I completely fixed the zero-conf transactions in the ramreduceleveldb.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 09, 2013, 04:45:22 PM
 #2516

Update:

the new version of Armory seems to run flawlessly on testnet.  I accidentally deleted my mainnet database when trying to delete the testnet database, so I have to rebuild before I can do any testing on mainnet.   But so far, I don't see anything that doesn't work.  But there's also so many little nooks and crannies, there's no way I can test everything exhaustively.  Help me out!

Reminder: poor interface-user communication:  there's actually two steps to building the DB: one is writing the raw blocks to the DB, the other is actually walking through those blocks and updating the DB with spentness info.  The system currently does not give you any real indication that the first step is happening (though it should on the command line, if you run with --debug).  Until I fix that, it may not be obvious that anything is happening... and that first step usually takes like 45 min!  After that, you should get a fairly accurate progress bar in the GUI for the next 3-4 hours of updating the DB.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
September 09, 2013, 07:17:34 PM
 #2517

I built the ramreduceleveldb branch, and I started it on mainnet with --debug, and I still don't see any indication that something is happening. It's completed the initial blockchain scan, and there is no ~/.armory/databases directory yet.
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 09, 2013, 07:20:49 PM
 #2518

I built the ramreduceleveldb branch, and I started it on mainnet with --debug, and I still don't see any indication that something is happening. It's completed the initial blockchain scan, and there is no ~/.armory/databases directory yet.

The log file you sent indicates you're still on version 0.88.2.  But if you were on the ramreduceleveldb branch, it would say 0.89.95.

After battling multiple issues destroying mainnet DB (all user error), I did notice that a bunch of my wallet balances were totally wrong on mainnet, but not testnet (frequently reporting "total received", not "current balance").   I confirmed that the DB actually has the correct data, and the GUI just happens to be reading it incorrectly.  Not sure why I'm not seeing the problem on testnet, but at least it'll be easier than tracking down a DB error...

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
September 09, 2013, 07:31:20 PM
 #2519

ARGH.  I somehow reverted one armorymodels.py to the pre-leveldb version.   Just about to commit the fixed version to the ramreduceleveldb branch.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
superbit
Hero Member
*****
Offline Offline

Activity: 763
Merit: 500



View Profile
September 09, 2013, 07:42:50 PM
 #2520

When I loaded armory this AM, it said it detected a corrupt block in the blockchain.

I closed armory, opened bitcoin 0.8.4 and it offered to repair the chain.  I let this run through and it completed giving me the green checkmark in the bottom right corner.  Then as soon as I went back into armory I got the same error, now I go back into the bitcoin client and it is starting the repair again??

I really need to send coins in my armory wallet out today, what can I do to end this loop?

https://bitfinex.com/?refcode=UInJLQ5KpA <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with the refcode
My feedback thread: Forum thread
Pages: « 1 ... 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 [126] 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 ... 231 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!