Bitcoin Forum
December 08, 2016, 08:11:59 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 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 ... 232 »
  Print  
Author Topic: Armory - Discussion Thread  (Read 482140 times)
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1442



View Profile
July 08, 2012, 05:51:48 PM
 #961

When I mentioned fixed withdrawal addresses is because the services don't allow to change them, not because I'm attached to them.
There is a way for those service owners to change them, I'm just sure most will not do it easily when asked to because they used fixed withdrawal addresses for security reasons.

1481184719
Hero Member
*
Offline Offline

Posts: 1481184719

View Profile Personal Message (Offline)

Ignore
1481184719
Reply with quote  #2

1481184719
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
BadBitcoin (James Sutton)
Donator
Sr. Member
*
Offline Offline

Activity: 451



View Profile
July 08, 2012, 09:52:49 PM
 #962

can't wait to use this! However the non importing feature from wallets in 0.6.XX makes this distro completely useless for me, any ETA on when the new version supporting 0.6.2 will be released?


First of all, it's going to be a little while.  I need a new wallet format.  Read a few messages back in this thread for more info.

Second of all, why is this such a dealbreaker for folks?  I'm not looking down on anyone for this, I just don't understand why this feature is so critical -- in fact, it's going to cause so many problems for people I don't even want to do it.  Bitcoin-Qt is especially not suited for multiple programs using the same addresses at the same time -- users will end up with locked coins and incorrect balances and it's really difficult to fix.

(1) Even if you can import your whole bitcoin-qt wallet, only the exact addresses you import will be useful.  All new addresses produced by Armory and Bitcoin-qt will be different.  This is one reason that, if you are going to import any Bitcoin-qt addresses, you should import all of them and then remove the wallet from Bitcoin-qt.
(2) If you're dealing with Vanitygen addresses:  those are in the correct format already, so there's not problem there.
(3) If you're not sure yet whether you want to make the move, then you shouldn't be migrating anything.  Please just create a new Armory wallet and move some/all of your coins to it.  Move them back if you don't like Armory.  So much heartache can be avoided this way.

I know that some people are attached to some of their addresses and that's why some people must have a migration feature.  And some users want to be able to migrate your keys from an offline wallet without bringing it online.  Those are two reasons that wallet migration should be a dealbreaker, but I thought it was a small percentage of users.  What other reasons are there?

I am seriously frustrated, because I feel like migration feature is going to cause endless heartache and customer-support issues (locked coins are always a crisis).  I just want to know why people are requesting this feature, and make sure that users who actually should not be using the migrate feature anyway, aren't passing up Armory because it's not there.    (it sounds like I'm going to have to add all sorts of warnings to the program, akin to what I just warned in this post)

I wouldn't care, but the problem is I have about 40 accounts with different people all sending coins to specific addresses of mine, and tracking them all down individually and getting them to switch to a new address would be way too much work to prove useful for me.

Take a look at my  machine learning/economics/engineering blog!
www.learningann.wordpress.com
Gladamas
Sr. Member
****
Offline Offline

Activity: 294


Bitcoin today is what the internet was in 1998.


View Profile
July 08, 2012, 10:17:46 PM
 #963

Ah, I forgot to mention, every time I start an Armory instance that crashes later, it won't receive (show or give any indication of) a new transaction coming to one of its Bitcoin addresses. The transactions are in the blockchain but won't show up. I forgot if it ahows the correct block number or not, though. Perhaps the crash occurs when Armory receives a second transaction (after the first that it didn't show?) Just a WAG.

Do you mean, "when Armory is getting ready to crash, it no longer shows any new transactions until you restart?"

That is correct. When I start an Armory instance, it either will crash later or it won't crash later. If I start an Armory instance that will crash, then it won't record any received (to-my-wallet) transactions in the ledger. I'm not sure if restarting works or not.

@ Gladamas

FYI, my Win7-64bit VM with 2GB of RAM and Bitcoin-Qt 0.6.3 has had Armory open for 2 days and has not crashed yet.  So, unless there is a specific trigger someone can point me to, I'm going to have to let this bug through for now.  Please let me know more details about the crashing, and hopefully I'll find a way to replicate it in the future.

However, I'm very close to a 0.82.1 version with full logging.  This will improve the situation a lot, since every crash can now be accompanied by a full log file of every informational message and error message, without the user even doing anything.   I will hopefully have that out tonight, and those of you experiencing crashes will only have to send me your armorylog.txt file after the crash.

Thank you, I will give you whatever information I can if I have any. I haven't noticed any particular trigger but that log-file should help.

Say you open a window that lists all of your private keys (export keys function.) Will Armory record those keys in the log-file? If you send BTC to someone, will it log the transaction amount/etc. in the log-file?

Thank you for you work on this!

1GLADMZ5tL4HkS6BAWPfJLeZJCDHAd9Fr3 - LQ6Zx8v7fHVBiDX5Lmhbp6oEDB7dUFjANu
GPG 0xF219D5BB3C467E12 - Litecoin Forum
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 09, 2012, 02:01:43 AM
 #964

I wouldn't care, but the problem is I have about 40 accounts with different people all sending coins to specific addresses of mine, and tracking them all down individually and getting them to switch to a new address would be way too much work to prove useful for me.

Fair enough.  I just want to make sure that requests are justified for the risks involved.  I think a lot of users want to "import" their Bitcoin-Qt wallets because they don't realize the risks, and don't realize that transferring coins is frequently the safest way to transition to a new wallet, especially for experimenting with Armory.

My own experience is that I have a few payout addresses for my miners.  If I have to change those addresses, oh well.  I didn't realize so many people had such hardened accounts...


Say you open a window that lists all of your private keys (export keys function.) Will Armory record those keys in the log-file? If you send BTC to someone, will it log the transaction amount/etc. in the log-file?

I'm making sure that any variable that ever holds private key data is never written to the log-file, even when there's an error.  However, I will serialize all transactions (signed and unsigned) into the logfile.  I was kind of concerned about logging that information, but anyone who has access to your system (and thus the log file) already has access to all the transaction information, so it's redundant information.

If this logic doesn't sound right, please let me know.  I can still adjust the behavior, or at least make it configurable.  I will have a --nologging option to disable it completely..

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!)
teste
Sr. Member
****
Offline Offline

Activity: 316


View Profile
July 09, 2012, 06:20:22 PM
 #965

Hi, I have a feature request.

1- Add on transactions window a column showing what was the usd value of 1 bitcoin in the time someone sent me the coins.
If I'm a merchant that accept bitcoin I would like to record the value of bitcoin on each transaction. So I can choose to only sell it if bitcoin price is = or higher when I received it.
Gladamas
Sr. Member
****
Offline Offline

Activity: 294


Bitcoin today is what the internet was in 1998.


View Profile
July 09, 2012, 06:42:54 PM
 #966

Etotheipi, thanks, just making sure.  Smiley

Hi, I have a feature request.

1- Add on transactions window a column showing what was the usd value of 1 bitcoin in the time someone sent me the coins.
If I'm a merchant that accept bitcoin I would like to record the value of bitcoin on each transaction. So I can choose to only sell it if bitcoin price is = or higher when I received it.

What would that price be? MtGox? BTC-e? Would it factor in a configurable fee %?

1GLADMZ5tL4HkS6BAWPfJLeZJCDHAd9Fr3 - LQ6Zx8v7fHVBiDX5Lmhbp6oEDB7dUFjANu
GPG 0xF219D5BB3C467E12 - Litecoin Forum
teste
Sr. Member
****
Offline Offline

Activity: 316


View Profile
July 09, 2012, 06:55:22 PM
 #967

I think should have an option to set any exchange we want.
teste
Sr. Member
****
Offline Offline

Activity: 316


View Profile
July 09, 2012, 07:03:52 PM
 #968

If Armory add it, will only work for transactions done after the feature is implemented, right?
Because probably we don't have a database of all past time exchanges prices
kuzetsa
Sr. Member
****
Offline Offline

Activity: 369


View Profile
July 09, 2012, 08:31:22 PM
 #969

...we don't have a database of all past time exchanges prices

I really don't think there's a single exchange out there right now that DOESN'T provide historical data about their past exchange rates. mtgox's data is quite nice. covers all of their rates for multiple currencies going back to when << some currency >> was first traded on their exchange.

Really agree that this feature could be convenient for other purposes than the one you listed.

...First of all, it's going to be a little while.  I need a new wallet format.  Read a few messages back in this thread for more info.

Second of all, why is this such a dealbreaker for folks?  I'm not looking down on anyone for this, I just don't understand why this feature is so critical -- in fact, it's going to cause so many problems for people I don't even want to do it.  Bitcoin-Qt is especially not suited for multiple programs using the same addresses at the same time -- users will end up with locked coins and incorrect balances and it's really difficult to fix.

So if I wanted to delete my wallet / history / addresses completely out of the mainstream satoshi client (bitcoind ... or bitcoin-qt if I was using the gui version. apparently they both use the same wallet & blockchain data)

Expecting this to work... maybe the dealbreaker isn't that it currently doesn't work... Web browsers can import history when you install a competing browser. email clietns too, etc.

Why should I have to:

1) cause extra wasteful traffic in the blockstream to send money to myself as a workaround
2) pay any related transaction fees for something that shouldn't require network traffic
3) justify wanting to use a (currently broken) feature that has a button right inside armory in a conspicuous place

My dealbreaker isn't wanting a feature to work. It's that project lead / main dev has a half-arsed feature that doesn't work...

What's with wanting to shift blame to people who have a use for the feature rather than fix the current state of incompatibility.
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 11, 2012, 03:11:27 AM
 #970

Why should I have to:

1) cause extra wasteful traffic in the blockstream to send money to myself as a workaround
2) pay any related transaction fees for something that shouldn't require network traffic
3) justify wanting to use a (currently broken) feature that has a button right inside armory in a conspicuous place

My dealbreaker isn't wanting a feature to work. It's that project lead / main dev has a half-arsed feature that doesn't work...

What's with wanting to shift blame to people who have a use for the feature rather than fix the current state of incompatibility.

Please allow me to share a story with you, about why this seems half-assed.   It's a kind of outlier in Armory's feature set, since most of the other features are very well-developed and stable.

There was high demand for wallet migration just before Bitcoin-Qt 0.6.0.  I implemented it.  It worked.  Flawlessly.  With encrypted wallets, and everything.  I put a lot of time into catching everything that could go wrong: wallets updating mid-migraion, catching duplicate addresses existing in your other wallets, preventing alt-network wallets, and providing notifications and intuitive ways to deal with all of it.  It was a high quality feature.

Then, a month later, the main devs decided to switch to compressed public keys which requires a whole new wallet format for Armory.  I was crushed.   This feature which met all the needs of the users requesting it became basically useless.  However, at the time, most people still were using wallets that were made prior to 0.6.0.  So I added the warning and left the feature in there.

Now it's been many months.  Maybe it's time to remove it, until I update the wallet format.  Most new users will have created their wallets post 0.6.0 so the number of users who benefit from it is small.   But that's why it is the way it is.  And the point has been made that I need to add a warning to the address-import dialog.  So far, you are the first user who has pulled individual keys out of wallet.dat to import (and told me about it). 

I didn't mean to "shift blame".  It's that many users do not recognize the risk of managing addresses from multiple wallets.  They don't realize they could be shooting themselves in the foot.  And on top of it, it's never been something I personally had a use for.  So I was asking to make sure that the users requesting it actually understood it.  Because in the end, supporting this is a a lot of work, and I have a ton of other priorities to balance.

Finally, I had a flurry of nearly identical requests/complaints in the past couple days and I didn't understand why users would say that Armory is "useless" without it.  However, someone posted good information about why this feature is necessary, and I thus conceded.  It will happen.  Although, I am still bothered by the "useless" comment (but the user did say "useless to me", so that's fairly reasonable).



For now, if you cannot accept the lack of that feature, then please subscribe to the announcements thread which only triggers notifications on new, final releases (maybe one every few weeks).  When the new wallet format is done, that will surely be announced.

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: 2002



View Profile
July 11, 2012, 10:08:18 AM
 #971

I just ran the armory sample_armory_code.py to generate SatoshiDice stats and got a crash.  The script said "Let's look at all the bets ever placed at SatoshiDice.com" then "Segmentation fault (core dumped)".

The logfiles showed:

==> /var/log/kern.log <==
Jul 11 02:26:26 chris kernel: [128656.317555] python[29564]: segfault at 4 ip b6c060ed sp bf864c50 error 4 in _CppBlockUtils.so[b6ade000+390000]

This was in git revision 60d513aaee8085, which was the head of the 'dev' branch last time I fetched from the repository (5th July).

I've run the same script many times without a problem, so I can't reproduce the bug, or provide any extra information that might be of use, sorry.  Just: there's a serious crashing bug in there somewhere...

etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 11, 2012, 01:16:49 PM
 #972

I just ran the armory sample_armory_code.py to generate SatoshiDice stats and got a crash.  The script said "Let's look at all the bets ever placed at SatoshiDice.com" then "Segmentation fault (core dumped)".

The logfiles showed:

==> /var/log/kern.log <==
Jul 11 02:26:26 chris kernel: [128656.317555] python[29564]: segfault at 4 ip b6c060ed sp bf864c50 error 4 in _CppBlockUtils.so[b6ade000+390000]

This was in git revision 60d513aaee8085, which was the head of the 'dev' branch last time I fetched from the repository (5th July).

I've run the same script many times without a problem, so I can't reproduce the bug, or provide any extra information that might be of use, sorry.  Just: there's a serious crashing bug in there somewhere...

The blk0001.dat file just split!    

I've gotten a couple reports similar crashes/freezes, but they have all been users who hadn't upgraded to version 0.81+ which handles the blk file split...  Versions prior to 0.80 will not handle this phenomenon and will crash.

Now, technically the dev branch is 0.81/0.82.  However, it appears that you are using the pre-0.80 blockchain utilities, because when I run the script on that branch unmodified (but with the latest compiled utilities) it crashes later due to blkchain utility calls that are no longer valid in the new code (really, only a couple tiny things).

The first part of the solution is to recompile.  Go into the cppForSwig directory, do a "make swig".

The second part of this is: I updated the sample code to work, by making the following replacements throughout the code:

FROM:
Quote
for tx in txList:
   ...
TO:
Quote
for txref in txList:
   tx = txref.getTxCopy()
   ...

Additionally, you must replace all calls to "getTxInRef" and "getTxOutRef" with "getTxIn" and "getTxOut". 

I have updated the script in the dev branch, though I suspect you have heavily modified it (based on your satoshidice posts... thanks for keeping that up, btw!).  So I figured you might want to manually update it.  That's all I did just now to modify the script to work with 0.81+ compiled utilities.

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: 2002



View Profile
July 11, 2012, 04:46:01 PM
 #973

The first part of the solution is to recompile.  Go into the cppForSwig directory, do a "make swig".

I had already done that.  I did a 'make clean' then 'make swig' when I updated from git (which I had to do because my 32 bit Python was getting MemoryError exceptions after the blockchain grew to a certain size, and I was hoping you had fixed the problem in git.

The second part of this is: I updated the sample code to work, by making the following replacements throughout the code:

FROM:
Quote
for tx in txList:
   ...
TO:
Quote
for txref in txList:
   tx = txref.getTxCopy()
   ...

Additionally, you must replace all calls to "getTxInRef" and "getTxOutRef" with "getTxIn" and "getTxOut". 

I have updated the script in the dev branch, though I suspect you have heavily modified it (based on your satoshidice posts... thanks for keeping that up, btw!).  So I figured you might want to manually update it.  That's all I did just now to modify the script to work with 0.81+ compiled utilities.

I had already done something similar, like this:

Quote
      for tx in txList:
         tx = tx.getTxCopy()

which I think would have the same effect as your suggested change.  I also had already replaced the getTx*Ref with getTx* - (else the script threw exceptions and failed).

Like I say, the script works almost all the time - it only crashed the once, and I've run it a lot of times since switching to the dev branch.

etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 11, 2012, 05:41:29 PM
 #974

Like I say, the script works almost all the time - it only crashed the once, and I've run it a lot of times since switching to the dev branch.

Oh, I misunderstood.  I thought you said it used to work and now doesn't.  Sounds like it always works, except for one hard crash recently during loading blockchain.  Is that correct?

In that case, I suspect a very inconveniently timed blk000X.dat update from the Satoshi client may have messed up (reading a partial write).  I always wondered if that would happen, and maybe that's what happened here.  Thus confirming it is possible but rare.

I'm not sure there's a good way to fix it (since Satoshi client always has that file open for writing), and I might just have to take the 1/100 chance of that happening until Armory starts managing its own blockchain file.

Am I understanding you?

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: 2002



View Profile
July 11, 2012, 06:07:13 PM
 #975

Oh, I misunderstood.  I thought you said it used to work and now doesn't.  Sounds like it always works, except for one hard crash recently during loading blockchain.  Is that correct?

In that case, I suspect a very inconveniently timed blk000X.dat update from the Satoshi client may have messed up (reading a partial write).  I always wondered if that would happen, and maybe that's what happened here.  Thus confirming it is possible but rare.

I'm not sure there's a good way to fix it (since Satoshi client always has that file open for writing), and I might just have to take the 1/100 chance of that happening until Armory starts managing its own blockchain file.

Am I understanding you?

Yes, it only segfaulted once.  And I was running bitcoin-qt at the time, so you're probably right that the blockchain file was updated while it was being read.

It doesn't seem like it should be all that rare to me - it takes a minute to read the blockchain, and it gets updated every 10 minutes or so, so that sounds like a 1-in-10 chance to me.  I guess maybe it needs to be reading the right bit of the file, and that's why it's rarer.

Either way, perhaps you can't stop it being an error, but probably you could do something other than segfaulting when it happens...

Incidentally, I noticed recently that your SatoshiDice script incorrectly identifies a few hundred winning "under 64000" bets as having been refunded.  The multiplier for those bets is so low that even when you win, you sometimes don't cover the transaction fee that they take off for sending your winnings back to you.  So your returned amount can be slightly more than your bet, and still be a win, and your returned amount can be very close to your bet amount and not be a refund.

dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
July 11, 2012, 06:36:29 PM
 #976

Incidentally, I noticed recently that your SatoshiDice script incorrectly identifies a few hundred winning "under 64000" bets as having been refunded.  The multiplier for those bets is so low that even when you win, you sometimes don't cover the transaction fee that they take off for sending your winnings back to you.  So your returned amount can be slightly more than your bet, and still be a win, and your returned amount can be very close to your bet amount and not be a refund.

It happens with 'under 48000' bets too.  Here are couple of examples:

  bet wins 71 satoshis less than the stake
  bet wins 453 satoshis more than the stake

etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 11, 2012, 07:00:58 PM
 #977


My guess is, it's only if Armory tries to open the file for reading during a bitcoin-qt write operation.  The file can be updated all you want after Armory opens it, and it will never be affected by the updates because they are all append operations.  The file will have the same size and content according to Armory regardless of how much data has been added while it is scanning (until I close and reopen it).  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! 

What you said makes total sense about SatoshiDice... I could see the script misclassifying those bets.  I'll take a look at it a little later, but would rather not clutter this thread with that discussion.  Please PM or reply to the SD thread to talk about it...

P.S.--
Either way, perhaps you can't stop it being an error, but probably you could do something other than segfaulting when it happens...
It's not like I chose to segfault.  That's not something I have much control over in this case.  If I can prevent phenomenon from happening, then I will try, but I don't have any control over that behavior until I find the precise cause.

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

Activity: 1708



View Profile
July 11, 2012, 07:05:08 PM
 #978

It doesn't seem like it should be all that rare to me - it takes a minute to read the blockchain, and it gets updated every 10 minutes or so, so that sounds like a 1-in-10 chance to me.  I guess maybe it needs to be reading the right bit of the file, and that's why it's rarer.
The calculation isn't so easy. The blkNNNN.dat files are maintained with buffering but without obeying proper lock protocol.

You could probably work around this problem by creating file system snapshots (shadow copies in the Windows parlance: vssadmin.exe is the tool to look at).

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
July 11, 2012, 07:22:03 PM
 #979

It's not like I chose to segfault.  That's not something I have much control over in this case.  If I can prevent phenomenon from happening, then I will try, but I don't have any control over that behavior until I find the precise cause.

I wonder if you can provoke the bug into happening more often by running a modified bitcoind that simulates blocks being found very rapidly, so there's a much greater chance of the two events coinciding.

take5
Jr. Member
*
Offline Offline

Activity: 41



View Profile
July 12, 2012, 02:46:56 AM
 #980

Not sure what's happening, but I get this error every time I try to start Armory.

Code:
Traceback (most recent call last):
  File "ArmoryQt.py", line 2439, in <module>
    form = ArmoryMainWindow()
  File "ArmoryQt.py", line 343, in __init__
    self.loadBlockchain()
  File "ArmoryQt.py", line 1110, in loadBlockchain
    BDM_LoadBlockchainFile()
  File "/home/evan/BitcoinArmory/armoryengine.py", line 898, in BDM_LoadBlockchainFile
    return TheBDM.parseEntireBlockchain(blkdir)
  File "/home/evan/BitcoinArmory/CppBlockUtils.py", line 1238, in <lambda>
    __getattr__ = lambda self, name: _swig_getattr(self, BlockDataManager_MMAP, name)
  File "/home/evan/BitcoinArmory/CppBlockUtils.py", line 51, in _swig_getattr
    raise AttributeError(name)
AttributeError: parseEntireBlockchain


However this is the first real problem I've ever had with Armory Smiley
Pages: « 1 2 3 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 ... 232 »
  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!