Bitcoin Forum
March 19, 2024, 11:50:32 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 [54] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 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 ... 231 »
  Print  
Author Topic: Armory - Discussion Thread  (Read 521670 times)
Kluge
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1015



View Profile
August 01, 2012, 10:29:02 AM
 #1061

A bit OT... Anyone know how to export watch-only addresses from Armory, and get them into Blockchain.info or the Bitcoin Wallet Watcher app for Android? With Blockchain.info, I am able to import addresses one at a time, but I don't have a week to spend copy/pasting addresses one-by-one, and can't find a bulk import option, less "Import Backup," which I can't figure out how to paste a load of of watch-only addresses into. I've tried just the address strings, just public keys, and strings with public keys -- pasting any of those into Blockchain.info returns "Cannot Decode Import Data," and the Android app returns "0<=size"
1710849032
Hero Member
*
Offline Offline

Posts: 1710849032

View Profile Personal Message (Offline)

Ignore
1710849032
Reply with quote  #2

1710849032
Report to moderator
1710849032
Hero Member
*
Offline Offline

Posts: 1710849032

View Profile Personal Message (Offline)

Ignore
1710849032
Reply with quote  #2

1710849032
Report to moderator
1710849032
Hero Member
*
Offline Offline

Posts: 1710849032

View Profile Personal Message (Offline)

Ignore
1710849032
Reply with quote  #2

1710849032
Report to moderator
The block chain is the main innovation of Bitcoin. It is the first distributed timestamping system.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
etotheipi (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 01, 2012, 10:48:21 AM
Last edit: August 01, 2012, 02:05:58 PM by etotheipi
 #1062

A bit OT... Anyone know how to export watch-only addresses from Armory, and get them into Blockchain.info or the Bitcoin Wallet Watcher app for Android? With Blockchain.info, I am able to import addresses one at a time, but I don't have a week to spend copy/pasting addresses one-by-one, and can't find a bulk import option, less "Import Backup," which I can't figure out how to paste a load of of watch-only addresses into. I've tried just the address strings, just public keys, and strings with public keys -- pasting any of those into Blockchain.info returns "Cannot Decode Import Data," and the Android app returns "0<=size"

I have not done this myself, but I suspect it may have to do with the formatting of the keys.  For one, Armory displays private and public keys with a space between every quad of hex characters, which is done for ease of copying/typing by hand, but not necessarily handled by other applications (actually, it's probably not).  Second, for public keys, they are usually serialized slightly differently.  Armory displays this:

Quote
  PublicX   : 94bb ad39 3082 eb3d 82c3 2ef5 59d8 9528 a46d f6a5 f711 ea07 36b9 3441 a182 51a5
   PublicY   : e9c2 ea48 55de 4b62 a19d cc84 8ce7 18a4 0224 797c c6e3 8190 622d d2a9 ebbf 5e8f

But most applications would use the concatenated version with "04" prefix byte  (and without the spaces between):

Quote
04 94bb ad39 3082 eb3d 82c3 2ef5 59d8 9528 a46d f6a5 f711 ea07 36b9 3441 a182 51a5 e9c2 ea48 55de 4b62 a19d cc84 8ce7 18a4 0224 797c c6e3 8190 622d d2a9 ebbf 5e8f

This wasn't done to be confusing:  it was done because this display is much cleaner and I didn't expect anyone to really use it for anything (and if they did, I expected they might already know what to do with it).  But as I write this, I realize I should add a checkbox for "Raw Public Key" which gives you exactly what other apps would expect.  

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!)
dooglus
Legendary
*
Offline Offline

Activity: 2940
Merit: 1327



View Profile
August 01, 2012, 05:36:40 PM
 #1063

I think the following might fix the crash:

Code:
diff --git a/cppForSwig/BlockUtils.cpp b/cppForSwig/BlockUtils.cpp
index 2b08f5e..bf270bf 100644
--- a/cppForSwig/BlockUtils.cpp
+++ b/cppForSwig/BlockUtils.cpp
@@ -2535,6 +2535,7 @@ uint32_t BlockDataManager_FileRefs::parseEntireBlockchain( string   blkdir,
             bsb.reader().advance(nextBlkSize);
          }
       }
+      globalCache.openFile(fnum-1, blkfile);
       TIMER_STOP("ScanBlockchain");
 
    }

Since adding that line to the code I've had no further crashes.  I'm pretty sure that fixes the bug.  There's probably a more efficient way to get the same result than re-opening all the blockchain files, but at least I've found the problem now.

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
etotheipi (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 01, 2012, 09:57:16 PM
 #1064

I think the following might fix the crash:

Code:
diff --git a/cppForSwig/BlockUtils.cpp b/cppForSwig/BlockUtils.cpp
index 2b08f5e..bf270bf 100644
--- a/cppForSwig/BlockUtils.cpp
+++ b/cppForSwig/BlockUtils.cpp
@@ -2535,6 +2535,7 @@ uint32_t BlockDataManager_FileRefs::parseEntireBlockchain( string   blkdir,
             bsb.reader().advance(nextBlkSize);
          }
       }
+      globalCache.openFile(fnum-1, blkfile);
       TIMER_STOP("ScanBlockchain");
 
    }

Since adding that line to the code I've had no further crashes.  I'm pretty sure that fixes the bug.  There's probably a more efficient way to get the same result than re-opening all the blockchain files, but at least I've found the problem now.

Dooglus,

You are very resourceful, thanks for helping debug the code while I'm on vacation!  I still don't fully understand the issue (and why that line of code fixed it), but it's not a bad thing to reopen the file just before scanning.  As it was before, blk0002.dat was being opened before blk0001.dat was scanned.  Your line reopens the file just before it is scanned (and I could see why that's a good thing).  The first thing I do when I get back is I'll put that fix into 0.82.1 and commit it.  And then I'll release 0.82.1 because it's about time...

Seriously, thanks for helping me with this!  I've been stressed that issues like this are cropping up and I've had no time to deal with it!


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!)
zveda2000
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
August 03, 2012, 10:09:42 AM
 #1065

The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.
etotheipi (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 03, 2012, 11:57:17 AM
 #1066

The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.

You can't resize the window?  Are there windows that can't be made small enough?  For a while, this was an issue and I thought I had fixed it.  But I guess not. 

Let me know what windows are problematic, I'll be sure to make the resizing & layouts more flexible.

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!)
fabrizziop
Hero Member
*****
Offline Offline

Activity: 506
Merit: 500



View Profile
August 03, 2012, 01:40:03 PM
 #1067

Hey, just a suggestion, it would be nice to create an armory wallet watcher for Android.
LuaKT
Member
**
Offline Offline

Activity: 162
Merit: 10


The World’s First Blockchain Core


View Profile
August 03, 2012, 02:12:39 PM
 #1068

Hi,

Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.

Any ideas?

Thanks

▄▄▄▄▄▄▄▄▄▄▄ ▄ ■        SKYNET        ■ ▄ ▄▄▄▄▄▄▄▄▄▄▄
▐▬▬▬▬▬▬▬▬▬▬     PRIVATE SALE is LIVE     ▬▬▬▬▬▬▬▬▬▬▌
Whitepaper   Bounty   Bitcointalk  ■  Facebook   Twitter   Telegram
dooglus
Legendary
*
Offline Offline

Activity: 2940
Merit: 1327



View Profile
August 03, 2012, 04:56:54 PM
 #1069

Dooglus,

You are very resourceful, thanks for helping debug the code while I'm on vacation!  I still don't fully understand the issue (and why that line of code fixed it), but it's not a bad thing to reopen the file just before scanning.  As it was before, blk0002.dat was being opened before blk0001.dat was scanned.  Your line reopens the file just before it is scanned (and I could see why that's a good thing).  The first thing I do when I get back is I'll put that fix into 0.82.1 and commit it.  And then I'll release 0.82.1 because it's about time...

Seriously, thanks for helping me with this!  I've been stressed that issues like this are cropping up and I've had no time to deal with it!

You're welcome.

Actually the change as you describe it is not what I intended.  I meant to reopen each file after it was scanned, not before.  Isn't that what my change does?

All I'm aiming to do is to have the fileSizes_ array contain the sizes as they were actually read, not the sizes as they happened to be when the files were originally opened.  Because when the stored filesizes value is smaller than the amount that was actually read, that's when the crash happens.

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
etotheipi (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 04, 2012, 08:08:46 AM
 #1070

Hi,

Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.

Any ideas?

Thanks

You are the second person to report this problem.  It's strange that the SelectCoins code has been in use for 8 months and there's never been a hint of a problem with it, but suddenly multiple people run into this! 

The other person who reported this sent me their wallet so I can debug it.  I will dig into it tonight, and hopefully have a fix for 0.82.2, which will be an official release this week. 

The other user was using a wallet that had tons of inputs, and attempting to move the entire balance in one tx, which would require a large tx fee.  As such, I recommend you compute your total balance minus the requested tx fee, and put that in directly and change the fee directly to the recommended fee.  There may be an issue with the fee calculation when there's dozens of inputs, but if you give it the correct answer to start it may not have an issue.

Let me know.  This seems like a serious issue and I will be attending to it right away!

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!)
OneEyed
aka aurele
Full Member
***
Offline Offline

Activity: 154
Merit: 100



View Profile WWW
August 04, 2012, 09:12:06 AM
 #1071

You are the second person to report this problem.  It's strange that the SelectCoins code has been in use for 8 months and there's never been a hint of a problem with it, but suddenly multiple people run into this!

Make me the third one. I sometimes see this problem after I accept to add a fee to a transaction, but had no chance to properly report it.

LuaKT
Member
**
Offline Offline

Activity: 162
Merit: 10


The World’s First Blockchain Core


View Profile
August 04, 2012, 10:41:42 AM
 #1072

Hi,

Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.

Any ideas?

Thanks

You are the second person to report this problem.  It's strange that the SelectCoins code has been in use for 8 months and there's never been a hint of a problem with it, but suddenly multiple people run into this! 

The other person who reported this sent me their wallet so I can debug it.  I will dig into it tonight, and hopefully have a fix for 0.82.2, which will be an official release this week. 

The other user was using a wallet that had tons of inputs, and attempting to move the entire balance in one tx, which would require a large tx fee.  As such, I recommend you compute your total balance minus the requested tx fee, and put that in directly and change the fee directly to the recommended fee.  There may be an issue with the fee calculation when there's dozens of inputs, but if you give it the correct answer to start it may not have an issue.

Let me know.  This seems like a serious issue and I will be attending to it right away!


I've just tried again to send the payment and it worked no problem.

For the record I was trying to send BTC0.1 with a BTC0.0005 transaction fee from a wallet with BTC13.

Thanks

▄▄▄▄▄▄▄▄▄▄▄ ▄ ■        SKYNET        ■ ▄ ▄▄▄▄▄▄▄▄▄▄▄
▐▬▬▬▬▬▬▬▬▬▬     PRIVATE SALE is LIVE     ▬▬▬▬▬▬▬▬▬▬▌
Whitepaper   Bounty   Bitcointalk  ■  Facebook   Twitter   Telegram
SimonL
Member
**
Offline Offline

Activity: 113
Merit: 11


View Profile
August 05, 2012, 07:16:20 AM
 #1073

The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.

You can't resize the window?  Are there windows that can't be made small enough?  For a while, this was an issue and I thought I had fixed it.  But I guess not. 

Let me know what windows are problematic, I'll be sure to make the resizing & layouts more flexible.

I've also found the "Transaction Info" window can't be resized, makes it very difficult to see all the outputs for a transaction. Having this window resizeable would be great.
etotheipi (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 05, 2012, 01:21:37 PM
 #1074

The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.

You can't resize the window?  Are there windows that can't be made small enough?  For a while, this was an issue and I thought I had fixed it.  But I guess not. 

Let me know what windows are problematic, I'll be sure to make the resizing & layouts more flexible.

I've also found the "Transaction Info" window can't be resized, makes it very difficult to see all the outputs for a transaction. Having this window resizeable would be great.

Alright, I'll spend some time playing with Armory in a VM with 1024x600 resolution.  I'm sure the issues will pop out.

I just got home from my vacation, and though my work-work is still going to be kind of intense, I will finally have some time to do real development again!  The first thing will be to dig into the SelectCoins problem with the watching-only wallet I have.  I will also inject Dooglus' blockchain utilities fix.  I don't think it's going to fix the periodic crashes (once Armory is running), but it should make sure the scan works.  Then I will release 0.82.2.

FYI -- while I had downtime on vacation, I started playing around with LevelDB.  I think I decided that changing the engine to maintain its own blockchain using leveldb is not only going to be extremely useful, but not terribly difficult either (the last round of blockchain engine updates properly modularized the blockchain management from the rest of the program). 

--First and foremost, all these crashing issues can go away: I'm pretty sure they're related to "hacking" my way through the blk000X.dat files which are being maintained by another process out of my control (that's not to say I did it right or that it can't work, but it seems like an unnecessary situation). 
--This also will allow users to connected to any full node, as long as it is 100% trusted -- it doesn't have to be localhost.  The downside is, if it is localhost, you'll be maintaining two copies of the blockchain.
--Start times will be near instantaneous -- as long as I'm storing blockchain data, I can easily store between-load information
--The new utilities will be designed with blockchain pruning in mind (my pruning method in particular, but any method that cares about separating out unspent TxOuts and possibly removing everything else).  I don't plan to implement pruning yet, but I've already figured out how I can organize the data such that it will be minimal engine modifications to implement lightweight nodes and pruned nodes.
--Faster!  The benchmarks I ran showed that a full scan can be done in like 15s even on a non-SSD.  Granted, that's when much of the file is cached by the OS already -- but it's still faster than what I've got right now which also should benefit from OS caching.

I know I keep pushing back beta -- but it's for a good reason:  I think Beta is going to get a lot of attention, and I don't want 5 minute load-times and 700 MB RAM usage to be the focal point of the discussions/reviews.  I think I can get all this implemented in a couple weeks, then a couple more weeks of testing.  Then a few of Armory's achilles heels will be gone!







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!)
OneEyed
aka aurele
Full Member
***
Offline Offline

Activity: 154
Merit: 100



View Profile WWW
August 05, 2012, 02:22:10 PM
 #1075

FYI -- while I had downtime on vacation, I started playing around with LevelDB.  I think I decided that changing the engine to maintain its own blockchain using leveldb is not only going to be extremely useful, but not terribly difficult either (the last round of blockchain engine updates properly modularized the blockchain management from the rest of the program). 

--First and foremost, all these crashing issues can go away: I'm pretty sure they're related to "hacking" my way through the blk000X.dat files which are being maintained by another process out of my control (that's not to say I did it right or that it can't work, but it seems like an unnecessary situation). 
--This also will allow users to connected to any full node, as long as it is 100% trusted -- it doesn't have to be localhost.  The downside is, if it is localhost, you'll be maintaining two copies of the blockchain.

That seems like an important downside to me. If you are going to store the blockchain data, can't you replace bitcoind by incorporating the networking code directly into Armory? Once you handle the blockchain in armory, it makes little sense to keep a copy of the blockchain in bitcoind, since it will have no use.

--Faster!  The benchmarks I ran showed that a full scan can be done in like 15s even on a non-SSD.  Granted, that's when much of the file is cached by the OS already -- but it's still faster than what I've got right now which also should benefit from OS caching.


The benchmark with cached data has no meaning. People don't stop and start armory all the time, the empty-cache case is the interesting one.

I know I keep pushing back beta -- but it's for a good reason:  I think Beta is going to get a lot of attention, and I don't want 5 minute load-times and 700 MB RAM usage to be the focal point of the discussions/reviews.  I think I can get all this implemented in a couple weeks, then a couple more weeks of testing.  Then a few of Armory's achilles heels will be gone!

Well, right now, one of the strong points in Armory is that it takes only 700k extra data in my home directory. If it now takes 3.1G (as bitcoind does), that's bad. And I'd be interested in looking at the cold cache startup time, as this is the one that will appear in benchmarks.

etotheipi (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 05, 2012, 04:17:04 PM
 #1076

OneEyed, thanks for the feedback on this.   Admittedly, I hadn't considered all the other perspectives on the changes I proposed.  I know what I want out of Armory, but that is frequently at odds with others (who use it in different ways than me).  

If you are going to store the blockchain data, can't you replace bitcoind by incorporating the networking code directly into Armory? Once you handle the blockchain in armory, it makes little sense to keep a copy of the blockchain in bitcoind, since it will have no use.

That's a hell of a "can't you?" statement.  It could take me months to implement the networking protocol, and in the end, Armory would end up worse off (with a buggy, security-untested networking engine).  However, this is one steps towards that Armory-full-node goal, which may include cannabilizing another networking engine (maybe directly from bitcoind) to integrate into Armory (which is still a hardcore modification of the software).  So, there is a transient period where both processes would need it.  On the other hand:

  • RAM usage is going to become nil.  Relying entirely on a disk-based DB engine means that it will work well on systems with lot of RAM that can do lots of caching, but it won't need it.
  • You will be able to connect to any (trusted) full node, just not localhost and not just bitcoind/-qt.  That means you could have one bitcoind on your network, and all your systems can connect to it.  
  • This paves the way for making a lite-version of Armory which doesn't need the full blockchain at all.  i.e. you can run your full bitcoind/-qt and Armory will only get the wallet-relevant information it needs.  It wouldn't actually copy the entire blockchain.  This isn't ready yet, but it's most definitely on my path to verison 1.0.  The end result would be a lot more stability and flexibility, with pretty much the same disk usage as right now.
  • Although I don't really like the idea much, it would be possible for people to start services supplying the trusted full node for you.
  • This paves the way for pruned-full-node and/or pruned-lite-node Armory, and implementing my own version of Ultimate Blockchain compression.  If this eventually gets me to a system like that, then everyone wins.

The benchmark with cached data has no meaning. People don't stop and start armory all the time, the empty-cache case is the interesting one.
...
Well, right now, one of the strong points in Armory is that it takes only 700k extra data in my home directory. If it now takes 3.1G (as bitcoind does), that's bad. And I'd be interested in looking at the cold cache startup time, as this is the one that will appear in benchmarks.

There's two things you missed here:
(1) Users would no longer be reading the entire blockchain on start. They'd be reading a tiny database that would load instantly.  This scan time would only be relevant on first load (ever) and re-scans when importing addresses/wallets.
(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot.  The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).  


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 (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 05, 2012, 04:22:18 PM
 #1077

Hey, just a suggestion, it would be nice to create an armory wallet watcher for Android.

Yes!  This is in my plans.  I was hoping to implement multi-sig and then create an android app that lets you use your phone as a two-factor authentication device.  However, a lot of other priorities have come up, and the wallet file needs to be upgraded, so I haven't been able to pursue this just yet.  But I will!  It was intended to be one of the core Armory features!

You're welcome.

Actually the change as you describe it is not what I intended.  I meant to reopen each file after it was scanned, not before.  Isn't that what my change does?

All I'm aiming to do is to have the fileSizes_ array contain the sizes as they were actually read, not the sizes as they happened to be when the files were originally opened.  Because when the stored filesizes value is smaller than the amount that was actually read, that's when the crash happens.

Oh I must've misread the patch you posted.  And I must've misunderstood how the file reading/opening works.  I thought that even if the file changed size, that once it's open for reading it would be limited to that size until you explicitly reload it.  And because I wasn't sure about that, I stored/used the file sizes when it opened to try to avoid exactly what you said it's doing.  But clearly I botched something...

I just got back from vacation, and I need to get my life back into order.  But I'll be digging in hard, soon!

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!)
OneEyed
aka aurele
Full Member
***
Offline Offline

Activity: 154
Merit: 100



View Profile WWW
August 05, 2012, 04:37:47 PM
 #1078

(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot.  The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).  

Caching does not hold between boots at all. But by dropping the caches using drop_caches, you are also probably dropping a lot of pages belonging to the libc and other shared libraries, which puts you into a worse situation than when running armory for the first time after boot if other applications have been started before it: those applications have probably already loaded some of the shared libraries pages you will need.

etotheipi (OP)
Legendary
*
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 05, 2012, 04:55:49 PM
 #1079

(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot.  The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).  

Caching does not hold between boots at all. But by dropping the caches using drop_caches, you are also probably dropping a lot of pages belonging to the libc and other shared libraries, which puts you into a worse situation than when running armory for the first time after boot if other applications have been started before it: those applications have probably already loaded some of the shared libraries pages you will need.


Okay.  Then at worst, it runs at the same speed as the current Armory utilities in Linux, and twice as fast once it's been cached.  I'll have to do the same tests on a native Windows system.

I figured, maybe the system remembers what files you access frequently and pre-caches them on load.  I guess not...

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!)
OneEyed
aka aurele
Full Member
***
Offline Offline

Activity: 154
Merit: 100



View Profile WWW
August 05, 2012, 05:29:15 PM
 #1080

I figured, maybe the system remembers what files you access frequently and pre-caches them on load.  I guess not...

It can, if you use something like preload (but it is not the Linux kernel itself that does that).

Pages: « 1 ... 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 [54] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 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 ... 231 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!