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

There's a lot of system libraries that Armory depends on.  I can't statically compile all of them.  At least, all these libraries are in the standard repos which are generally widely used, and downloaded with authentication by the package manager.

Also, I don't want a 200 MB git repo by including all these libraries, especially OS-specific ones.  I included crypto++ due to similar problems as this one, but that was a nice compact C++ library.  Maybe I can get the same from python-dev?  I never actually looked at how much source code it is or how much of a pain it is to compile (in all OS)

It doesn't change the fact that my makefile is crappy.  But at least 98% of the problems would go away.  Hmm...

Hmmm, security wise you may consider supplying your own python-dev lib?

Edit: should have also said the obvious, this would obviate the need for searching for it too.

Want to make 0.5 BTC?  It's gotta be much less complicated than I'm making it.

https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/Makefile

I mentioned it a few posts up:  the issue is python-dev.  I need it static-compiled into the project, but I need it to autodetect the location of it, and switch to the .so if the .a does not exist.   I know that Makefile is terrible -- I don't do Makefiles or bash scripting... I did whatever I could to make it work, but it's clearly not very portable...

I can do makefile stuff ...

I really like the way bounties are handled at i2p project:

http://www.i2p2.de/bounties.html

Maybe a page like that would be cool. You could make a list of things that need to get done. Users like myself can donate to the bounties they are most interested in. Devs currently working on the project get listed, including collaborative projects. And once it makes it to the client the devs get paid.

Seems very efficient to me.

Welcome back!
In BTC the usage of "private keys" only (PINs) is a severe security hole indeed.

That's why normal banks demand PIN and TAN for each transaction (2-factor).
The TAN is often transmitted by SMS: mTAN = mobile TransActionNumber.
This method is fast, due to its second way extremely secure and easy to use. No "google-auth".

Some BTC markets (Bitcoin.de) provide the same (PIN + mTAN) for the online wallets of their costumers.
Easy and efficient. Enough to enter a SMS-capable phone number and we are quite sure there.
You might call it a centralized server.

For local wallets this cannot be done by changing the blockchain adding the phone somehow to the private keys.
Impossible for the so called peers/nodes/clients/miners to call such a number if needed to validate a tx.

And a thief of private keys (stolen wallet) might be able to change a changeable phone number...
So SMS-mTAN or other 2-factor-auth seems not possible in the public p2p blockchain case.

I looked at etotheipis BIP draft #10 Multi-Sig Transaction Distribution, created: 28-10-2011
https://en.bitcoin.it/wiki/BIP_0010

Since (also in the example) writing there only about transactions "with more than one recipient address" I did not understand it.
IMHO one or more signatures are needed for disposals of the owner/sender only and always, regardless which and how many recipients/transactions.
What we could do insofar with Armorys online/offline wallets is within the private sphere quite another thing.  Could be provided by any user-client-app. Blockchain not involved.

I would also like to pass along my gratitude!

Armory is great!

totally agree.

i also met Alan over the weekend for the first time and he's as nice in person as he is here. 

totally expected.

I know we all tell you this every day, but thank you very much for the awesome work you are doing. Armory is the absolute best piece of software to manage Bitcoins, and the support you provide is 10000000000 times better than the support provided for 99% of commercial software.

I procrastinated a very much deserved donation to Armory too long - I'm doing it ASAP!

The subset of features used in offline mode are rarely updated.  I change some of the flow (try to remove unnecessary question boxes), and add a couple convenience features, but nothing you need.  There won't be a "required" update of the offline computer until the new wallet format is implemented, but that may actually still work fine with old wallets -- only needed for new wallets.

Sorry for this off-topic question.

I use Armory offline in Ubuntu 10.04, and I did not update my offline bundle to the latest version - is this a problem? What benefits would I get from upgrading?

Thanks

I am in total agreement with Gavin about this.  For anything substantial, bounties are a really terrible way to get work done.  However, I have actually had great success with bounties for things like this, which are

(1) Extremely well-defined
(2) A trivial amount of effort for someone knowledgeable (1-3 days)
(3) I'm the only one offering the bounty and I decide (not by consensus) who gets it, and I'm not a stickler about it.

For anything that is more than a couple day's work and without well-defined exit criteria, bounties are a terrible way to go.   Especially when it's a long project and project direction could change mid-way, etc.  In this case, it's clear what needs to happen, and if I end up with something that's not exactly right, I'll still pay the 0.5 BTC.

Instead of a bounty, how about the model Gavin (or was it Jeff) mentioned during one of the panels... find someone who can do it and contract directly with them. If you give a price that it's worth for you, I'm sure someone around here knows a makefile expert who would be interested. Maybe you could offer a tiny bounty for the first person to get you in contact with a makefile developer who contracts with you. At least that's a simple and well defined requirement.

Or maybe I'm over thinking this and a bounty would work fine for this purpose.

I should start a bounty to have someone with real Makefile experience rework that Makefile.  I know it sucks.  It works on Ubuntu 12.10-, and requires only small deviations for other OS, but I don't know how to do it "right". 

The only issue appears to be python-dev.  In Ubuntu 13.04, the files end up somewhere unexpected.  In other OS, the static library is not available.  But I need it to compile the static library when available, for distribution purposes (or else it fails to start on many systems when installed from my .deb).  If it doesn't do that by default, I'll inevitably create non-working .deb packages and go through the whole release process not realizing I did it.

So, anyone want 0.5 BTC?  This can't possibly take a long time to do, it just needs someone who has any experience with Makefiles.  If the python-dev library is already installed, it should (1) Try to compile using the static library (.a), (2) If the static library is not available, just use the dynamic (.so) library, and (3) Do so in the "correct" manner to find these things, not hardcoding paths as I have basically done.

I switched from Ubuntu to Debian this weekend and tried to recompile Armory. It failed, of course. I didn't need to install any extra packages this time but I did need to edit line 15 to:

PYVER += 2.7

I got rid of all that other junk because it just wasn't working, and I know what python version I'm running, so I can just plug it in manually.

there you go, its a good solution to DITCH a deprecated OS.

This damn wallet doesn't work anymore! It was running fine last week but now it crashes before it even start's up. I already went to the website and downloaded the latest 64Bit version (Windows). Same problem. I need access to my coins. This sucks!!!!!!!!!!!!!!!!!!

Edit: I've installed the Linux version in a VM and loaded the backups. Got my coins back...it still sucks -.-

thats because no such tag exists

This is the part I'm talking about:

seth@LockBox:~/BitcoinArmory$ git tag -v v0.88.1-beta
error: tag 'v0.88.1-beta' not found.
seth@LockBox:~/BitcoinArmory$

its working!
is just saying you didnt trust this key