|
FYI, I have been too swamped with work-work and keeping Armory from breaking under the increased blockchain load to spend too much time on this specific proposal. I have not lost interest by any means, I just need to catch my breath after some big deadlines. Then I'll be taking some time off to work explicitly on some Bitcoin stuff... including this proposal.
I'm going to spend some time in the near future looking at space efficiency of a couple variants of the trie data-structure. I'm not sure exactly how this theoretical datastructure can be merged with a disk-based DB engine (I imagine that what I have in mind is not used by an existing, acceptable DB engine) but maybe there's a way to make a hybrid. This is a problem that still needs to be resolved before we can move forward with an implementation: Once we agree on a datastructure, how do we use it but avoid re-inventing the wheel in terms of robust, scalable disk-based database engines?
The more I've been thinking about it, the more I have become convinced that a trie-like structure is necessary. Note only are query and insert times are constant, the determinism of tree structure for a given set of tree nodes means that queries and inserts can be parallelized. For instance, the tree could be implemented with the first layer (the first 256 nodes of a 256-way trie) split into a different files/DBs/processes/servers for each branch. Then every new piece can be distributed and queued for its particular destination. It could even be distributed amongst different, independent servers. This seems to be advantageous.
For reference, I learned of this particular tree in my data structures class in college, but I find no reference that anyone else has ever heard of it. In my class it was called a "De La Brandia Tree/Trie". A Patricia tree is a level-compressed trie. A "de la brandia tree" is a Patricia tree that uses a linked-list of pointers, instead of a constant-size array. i.e. -- in a 256-way trie or patricia tree, each branch node contains 256 pointers (8 bytes each), which could point to other nodes. However, the sparseness of lower-level nodes means that the nodes will frequently have 255 null pointers, with only one relevant pointer. The de-la-brandia tree will represent all child pointers with an ordered linked list. It has some extra overhead for nodes that have mostly-full child lists, but it I think such near-full nodes will be tiny compared to the amount of space saved on sparse nodes.
When I get some more time, I'll make some pictures, and update the original post with the updated proposal.
|
|
|
|
I just had another crash while running the satoshidice armory code. This time it happened much earlier on, while parsing the blockchain: Opening file 1: /home/chris/.bitcoin//blk0001.dat
Opening file 2: /home/chris/.bitcoin//blk0002.dat
Highest blkXXXX.dat file: 2
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0001.dat
/home/chris/.bitcoin//blk0001.dat is 2000.15 MB
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0002.dat
/home/chris/.bitcoin//blk0002.dat is 210.012 MB
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff54a9262 in CryptoPP::X86_SHA256_HashBlocks (state=0x7ffff585a830, data=0x0, len=256) at sha.cpp:435
435 );
(gdb) where
#0 0x00007ffff54a9262 in CryptoPP::X86_SHA256_HashBlocks (state=0x7ffff585a830, data=0x0, len=256) at sha.cpp:435
#1 0x00007ffff54aa2f4 in CryptoPP::SHA256::HashMultipleBlocks (this=<optimized out>, input=<optimized out>, length=258) at sha.cpp:453
#2 0x00007ffff5484cc7 in CryptoPP::IteratedHashBase<unsigned int, CryptoPP::HashTransformation>::Update (this=0x7ffff585a7c0, input=0x0, len=258)
at iterhash.cpp:55
#3 0x00007ffff53d150c in BtcUtils::getHash256(unsigned char const*, unsigned int) () from ../_CppBlockUtils.so
#4 0x00007ffff53cb1fa in TxRef::getThisHash() const () from ../_CppBlockUtils.so
#5 0x00007ffff53db4bf in BlockDataManager_FileRefs::insertTxRef(BinaryData const&, FileDataPtr&, BlockHeader*) () from ../_CppBlockUtils.so
#6 0x00007ffff53dc904 in BlockDataManager_FileRefs::parseNewBlockData(BinaryRefReader&, unsigned int, unsigned int, unsigned int) () from ../_CppBlockUtils.so
#7 0x00007ffff53e5296 in BlockDataManager_FileRefs::parseEntireBlockchain(std::string, unsigned int) () from ../_CppBlockUtils.so
#8 0x00007ffff54d4a7d in _wrap_BlockDataManager_FileRefs_parseEntireBlockchain () from ../_CppBlockUtils.so
(gdb) Both crashes you posted I believe are related. In both cases, data is supposed to be pulled from the blk000X.dat file (and then a pointer to that is to be used for hashing/parsing), but the data isn't getting read from disk. Looking at the code (where it's supposed to pull the data from disk), there's multiple places for it to return NULL. Unfortunately, by the time the segfault happens, it's already long past where the problem occurred. Given the previous backtrace you gave me, I would suspect that the filestream is simply closed or inaccessible. Or I somehow mismanaged the file stream objects/pointers. Unfortunately, the only way to catch this will be really slow, and I'd have to be able to reproduce it. If you can reliably reproduce it, next time you run it in gdb, can you put a breakpoint at FileDataPtr.h:290? If it crashes there, check for what's going on with cidx, cstart, cbytes and the values of the pointers in openFiles_ and the values of fileSizes_. However, if it doesn't crash at that conditional, I'll have to do some work to add some extra conditions and re-run the sample_armory_code.py script over and over until it crashes. |
|
|
|
Version 0.82.1 updated. Same download links as before, but the files/installers have been updated ( except for 32-bit linux). Windows users, please try this version and confirm no more freezing on-load: Windows 64-bit installerWindows 32-bit installerLinux 64-bit Debian packageLinux 64-bit Debian packageUnfortunately, been really busy, and I'm going out of town tomorrow. I won't have enough time to make this an official release, but I'm sure people will test and let me know what they think. I'll do it when I get back. I will still check on the thread and check emails, but I won't be near my dev computer for the next 10 days! UPDATE: I just added Linux-32bit download above. Also just witnessed a crash in Windows during debugging, that is pointing me to some code that is suspicious. Unfortunately, I can't dig into until I get back, but I'll leave open the debugger and I will dig into it when I get back. |
|
|
|
(I don't even know if this is the right place to put this, but I'm sure it'll get moved if necessary) It is 'morally wrong' to pay tradesmen cash in hand, says David Gauke (Exchequer Secretary to the Treasury) David Gauke, a Treasury minister, told The Daily Telegraph that home owners who allow workmen to evade VAT or income tax were forcing others to pay more.
His comments reflect growing concern in Whitehall about the cash-in-hand economy, which costs Britain billions of pounds a year in lost tax revenues. The concept of Bitcoin + tax-evasion is not a new concept, but it is something Bitcoin's image is going to have to deal with if we ever want Bitcoin to reach any degree of acceptance at a higher level. |
|
|
|
2012-07-24 15:55 (INFO) -- qtdialogs.py:5033 - Change address behavior: NewAddr
2012-07-24 15:56 (ERROR) -- qtdialogs.py:4858 - Problem sending transaction!
Traceback (most recent call last):
File "/usr/share/armory/qtdialogs.py", line 4848, in createTxAndBroadcast
finalTx = txdp.prepareFinalTx()
File "/usr/share/armory/armoryengine.py", line 5572, in prepareFinalTx
else: LOGDEBUG('Signatures for input', i, 'are valid!')
File "/usr/share/armory/armoryengine.py", line 293, in LOGDEBUG
logstr = msg % a
TypeError: not all arguments converted during string formatting Can't send transaction, no idea why  It had just sent 1 tx so I can't figure out what's happening. Looks like version 0.82.1. It's an error in the error-logging code (yes, silly) that causes it to bail before it actually sends the tx. This is the same message that someone else has reported, and I committed a fix last week. I think you only need to do a git pull, then restart (no recompile required). |
|
|
|
Not directed towards any particular person/group, I created a walk-thru based on my experience implementing URI support in Armory. https://bitcointalk.org/index.php?topic=79010.0It shows how to do it in windows with the registry (non-admin, like Firefox/Chrome/IE setting your default browser), and for a couple of Ubuntu/Gnome variants (because it's fairly straightforward in Gnome, but Ubuntu 11.04+ switched to Unity and this kind of registration doesn't work anymore). |
|
|
|
|
These URIs should all work "out-of-the-box" if your Bitcoin application does its job correctly (and registers itself with your OS). Unfortunately, Bitcoin-Qt does not do this, for reasons I haven't fully understood yet (perhaps bugginess of implementation). However, most of the alternative clients do this, and simply installing and/or running those programs once will then make "bitcoin:" links clickable from any browser without the user having to setup anything.
Armory checks for the currently-registered application on load and asks if you want to make Armory default. Multibit and Electrum, I believe they register themselves as the "bitcoin:" handler when you install them. I think some pressure should be applied to the core Bitcoin-Qt dev team to do something like this too. It's a tremendously valuable feature for Bitcoin users, especially new ones, to not have to copy and paste information all over the place to send money.
|
|
|
|
it was discussed here back when I did it. I think first it was wrong python version, then it was mainly wrong glibc version linked against the swig stuff vs. the version on my ubuntu. I ended up using a version of cppForSwig I compiled on a different host. Read post https://bitcointalk.org/index.php?topic=56424.msg965679#msg965679 and onwards for more info. Ahh. All that python dependency stuff should be a non-issue, now. And it wouldn't have been issue if you were using Ubuntu 10.04-32bit (which is what I made the offline-bundle for), but I recognize some users will use different distros and/or want to compile it themselves. However, even that has been improved with static compiling of python into the C++ utilities. When I do the next release, I'll make a couple extra offline bundles -- one for 10.04 and 12.04. And I will include all the packages you need to compile it, not just install it. |
|
|
|
One can also do it with armory instead of strongcoin-offlinetx-script, but firefox+strongcoin-offlinetx-script seem simpler to install onto an offline machine than armory (took me multiple sessions of 1-2 hours to get armory onto the offline ubuntu machine).
Molecular, What was the cause of the problem here? If you use the supplied "offline-bundle", it takes about 30 seconds to install on an offline Ubuntu machine (double-click InstallAllDeps.sh, and you're done). If something wasn't so easy, then I'd like to know how it can be improved. I expected the offline machine to be the easiest... |
|
|
|
Passing an unwanted guest to the offline wallet and back again over the USB key, seems like the one main vulnerability of Armory. I was thinking of re-partitioning an old USB flash drive to be just large enough to store most transactions one might make to/from the offline wallet.
This is definitely a non-perfect situation, but it's pretty damned good given the usability requirements. The process is already complicated for some new users, and they may not yet fully understand what's going on. I'd rather them use offline wallets with a USB key than not use offline wallets at all (which is a significant risk if it's too complicated). In that sense, everyone understands USB keys, so it serves its purpose well, and if you take precautions (like disabling USB autorun services, etc), it's very safe. If you are ultra-paranoid, one thing you can do, is buy a USB key that has a write-protect switch. Write the transaction to the USB key (which may be many kB), then turn on write-protect and insert it into the offline system. If you sign the transaction and observe the difference between the original and the signed version, it's only ~140 bytes for each input at the bottom of the TxDP: (in bold) -----BEGIN-TRANSACTION-FygKQ1EY-------------------------------------------------
_TXDIST_fabfb5da_FygKQ1EY_00a0
01000000023f4c47217647372132666fc1ae28d03508c8688a20273b255fbbf9b115b455e601000 0
0000ffffffff2224b044061b79b7af49c0df6c431dc600259fd5b222b3e25ebeb6001a7bc1d0000 0
...
_TXINPUT_00_19.59950000
_SIG_myiqg9jzUJ3TFi2dXaMBth1dDEcGuWuyRf_00_008c
4930460221007c746bf76bd6f8b3f60f62a8afd2dd653f66e87c90482fb4bea79118109bf1d1022 1
003d5ea4fe5223c7cc060f4f197208b4c8551195a6a1618065ef44cecba9405ec201410440ecb35 a
d63922d4d11314705a47372d63bc8bbc52f38c6abfba9c9fc5b1f230d432b7023687fda21c8a1f5 5
bf6c779cfd691917d4cb00b706b7a0df7d3af360
_TXINPUT_01_21.11110000
_SIG_mxUVS4fhnxD7jm5yjozuwkeMVDYakMueHB_01_008c
4930460221007db2bfb26234265781b7ca224f637a59fd4d1cb3b2f54330a1a075237f5ce09b022 1
00e05ce4dc9e3fcbc167d748da5286d26aabb3c0ad3874e2d4d8792b0e86208147014104f347f5a 0
3fa446972313e1df4e1596410bcfbaddaea90a8dd7cce01ff4f9575f34ed5b0e185fe1b36279e6f a
b0e219a72090de2d703b4df8d35df5af661f4fe5
-------END-TRANSACTION-FygKQ1EY------------------------------------------------- This is quite a bit of data, but theoretically it could be copied by hand or scanned+OCR on the online computer. If you only do it a couple times a year and holding a ton of money, it might be worth it. I was looking into serial cable solutions, but the hard wire connecting the two computers made me uncomfortable (not to mention that it takes quite a bit of setup to make sure that the serial line is secure). I was wondering if that sounds like a very good idea and, if it does, if the developer had any idea about how much space might be a good compromise between usability (key not usable if too small) and enhanced security (space for unwanted guests if key partition too large). As the wallet is offline, I don't anticipate ever sending to multiple addresses, or having especially long blockchain entries. I have imported private keys for this just in case anything were to go wrong with the armory wallet or if support on Armory were to end abruptly.
Luckily, Armory wallets have been the same since day one, and will continue to support the same deterministic structure even with the new wallet format coming up. As such, any version of Armory since January will be sufficient at producing any number of keys from any Armory wallet you've ever created. Even if support were to disappear, you'll be able to get those back with any version. As for the small USB key partition: I like the idea a lot better if there was a way to bound the transaction size. Unfortunately, these sizes are highly variable -- since I need to store previous transactoins in the TxDP (what is sent to the offline computer) there could be 100 kB in a single transaction. However, most transactions, for simple users, will only include a couple inputs and will only be a few kB. As such, the gap between smallest and largest is big enough that something sufficiently advanced could hide there  |
|
|
|
Hello, thanks for creating Armory looks pretty damn good so far. I wanted to try it out because I am looking for a bit more freedom than the standard client provides and it seems like the software is getting more secure. I have two questions:
1) How would you rate security (i the sense of absence of bugs which could cause a user to lose money) in relation to the default client? I am contemplating which client to use for Walets containing the majority of my Bitcoins
2) I have created a new wallet and made a digital backup. Am I correct in understanding that this backup will be sufficient always and never has to be recreated due to the deterministic nature of the armory wallets? (For the default client I have recreated my backups monthly to avoid losing coins sent to newly generated addresses).
Thank you
Hi watchwood, (1) So far, even while Armory has been in alpha for six months, I have received no reports of anyone losing money with Armory. Ever. I spent days testing and ironing out the wallets when I started, and there's never been a hint of a problem! Even I am impressed that the wallets have been so reliable through the infancy of the program. --Offline wallets are the holy grail feature, and they work. Even though they use USB keys, they are orders of magnitude better than regular encrypted wallets. --When you do maintain encrypted wallets online, Armory uses a scrypt-like key-stretching function to make it difficult for someone to brute-force the password even with GPUs. --If you make a paper/digital backup, all coins are always recoverable (after all, I think HDD failure is a bigger risk for most users than theft). (2) The digital and paper backups are essentially the same. They are deterministic wallets and all keys ever produced by them are recoverable from the first address & chaincode in the wallet. The only caveat is imported keys, which will have to be backed up separately. However, you can "Backup Individual Keys" in order to create a unified backup of all imported addresses. You can even use it to get the private keys of all your addresses (used so far) in case you want to import them into another program/servicce. Thanks for your interest! I'm always happy to answer more questions about Armory  |
|
|
|
Hello etotheipi, I'm testing the 0.82 and currently found no real bug. There's only one minor tiny improvements that could be made: I transferred some coins from one address to another in the same wallet. Armory understand this is the same wallet and so balance doesn't change. But when I export the CSV, the transaction is set in the "Total credit" column only, with no mention of fees paid. So it looks like we received the whole amount instead of sending and receiving it at the same time. Could make the column "Total debit" mention the debit as well? Thanks a lot for your great work Fwhew! It's so nice to hear that at least one person is not having a problem with Armory! A lot of Armory problems reported in the last couple weeks and I've been swamped at my real job. So, I won't get to address the major issues for another couple weeks (such as switching Armory to maintain its own blockdata files). By the way, I went down to 30 hrs/week after crowdfunding back in March so that I could work on Armory more. And I will be back to that in a month. Until then, I get to work 50+ per week and only get paid for 30 Armory development is slow right now... I just looked at the export-tx-history code and it does seem to be an error. Sent-to-self transactions are not reflected properly in the .csv. That should be an easy fix. Also I am finally able to reproduce the version-check-freeze. And so far nothing I do fixes it. It must be related to github, since urllib2.urlopen works with google & microsoft.com fine, despite freezing for 4 min on github... I'll try to host the version check file somewhere else and see if that fixes it. Hopefully tomorrow I'll have a re-release of 0.82.1 with a few other bug fixes too, and then I'll dig into the segfaults... |
|
|
|
And then you have to run "gdb python" because you actually have to debug python in order to hit the stack trace. So you "gdb python" to get into GDB. Then you type "run" to start debugging python. Then you type "import sample_armory_code". Then the stack trace will extend into the C++ code. Not to mention, once it's compiled in debug the C++ will provide a little more output.
I've just been doing "gdb python" then "run sample_armory_code.py". That should be enough, right? gdb's "run" command takes arguments and passes them to the process it's debugging - in this case "python". As predicted the crash is no longer happening of course... When I get my faster laptop back from having it repaired I'll try running it using valgrind. That usually finds the source of intermittent crashes. Oh good call! I haven't run valgrind on the C++ codebase in months! Since I've changed so much of the underlying code since then, I should probably check it again. I hope you find something. I haven't yet experienced any crashes, but many other users have, and I'm hoping they're all related to the same thing... |
|
|
|
So I say 1/1000 because I think a blkfile-write and blkfile-open have to occur at the same time. The hypothesis is further supported by the fact that I have seen a curious segfault once in the past month similar, and you are the only other report of it (and I open Armory like 50x per day!)
Please let me know if it happens again!
I ran my modified copy of sample_armory_code.py twice today. Both times it failed with "Segmentation fault". I've not modified the C++ code at all. I'm now running it in gdb to hopefully get a stack trace for you, though in my experience running it in gdb is often enough to stop the crash from happening. It actually usually is useful, but you might have to compile Armory in debug mode (I manually modify the Makefile [at the top] because I do this so rarely). And then you have to run "gdb python" because you actually have to debug python in order to hit the stack trace. So you "gdb python" to get into GDB. Then you type "run" to start debugging python. Then you type "import sample_armory_code". Then the stack trace will extend into the C++ code. Not to mention, once it's compiled in debug the C++ will provide a little more output. I have been overwhelmed with work-work, and Armory has fallen in priority this month. This will settle down in a couple weeks (my real job rarely gets this intense) and I'll be back to part time like before. So all of you digging into these things for me is fantastic! Thanks so much! |
|
|
|
I reinstalled and python27.dll was installed fine as well, and armory now boots. But it is unresponsive once it loads up. After about 4 minutes it becomes responsive and appears to work fine. (WARNING) ArmoryQt.py:1273 - Memory pool file was corrupt. Deleted. (no further action is needed) (ERROR) ArmoryQt.py:782 - Could not access latest Armory version information (ERROR) ArmoryQt.py:783 - Tried: https://raw.github.com/etotheipi/BitcoinArmory/logger/versions.txtI then disabled the version check and restarted armory, this time it was immediately responsive. Okay, this is clearly very wrong behavior. I just wish I could reproduce it so that I can figure out how to make it go away. Any information that might explain why you experience this delay and not me? It doesn't happen on my Win7-64bit VM. I don't really want to disable it, but I will have to if I can't figure this out. I have a strange problem. I'm using the following piece of code (on a watch-only testnet wallet) and am getting no Addr20 value. ledger = wlt.getTxLedger() #wlt is a PyBtcWallet
ledger[0].pprint()
Returns LedgerEntry:
Addr20 :
Value : 10
BlkNum : 71313
TxHash : 43b999e0c1df82e83eaf2c4a589d7d8517552c32d4006ad4ae486c09ef42c881
TxIndex : 1
isValid : 1
Coinbase: 0
sentSelf: 0
isChange: 0
Also, just for my own sanity check, I found that the type of ledger[0].getAddrStr20() is str with length 0 Any ideas on why this is happening? You somehow evaded the code path that sets that addr20 value. I am looking at the code, but I can't figure out how that would happen. Could you PM/email the context so I can see how it was created? Was it created from Armory itself? Or did you create it from a script on the offline computer using armoryengine? If I can figure out how it happened, I can either fix that code path, or cut it off to avoid it in the future (I would like people to be able to leverage the library, like you are, without breaking stuff). |
|
|
|
Also, I am unsure about the difference between spendable, unconfirmed and ultimate in address balances. Can someone clear this up for me? It didn't behave how I expected. eg:
Into one address I had 1.2 btc transferred with 8 confirmations and 2.1 btc with 1 confirmation, and I got this result:
spendable - 3.3
unconfirmed - 0
ultimate - 3.3
(1) Ultimate/Full includes every, confirmed and not confirmed (2) Spendable includes everything (SentToSelf || >1 confirmation) (3) Unconfirmed is (NotSentToSelf && <6 confirmations) EDIT: I realize now it would've been clearer to say avoid "Spendable" and just say "Confirmed". Though maybe not: you send coins to yourself in Armory and they show with 0 confirmations, yet it still shows up as confirmed. That doesn't fit well with folks conditioned to believe that nothing is confirmed until 1+. Ehhh... whatever. I'm leaving it. |
|
|
|
Tried it again & no delay on first run, but not when I tried to see where the update setting was left under Help -->. Here is the log from just before the errors begin: 2012-07-15 19:09 (INFO) -- ArmoryQt.py:350 - Loading blockchain took 59.3 seconds 2012-07-15 19:09 (INFO) -- ArmoryQt.py:403 - Usermode: Expert 2012-07-15 19:09 (INFO) -- ArmoryQt.py:704 - Changing usermode: 2012-07-15 19:09 (INFO) -- ArmoryQt.py:705 - From: Expert 2012-07-15 19:09 (INFO) -- ArmoryQt.py:713 - To: Expert 2012-07-15 19:09 (INFO) -- ArmoryQt.py:2525 - Another Armory instance just tried to open. 2012-07-15 19:09 (INFO) -- ArmoryQt.py:755 - User requested never check for new versions 2012-07-15 19:09 (INFO) -- armoryengine.pyc:9084 - Handshake finished, connection open! 2012-07-15 19:17 (ERROR) -- ArmoryQt.py:782 - Could not access latest Armory version information 2012-07-15 19:17 (ERROR) -- ArmoryQt.py:783 - Tried: https://raw.github.com/etotheipi/BitcoinArmory/logger/versions.txtAfter it unfroze, went to Help --> Armory Version and had no delay at all seeing the message that a new version was available, I tried that several times in a row, no delays and no more log entries being created to share. I'll try flatfly's idea. And if I read line-by-line, I can put in my own timeout (unless it freezes on the first readline()). This is frustrating... and even more so when I can't reproduce it on my side! |
|
|
|
Interesting you posted this just as I finished compiling with another solution. I found a post of someone reporting the exact same problem, and it was that there is a near-infinite timeout set at the socket layer that has to be overridden explicitly (I specify a urlopen timeout, but not socket.read timeout): import urllib2
import socket
socket.setdefaulttimeout(CLI_OPTIONS.nettimeout)
versionLines = urllib2.urlopen(HTTP_VERSION_FILE, timeout=CLI_OPTIONS.nettimeout)
versionLines = versionLines.readlines()
However, since I can't reproduce the problem, I had to recompile the Win64 version and replace the previous one. @traderjoe: please re-download and reinstall. Tell me if the problem went away. The links below are the same as on the original post, re-linked here for convenience. Windows 64-bit installerWindows 32-bit installerLinux 64-bit Debian packageLinux 32-bit Debian package |
|
|
|
After reading the document - it appears to use a seed key generated by a random number generator, and NOT A PASSPHRASE which most people seem to expect and want.
Randomized passphrases can be converted to memorable objects via changing the "alphabet". Seeds are 16 bytes -- which means 16 base-256 characters. This can be converted to a passphrase by changing it to base-80,000, where 80,000 is number of words in your dictionary. Thus you can re-represent a 16-byte seed with approximately 8 such words from your dictionary. I think you mean exactly 8 words from a 65536 word dictionary (dictionary words literally indexed 1:1 to 16 bit machine words) 8 words = 128 bits (assuming 65536 possible words) 8 words selected from dictionary size of 80000 would exhaust the 128 bit address space too easily. assuming you only select 8 words: 4 times as many (8 word) combinations out of 80000 word dictionary compared to the 65536 word ones ... Where did you get the number 80k from anyway? I have a modest "word game" dictionary sitting around that contains zero hyphenated words, abbreviations, acronyms, or proper nouns. It also does not contain single-letter words such as "I" ... Just using US english, weighs in at more than double the 80k you listed... was going to feed it into vanitygen but never got around to it. I used 80k because I heard that's what Electrum used a long time ago. Maybe it doesn't. But the example is still valid. I totally agree that a dictionary of size 2^16 would make a lot more sense... |
|
|
|
Wouldn't start on 64-bit windows. Throws 2 errors. "The specified module could not be found LoadLibrary(pythondll) failed" and missing PYTHON27.dll
I just checked this on a super-fresh Win7 installation and I don'thave the same problem. I wonder if you somehow ended up with a partial installation. I'm staring at python27.dll in my Windows 7 Armory installation directory, right now! (C:\Program Files (x86)\Armory\Armory Bitcoin Client\python27.dll). Could you try reinstalling? Going to Help --> Armory Versions, I clicked on "Never again", restarted Armory & it worked fine--no abnormal delay. Then I went to Help --> Armory Versions to try to change it back. Before I could select anything, there was a long delay again (>5min?), followed by a dialog box saying "The latest Armory version information could not be retrieved.Please check www.bitcoinarmory.com for the latest version information." I clicked OK and it seems to be working normally. So this is good and bad news. It's good that it's only version checking causing the problem, I can always disable that if I need to. But it's bad because, I have no idea why that's problematic. I'm trying to grab the versions.txt file from github... I wonder if hosting it somewhere else would improve the situation? For those who are python-savvy, I'm looking at the code and wondering if maybe the last line below is the problem...? import urllib2
versionLines = urllib2.urlopen(HTTP_VERSION_FILE, timeout=CLI_OPTIONS.nettimeout)
versionLines = versionLines.readlines()
Is the "readlines()" call somehow triggering reading data for 5 minutes? I use urllib2 for checking the internet connection to google without a problem, but I didn't call readlines(). However, that call definitely doesn't take 5 minutes on my computer or any of the VMs I tried a signed offline transaction and 0.82.1, Windows 64 bit version worked fine except for the above. Thanks for promptly upgrading the python library btw.
And thanks for letting me know about this. Maybe I'll install Secunia on one of my windows machines to look out for this kind of stuff, myself. |
|
|
|
|
Show Posts
