Bitcoin Forum
December 05, 2016, 08:40:10 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 ... 232 »
  Print  
Author Topic: Armory - Discussion Thread  (Read 481841 times)
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
January 14, 2013, 09:46:01 PM
 #1741

I implemented a crappy version of listtransactions that probably doesn't behave much like the bitcoind version, but it is just as confusing (so at least there's something in common).  For each incoming transaction it gives one entry per txOut you own.  For each outgoing transaction, it gives one entry for the total output value (i.e. for your own contributions minus change) and one entry for each non-change receiving address (which can be sending or receiving depending on whose/howmany outputs there are).  I'm sure people will try to use it and complain.  Then I'll fix it to match what they were expecting...

However, I added my own version of listtransactions called "getledger" and "getledgersimple".  It has one entry per transaction and is a pure partition of your wallet activity.

For each transaction "getledgersimple" returns:
  • "direction" is {'send', 'receive', 'toself'}.  To self is any tx for which you own all inputs and outputs.
  • "amount" is the total BTC exchanged (inputs - outputs + change + fee)).  It is always positive.  For example, if I send someone 10 BTC with 0.05 BTC fee and 5 BTC change to myself, "amount is 10".  For to-self tx, change address is assumed to the be the address with the higher generation order (since the wallets always generate change addr after recipients are selected)
  • "netdiff" is the change in your wallet balance induced by the transaction.  For the above transaction, netdiff would be -10.05. If you send money to yourself, netdiff will be the negative of the fee paid.  Summing all returned "netdiff" values returned will give you your wallet balance
  • "fee" is the fee paid for the transaction.  It is always positive, and the caller only has to pay attention to it on outgoing tx if they want (and make it negative).  Or they may want to know how much fee was paid to determine how safe an incoming tx is. (returns zero in bitcoind for incoming transactions)
  • "txsize" is size in bytes of the tx (included for same reason as fee)
  • "firstrecip" is the first "target" of the transaction.  For simple transactions this is your own address for incoming tx, or the other person's address for outgoing tx
  • "changerecip" is the first address that may reasonably be interpretted as change.  Someone sending you money as part of a multi-output tx, this will return the first output address that isn't yours.  Or if the transaction is outgoing, it's the first txout with address in your wallet.

For each transaction "getledger" returns the same as the simple one, but with the following additional output.  This accommodates users that want to handle more-complex, multi-recipient transactions and kind of just want all the information:
  • "senderme":  list of all [address,value] pairs on the input side that are part of this wallet
  • "senderother" list of all [address,value] pairs on the input side that are not part of this wallet
  • "recipme":  list of all [address,value] pairs on the output side that are part of this wallet
  • "recipother" list of all [address,value] pairs on the output side that are not part of this wallet


mav originally setup the thing to handle watching-only wallets only.  I will eventually upgrade it to work on any wallet, and maybe even multiwallet.  But for now it's actually starting to have usefulness, and I'll hold off digging into too many more calls until I get some feedback.   For now, I want to dig into fixing the instability issues I referred to earlier with blocksplits and simultaneous blocks.

P.S. -- This is all on the armoryd branch, and you must have a armoryd.conf file in your Armory home dir specifying "username:password", then use that in the URL for the connecting client.  






Example of simple and nonsimple getledger calls:

getledgersimple
Code:
$ python armoryd.py --testnet getledgersimple
[
    {
        "amount": 10.0,
        "blockhash": "00000000067a1fb9e9634cf2b39f1728392882475c7fcda32db30724584707b6",
        "blocktime": 1357795104,
        "changerecip": "mqMK7xSkrNK5auTzHEJBndtxJiRZW6HMHK",
        "comment": "",
        "direction": "received",
        "fee": 0.00050000000000000001,
        "firstrecip": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
        "netdiff": 10.0,
        "txid": "e6582b82cf24888a86aee8b819a8e32f34033f2870d399dd0bcc1b9331331370",
        "txsize": 292,
        "txtime": 1357795104
    },
    {
        "amount": 0.25,
        "blockhash": "000000004a769f6db14bdff5374ce3790d756d4f49770a0f2203087133d3ec3a",
        "blocktime": 1358106188,
        "changerecip": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
        "comment": "",
        "direction": "sent",
        "fee": 0.00050000000000000001,
        "firstrecip": "n1NWE4QPX7FbxeBQaPhbr6rEwvHR1RjBWT",
        "netdiff": -0.2505,
        "txid": "747f357c8287da26fcd423e45974e2e1ba367216f0115d15eb2cdd66c4abc767",
        "txsize": 258,
        "txtime": 1358106188
    },
    {
        "amount": 13.5,
        "blockhash": "00000000db486e1907269bdff3fd0b62b1a8c7c51f214e89e57650403922bab9",
        "blocktime": 1358113003,
        "changerecip": "n1Q3DWs7pH5uvME4o3rDYDTd4ZgiqSPCUx",
        "comment": "",
        "direction": "toself",
        "fee": 0.00050000000000000001,
        "firstrecip": "mgdsaZL9WKbKrfxGRw8Rpi9FdRuaMMyyYJ",
        "netdiff": -0.00050000000000000001,
        "txid": "f53bdc6f3a1b573d2efa892591140caf5c88739c42248efdacfb0fd97da4287b",
        "txsize": 618,
        "txtime": 1358113003
    }
]

getledger

Code:
   {
        "amount": 10.0,
        "blockhash": "00000000067a1fb9e9634cf2b39f1728392882475c7fcda32db30724584707b6",
        "blocktime": 1357795104,
        "changerecip": "mqMK7xSkrNK5auTzHEJBndtxJiRZW6HMHK",
        "comment": "",
        "direction": "received",
        "fee": 0.00050000000000000001,
        "firstrecip": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
        "netdiff": 10.0,
        "recipme": [
            {
                "address": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
                "amount": 10.0
            }
        ],
        "recipother": [
            {
                "address": "mqMK7xSkrNK5auTzHEJBndtxJiRZW6HMHK",
                "amount": 14.499499999999999
            },
            {
                "address": "mi6hyHi3zVPx8sgB6wuf6cKkXPswa5NFDf",
                "amount": 0.5
            }
        ],
        "senderme": [],
        "senderother": [
            {
                "address": "mqy7NzHrcFLu32YK1ow6L4V2YC4PFCChHB",
                "amount": 25.0
            }
        ],
        "txid": "e6582b82cf24888a86aee8b819a8e32f34033f2870d399dd0bcc1b9331331370",
        "txsize": 292,
        "txtime": 1357795104
    },
    {
        "amount": 0.25,
        "blockhash": "000000004a769f6db14bdff5374ce3790d756d4f49770a0f2203087133d3ec3a",
        "blocktime": 1358106188,
        "changerecip": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
        "comment": "",
        "direction": "sent",
        "fee": 0.00050000000000000001,
        "firstrecip": "n1NWE4QPX7FbxeBQaPhbr6rEwvHR1RjBWT",
        "netdiff": -0.2505,
        "recipme": [
            {
                "address": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
                "amount": 9.7494999999999994
            }
        ],
        "recipother": [
            {
                "address": "n1NWE4QPX7FbxeBQaPhbr6rEwvHR1RjBWT",
                "amount": 0.25
            }
        ],
        "senderme": [
            {
                "address": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
                "amount": 10.0
            }
        ],
        "senderother": [],
        "txid": "747f357c8287da26fcd423e45974e2e1ba367216f0115d15eb2cdd66c4abc767",
        "txsize": 258,
        "txtime": 1358106188
    },
    {
        "amount": 13.5,
        "blockhash": "00000000db486e1907269bdff3fd0b62b1a8c7c51f214e89e57650403922bab9",
        "blocktime": 1358113003,
        "changerecip": "n1Q3DWs7pH5uvME4o3rDYDTd4ZgiqSPCUx",
        "comment": "",
        "direction": "toself",
        "fee": 0.00050000000000000001,
        "firstrecip": "mgdsaZL9WKbKrfxGRw8Rpi9FdRuaMMyyYJ",
        "netdiff": -0.00050000000000000001,
        "recipme": [
            {
                "address": "n1Q3DWs7pH5uvME4o3rDYDTd4ZgiqSPCUx",
                "amount": 1.7490000000000001
            },
            {
                "address": "mgdsaZL9WKbKrfxGRw8Rpi9FdRuaMMyyYJ",
                "amount": 13.5
            }
        ],
        "recipother": [],
        "senderme": [
            {
                "address": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
                "amount": 9.7494999999999994
            },
            {
                "address": "n34NnSRwMTUaHnx4R5ykmcjecoDn8uVXUA",
                "amount": 3.25
            },
            {
                "address": "n34NnSRwMTUaHnx4R5ykmcjecoDn8uVXUA",
                "amount": 2.25
            }
        ],
        "senderother": [],
        "txid": "f53bdc6f3a1b573d2efa892591140caf5c88739c42248efdacfb0fd97da4287b",
        "txsize": 618,
        "txtime": 1358113003
    }
]


P.S -- As far as I can tell, the ultra-high-precision values/amounts are due to the python-JSON library display.  It's a display issue caused by the fact that someone a long time ago decided the JSON interface should transport floats for amounts, instead of strings or satoshis, and the JSON library just prints the raw floats.  Luckily, double-precision values have enough precision that this will never screw up from a simple round() call.  But clearly, this is sub-optimal.  And since I'm using a built-in json.dumps call in python, I can't really modify the behavior.  

I'm thinking I could add a "setamtcoding COIN" or "setamtcoding STRING" to tell the RPC server to always encode values as longs (in Satoshis) or string values with at most 8 decimal places.  I could also make the last argument to every RPC call be "COIN" or "STRING" to tell the server what to output for that particular call.  But that seems kind of messy.

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

Posts: 1480927210

View Profile Personal Message (Offline)

Ignore
1480927210
Reply with quote  #2

1480927210
Report to moderator
1480927210
Hero Member
*
Offline Offline

Posts: 1480927210

View Profile Personal Message (Offline)

Ignore
1480927210
Reply with quote  #2

1480927210
Report to moderator
1480927210
Hero Member
*
Offline Offline

Posts: 1480927210

View Profile Personal Message (Offline)

Ignore
1480927210
Reply with quote  #2

1480927210
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480927210
Hero Member
*
Offline Offline

Posts: 1480927210

View Profile Personal Message (Offline)

Ignore
1480927210
Reply with quote  #2

1480927210
Report to moderator
1480927210
Hero Member
*
Offline Offline

Posts: 1480927210

View Profile Personal Message (Offline)

Ignore
1480927210
Reply with quote  #2

1480927210
Report to moderator
1480927210
Hero Member
*
Offline Offline

Posts: 1480927210

View Profile Personal Message (Offline)

Ignore
1480927210
Reply with quote  #2

1480927210
Report to moderator
mav
Full Member
***
Offline Offline

Activity: 168


View Profile
January 15, 2013, 03:15:25 AM
 #1742

I would have thought there's away to convert those floats to the correct decimal values, although maybe that was just a client... I'll look into it tonight cause those floats are horrid! Also I'll look at bitcoind listtransactions output if I get a chance.

Sounds like it's going well so far for the most part.
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
January 15, 2013, 04:07:11 AM
 #1743

I would have thought there's away to convert those floats to the correct decimal values, although maybe that was just a client... I'll look into it tonight cause those floats are horrid! Also I'll look at bitcoind listtransactions output if I get a chance.

Sounds like it's going well so far for the most part.

The problem is that those values should be transferred as either long-integer (satoshis) or string... in which case the value can be coded exactly.  But someone decided that they'll have bitcoind should transfer them as non-exact floating point (doubles), and 0.0005000000001 for the fee is the closest float that can be encoded.  I'm fairly confident it's really just a display issue, not an armoryd.py issue.

Luckily, round()'ing will always work because doubles have enough bits to represent 8 places without rounding errors.  But I wouldn't mind if we can find a way to have the json library print out the rounded version.  I noticed in the few lines of code I stole from jgarzik (and now part of armoryd.py), he defined a "UniversalEncoder" and was able to pass it to the json.dumps() method to explain how to handle decimal.Decimal objects.  Though I mostly removed that in favor of following  Proper money handling in JSON-RPC, even though it should all give the same answers (it's less characters and more readable).  Either way, maybe there's a hint there about how to tell UniversalEncoder to print "float" values.

Anyone think it's a bad/good idea to do what I recommended:  "python armoryd.py setamountencoding COIN" or "python armoryd.py setamountencoding STRING" to set the daemon to transfer long-int-satoshis or exact strings, respectively?  That way default behavior matches bitcoind that most are expecting, but they have the option to change it with one line at the top of their script.

-----

By the way (mostly for mav), I added the capability for armoryd.py to detect if there's already an instance of armoryd.py running, and if there is, it will connect to it, pass the command line arguments to it, print the reply, then disconnect.  I believe that's exactly what bitcoind does.

Also for anyone who wants to use this, you need to have a "/home/username/.armory/armoryd.conf" file or "C:\Users\username\AppData\Roaming\Armory\armoryd.conf" in order to use it.  The file contains a single line:  "username:password".  Make sure to "chmod 600 armoryd.conf"


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

Activity: 168


View Profile
January 15, 2013, 06:45:22 AM
 #1744

Have a look at this gist for my idea about using Decimal values (or converting ints to decimals first) and then dumping in the json so it doesn't have floaty rounding display happening

https://gist.github.com/4536693

Will get back in a few hours with the other stuff I'm looking into.

edit: I am inclined to agree with you on the using integers and correct money handling rather than shitty floats or even decimals. At least in this case, when the value is received and loaded into a Decimal, it will be displayed and loaded completely accurately and not rely on the client correctly implementing rounding, which we cannot assume. As I have previously stated, I think following bitcoind api where possible is best since it makes for the least dicking around when migrating to use armory from bitcoind.

edit2: The option to set integer / decimal / string encoding is a great idea. Don't forget to allow users to set it back to the default for decimal if they desire.

edit3: I had a crack at getting the listtransactions data for the various scenarios you describe (and thus the 'way it works'), however I couldn't get any results. Frustratingly, I got raw transactions to sign (which is the second-last step of many) and then the last step is to broadcast the transaction, but my transactions were always getting rejected. I've got my progress thus far well documented and is definitely repeatable so I might try to work it out later in the week. It's worth asking on the development subform for clarification on the way the listtransactions call works, they will hopefully be able to answer it. Anyway I was creating raw transactions to match your scenarios based off this guide and testnet-in-a-box - https://people.xiph.org/~greg/signdemo.txt
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
January 15, 2013, 05:59:49 PM
 #1745

edit3: I had a crack at getting the listtransactions data for the various scenarios you describe (and thus the 'way it works'), however I couldn't get any results. Frustratingly, I got raw transactions to sign (which is the second-last step of many) and then the last step is to broadcast the transaction, but my transactions were always getting rejected. I've got my progress thus far well documented and is definitely repeatable so I might try to work it out later in the week. It's worth asking on the development subform for clarification on the way the listtransactions call works, they will hopefully be able to answer it. Anyway I was creating raw transactions to match your scenarios based off this guide and testnet-in-a-box - https://people.xiph.org/~greg/signdemo.txt

I'm not sure I understand what you tried.  Were you trying to test creating unsigned transactions and then sign and broadcast with Armory?   Here's what I would do to test (and maybe this is what you did):  open ArmoryQt.py, create a new wallet, send it some money (testnet would be fine).   Create watching-only copy and save it in a different directory.  Now run armoryd.py on that wallet, and use the "sendtransaction" or "sendmany" to create the unsigned transaction.  Then you can go back to ArmoryQt and use the "Offline Transactions" button and select "Sign and/or Broadcast".  You can copy it into the window* and it should immediately recognize it, and allow you to examine and sign it.   Since you're online, you can also broadcast it right away, but I'm not sure why I didn't try that.  I got through signing with my testnet wallet while testing, and everything looked perfect, up to that point.

Also, I will integrate the cli_sign_script.py code into armoryd.py so that signing can be enabled, too.  My only question is how to send the passphrase to JSON-RPC... is it sent cleartext over the socket/JSON interface?  I looked at the Bitcoin code, and it appears that's what they do, though I'm not positive.  This seems okay for localhost (though I don't like it), but not for any remote connections.  Or maybe it just shouldn't be allowed on remote connections (actually, for now there are no remote connections, so I guess it doesn't matter).



*What I found is that if you use armoyd to send the command, it spits out the python-formatted string:  you cannot just copy this into ArmoryQt, because it has "\n" raw characters in there, etc.  You can open python and type "pring <copy string here>" and it will print it out with proper formatting.  Then you can copy it into ArmoryQt.

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

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

Activity: 1428


Core Armory Developer


View Profile WWW
January 16, 2013, 01:05:40 AM
 #1746


Anyone still having persistent crashing problems in Windows?  (or Linux?)

I finally fixed the two readBlkFileUpdate() bugs.  I made an elaborate test by taking slices of blk files, and copying them into a fake blkfile directory between readBlkFileUpdate calls.  In the end it was a tiny fix, but it should've resolved a variety of issues -- I'm hoping also the Windows crashing issue...

I created a testing version with the fix and even took it to the offline system to get signatures on the sha256 hashes.  As usual, if you are testing in Linux, just switch to the "testing" branch.   

Testing version 0.87.1-testing for Windows 64-bit
Testing version 0.87.1-testing for Windows 32- and 64-bit
Testing version 0.87.1-testing SHA256 hashes of installers

I've had Windows crashing before, but it has sometimes taken days between crashes, so I need someone who has more-frequent crashes to help test it.  I'd say there's a 50-50 chance it's fixed... but if not I have another idea...

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

Activity: 168


View Profile
January 17, 2013, 06:25:31 AM
 #1747

edit3: I had a crack at getting the listtransactions data for the various scenarios you describe...[/url]

I'm not sure I understand what you tried.  Were you trying to test creating unsigned transactions and then sign and broadcast with Armory?...

I tried getting some info about bitcoind listtransactions behaviour so you had something to go off when emulating it. It was nothing to do with armory. Actually I haven't even got the latest version of armory to look at yet, been crackers busy lately, but will definitely try to do so on the weekend.

Offline transactions with bitcoind are actually quite interesting. I still prefer armory because of the deterministic and watch-only wallet features, that's really a remarkable feature to have.
wachtwoord
Legendary
*
Offline Offline

Activity: 1484



View Profile WWW
January 17, 2013, 08:01:21 PM
 #1748

@wachtwoord
The alternative you describe is really not much better than just maintaining an encrypted wallet on your hot computer.  What it prevents is someone who has gotten remote access to your machine and manually digging around your filesystem looking for wallet files.  That's not to say that such things don't happen, but I believe the real threats are viruses that get on your computer and siphons off data and send it back to "home base" when it finds it (it will farm the data and send it back the next time it's online).  In this case it probably doesn't even have to send any data back... it just reads your wallet when decrypted and creates a transaction sending all BTC to its owner the next time it's online.

Any computer with access to the internet is vulnerable to these viruses.  You can get them from various exploits usually relating to your browser, or opening PDF/.xls documents with embedded exploits, etc.  However, in order to compromise a truly-offline computer, there's a couple orders-of-magnitude more work for the attacker to do.  They must (1) find a way to hide data on your USB key that (2) exploits an auto-run vulnerability when plugged into the offline computer, and then (3) be able to automatically find the data and copy it back, hidden, on the USB key to get it back to the offline computer.  And these exploits are much more complicated when they don't even know what OS the offline system is.  And if I can find another way to transfer data between systems not using USB keys, then this would even an order of magnitude better...

I would look into this idea posted by N.Z..   It's a bit more work but is definitely a very reasonable solution for a single-computer setup (in fact, I've been thinking about bundling the tails packages like N.Z. suggested, to make this easier).  This means that your wallet only ever touches this sandbox that has no access to internet, and is reset to default configuration on every boot.

As for question 3 (paper backups), you just said in question 2 that you believe flash storage is frail.  This is exactly why you make paper backups.  If you print a paper backup and put it in a safe-deposit box or fold it into a book on your bookshelf, it will still be readable 20+ years from now . It doesn't even have to survive "well", as you could pull the data out of a terribly-faded copy with a bit of work.  I mean, you've seen books that are 50+ years old and their pages are still readable.

Now compare that to any kind of digital media.  You can drop a flash drive, or sit on it or bend it, or put it too close to a magnet, or it just decays and it's no longer usable.  What's your confidence level that even a well-treated USB drive sitting in a metal box will still work 5 years from now?  20 years?    Even CDs and DVDs have expected lifetimes of 2-10 years, but that varies widely depending on lots of factors.  With the paper backup, unless it physically burns to ash, you know it will still provide the data you need to recover your wallet in 20 years.... probably much longer than that.


Thanks a lot for your reply. I have attempted to follow N.Z.'s method but have trouble comprehending how to make it work exactly so I created a thread and PM'ed N.Z. https://bitcointalk.org/index.php?topic=137091.0
Hopefully I'll be able to get this working and then I'll be much more secure Smiley

About the paper backups: I still think leaving paper backups is a huge security risk (I guess people will start searching for these). If someone finds my paper backup they can take all my coins while this is not the case for my flash drive (wallet files are encrypted!). With respect to the frailty of USB's, I have currently five nackups on different media and plan to backup it more when the media start failing.

Daily Anarchist
Hero Member
*****
Offline Offline

Activity: 615



View Profile WWW
January 19, 2013, 05:27:19 AM
 #1749

Fedora 64 bit make command gives me this error. I know this issue was addressed by mac osx builds, but was it ever addressed for linux builds?

Quote
Quote
$ make
cd cppForSwig; make swig
make[1]: Entering directory `/home/seth/BitcoinArmory/cppForSwig'
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[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

Discover anarcho-capitalism today!
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
January 19, 2013, 05:34:00 AM
 #1750

Fedora 64 bit make command gives me this error. I know this issue was addressed by mac osx builds, but was it ever addressed for linux builds?

Quote
Quote
$ make
cd cppForSwig; make swig
make[1]: Entering directory `/home/seth/BitcoinArmory/cppForSwig'
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[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2
install python?

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
January 19, 2013, 05:35:21 AM
 #1751

Fedora 64 bit make command gives me this error. I know this issue was addressed by mac osx builds, but was it ever addressed for linux builds?

Quote
Quote
$ make
cd cppForSwig; make swig
make[1]: Entering directory `/home/seth/BitcoinArmory/cppForSwig'
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[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2
install python?

No that's not it.  It's a one-line makefile fix, but I needed someone who had this problem to help me test the fix for it.  I'll commit something to the "armoryd" branch (which is my current development branch), in about 10 minutes.  If that doesn't work, I'll just tell you how to fix it Smiley

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

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

Activity: 1428


Core Armory Developer


View Profile WWW
January 19, 2013, 05:54:24 AM
 #1752

No that's not it.  It's a one-line makefile fix, but I needed someone who had this problem to help me test the fix for it.  I'll commit something to the "armoryd" branch (which is my current development branch), in about 10 minutes.  If that doesn't work, I'll just tell you how to fix it Smiley

Gah!  Why's it so damned hard to check whether a file exists from within a makefile?  I can't use my old bash trick because it's a dynamic filename based on DEPSDIR.

The solution is to change "STATICPYTHON" to point to the libpython2.x.so file instead of the libpython2.x.a.   I want something like (Makefile:28) --

Code:
   SWIG_INC     += -I"$(DEPSDIR)/include/python$(PYVER)"
   STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"

   ifneq (exists, $(shell [ -d $(STATICPYTHON) ]  && echo exists ))
      STATICPYTHON = "$(DEPSDIR)/lib/libpython$(PYVER).so"
   endif

But it doesn't seem to like the $(VAR) inside the shell...

You know the fix.  If you know a good way to resolve this, then please let me know.

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

Activity: 615



View Profile WWW
January 19, 2013, 06:01:59 AM
 #1753

I'm confused by what should be added/replaced. This is what my Makefile looks like:

Quote
Quote
25    SWIG_INC     += -I"/usr/include/python$(PYVER)"
 26    STATICPYTHON +=   "/usr/lib/python$(PYVER)/config/libpython$(PYVER).a"
 27 else
 28    SWIG_INC     += -I"$(DEPSDIR)/include/python$(PYVER)"
 29    STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"
 30
 31
 32    # A failed attempt at auto-detecting .a file and using .so if .a DNE
 33    #PYTHONA = "$(DEPSDIR)/lib/libpython$(PYVER).a"
 34    #ifeq ($(wildcard $(PYTHONA)),)
 35       #STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).so"
 36    #else
 37       #STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"
 38    #endif
 39 endif
 40

Can you give me a replace code with code for simplicty?

Discover anarcho-capitalism today!
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
January 19, 2013, 06:03:17 AM
 #1754

I'm confused by what should be added/replaced. This is what my Makefile looks like:

Quote
Quote
25    SWIG_INC     += -I"/usr/include/python$(PYVER)"
 26    STATICPYTHON +=   "/usr/lib/python$(PYVER)/config/libpython$(PYVER).a"
 27 else
 28    SWIG_INC     += -I"$(DEPSDIR)/include/python$(PYVER)"
 29    STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"
 30
 31
 32    # A failed attempt at auto-detecting .a file and using .so if .a DNE
 33    #PYTHONA = "$(DEPSDIR)/lib/libpython$(PYVER).a"
 34    #ifeq ($(wildcard $(PYTHONA)),)
 35       #STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).so"
 36    #else
 37       #STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"
 38    #endif
 39 endif
 40

Can you give me a replace code with code for simplicty?

Sorry.  Modify line 29 at the end to .so instead .a

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

Activity: 615



View Profile WWW
January 19, 2013, 06:05:40 AM
 #1755

No dice.

Quote
Quote
g++: error: /usr/lib/libpython2.7.so: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

Discover anarcho-capitalism today!
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
January 19, 2013, 06:06:49 AM
 #1756

No dice.

Quote
Quote
g++: error: /usr/lib/libpython2.7.so: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

Oh, have you installed python-dev?

Specfically, make sure you have all the dependencies listed on the compile-from-source page:

http://bitcoinarmory.com/index.php/building-armory-from-source

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

Activity: 615



View Profile WWW
January 19, 2013, 06:07:59 AM
 #1757

For what it's worth, a couple of months ago somebody recommended removing a large chunk of line 15 and it allowed it to fully compile. But since I'm doing a fresh install I thought it would be a better idea to run it by you first.

Discover anarcho-capitalism today!
Daily Anarchist
Hero Member
*****
Offline Offline

Activity: 615



View Profile WWW
January 19, 2013, 06:09:53 AM
 #1758

It's python-devel for us Red Hat folk, but yes it's installed, along with the rest of the dependencies.

Quote
Quote
$ yum list python-devel
Loaded plugins: langpacks, presto, refresh-packagekit
fedora/18/x86_64/metalink                                |  13 kB     00:00     
updates/18/x86_64/metalink                               | 8.4 kB     00:00     
Installed Packages
python-devel.x86_64                    2.7.3-13.fc18                     @fedora
Available Packages
python-devel.i686

Discover anarcho-capitalism today!
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
January 19, 2013, 06:11:02 AM
 #1759

For what it's worth, a couple of months ago somebody recommended removing a large chunk of line 15 and it allowed it to fully compile. But since I'm doing a fresh install I thought it would be a better idea to run it by you first.

Line 15 is what makes this makefile work regardless of what python version you have installed.  Unless you have a non-standard python installation.

What shows up when you type "ls -la /usr/lib | grep libpython"?  

You can change line 29 to just point to whatever .a or .so is there.  

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

Activity: 615



View Profile WWW
January 19, 2013, 06:13:06 AM
 #1760

For what it's worth, a couple of months ago somebody recommended removing a large chunk of line 15 and it allowed it to fully compile. But since I'm doing a fresh install I thought it would be a better idea to run it by you first.

Line 15 is what makes this makefile work regardless of what python version you have installed.  Unless you have a non-standard python installation.

What shows up when you type "ls -la /usr/lib | grep libpython"?  

You can change line 29 to just point to whatever .a or .so is there.  

That command gives me nada.

Discover anarcho-capitalism today!
Pages: « 1 ... 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 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 ... 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!