Author

Topic: Armory - Discussion Thread - page 182. (Read 521829 times)

legendary
Activity: 1428
Merit: 1093
Core Armory Developer
July 12, 2012, 11:22:36 AM
Code:
[quote author=take5 link=topic=56424.msg1025540#msg1025540 date=1342103784]
Well it seems like I forgot to make swig, but now when I do that I get this:
...
g++: error: /usr/lib/libpython2.7.a: No such file or directory
make: *** [swig] Error 1

Which is strange since I've never had a problem with python before and I haven't used it outside of Armory in quite awhile. I'll try reinstalling it and see what happens.
edit: I reinstalled all the python packages, but I'm still getting the same error. For some reason I always seem to have these issues with Fedora.

Okay, so this was a bug in 0.81 (for those who don't use Ubuntu).  Do a "git checkout dev" to switch to the dev branch, which is 0.82.  It's fairly well tested but not officially released.  Then make again.  The makefile should work that time.
newbie
Activity: 41
Merit: 0
July 12, 2012, 09:36:24 AM
Well it seems like I forgot to make swig, but now when I do that I get this:

Code:
BlockUtils.h:326: Warning 472: Overloaded method AddressBookEntry::AddressBookEntry(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:414: Warning 509: Overloaded method BtcAddress::addTxIO(TxIOPair &) effectively ignored,
BlockUtils.h:413: Warning 509: as it is shadowed by BtcAddress::addTxIO(TxIOPair *).
BlockUtils.h:413: Warning 509: Overloaded method BtcAddress::addTxIO(TxIOPair *,bool) effectively ignored,
BlockUtils.h:414: Warning 509: as it is shadowed by BtcAddress::addTxIO(TxIOPair &,bool).
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BtcUtils.h:956: Warning 472: Overloaded method BtcUtils::verifyProofOfWork(BinaryDataRef,BinaryDataRef) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
g++  -I"/usr/include/python`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`" -c -O2 -pipe -fPIC  -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS  -lpthread  CppBlockUtils_wrap.cxx
g++ -shared -lpthread  UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a "/usr/lib/libpython`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`.a" CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
g++: error: /usr/lib/libpython2.7.a: No such file or directory
make: *** [swig] Error 1

Which is strange since I've never had a problem with python before and I haven't used it outside of Armory in quite awhile. I'll try reinstalling it and see what happens.
edit: I reinstalled all the python packages, but I'm still getting the same error. For some reason I always seem to have these issues with Fedora.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
July 11, 2012, 09:53:11 PM
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
    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
    __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

Have you upgraded recently?  Do you compile it yourself?  There's a suspicious error in that output that looks like you are either using pre-0.80, or you upgraded the code base but didn't recompile it.

Versions prior to 0.80 did not handle the blockchain splitting at 2 GB.  That split happened yesterday, and all older versions of Armory will no longer work (well, offline mode will still work).

So far, all similar complaints have been users who hadn't upgraded, and no one who has upgraded has complained to me yet.  So I'm betting this is it Smiley
newbie
Activity: 41
Merit: 0
July 11, 2012, 09:46:56 PM
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
    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
    __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
legendary
Activity: 2940
Merit: 1333
July 11, 2012, 02:22:03 PM
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.
legendary
Activity: 2128
Merit: 1073
July 11, 2012, 02:05:08 PM
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).
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
July 11, 2012, 02:00:58 PM

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.
legendary
Activity: 2940
Merit: 1333
July 11, 2012, 01:36:29 PM
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
legendary
Activity: 2940
Merit: 1333
July 11, 2012, 01:07:13 PM
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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
July 11, 2012, 12:41:29 PM
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?
legendary
Activity: 2940
Merit: 1333
July 11, 2012, 11:46:01 AM
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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
July 11, 2012, 08:16:49 AM
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.
legendary
Activity: 2940
Merit: 1333
July 11, 2012, 05:08:18 AM
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...
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
July 10, 2012, 10:11:27 PM
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.
sr. member
Activity: 369
Merit: 250
July 09, 2012, 03:31:22 PM
...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.
sr. member
Activity: 312
Merit: 250
July 09, 2012, 02:03:52 PM
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
sr. member
Activity: 312
Merit: 250
July 09, 2012, 01:55:22 PM
I think should have an option to set any exchange we want.
sr. member
Activity: 294
Merit: 250
Bitcoin today is what the internet was in 1998.
July 09, 2012, 01:42:54 PM
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 %?
sr. member
Activity: 312
Merit: 250
July 09, 2012, 01:20:22 PM
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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
July 08, 2012, 09:01:43 PM
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..
Jump to: