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

Windows Search is based on preindexation performed by a back-end service. New folders may not be parsed right away in the temporary db.

You have to indicate both header and lib folder to msvc unless you install a pay version. You can register these folders globally in msvc options rather than just link them to each of your projects. Not sure how it's done is vc11 express. Ima look it up

Ugh!  Why is Windows search so terrible?!  I did a full "search" of the C-drive and it came up with nothing.  But I just followed the path you mentioned and I found it.  Alright, I'll manually add that to the "Additional Include Directories" and see where that gets me.

C:\WinDDK\7600.16385.1\inc\atl71 -> this is my include folder for all header files
C:\WinDDK\7600.16385.1\lib\ATL\i386 -> this is where the libs are. I picked i386 cause leveldbwin only support x86. However x64 binaries and libs are available if you wanna try a x64 compile.


I'm curious about your install folder, namely its build version (mine is 7600.16385.1 as you can see)

Edit: I'm redownloading the wdk iso to check the installation process. Did you perform a custom or full install? There's only one option needed to install ATL binaries and headers

I just noticed that Armory's website got a redesign.  Looks good.  I'm impatiently awaiting the new version of Armory that will be less RAM intensive, but I assume progress will be going faster now that you're working on this full time. 

I'm curious to know if there is any push to improve the Armory interface? For a user like me it works just fine, but someone who is newer to Bitcoin, I could see how it could be very uninviting.

@ goatpig

I am trying to follow your solution on Windows 7, 32-bit.  Everything has been smooth except for ATL.  I installed the 7.1.0 WDK, but it still can't find atlbase.h.  I have searched the entire harddrive looking for it, but can't find it.  I reinstalled the WDK and rebooted and it's nowhere to be found.  I did some googling and found posts telling me to install the 7.1.0 WDK... I wonder if it has to do with 32-bit OS?  I can't imagine the header file would, but I'm grasping at straws here...  any advice?

Raize, you are welcome to donate it to me.  All donations up until this point have gone to me, not the company, though at some point we will transition the address (and mark it clearly on the website) that future donations will support development (i.e. going to paying salaries of everyone working on Armory).  Up until this point, most people thought their donations were going directly to me for what I've done so far, so I made it clear to the investors that until the specified time I will continue to keep them.  Also because CEOs of startups who have the most equity (the most to gain), tend to also have the lowest salaries.  It's part of the risk I get to take given all the potential upside I have.  Until the company actually starts turning a profit, I'll be getting paid below my market value so that we can contribute more money to these superstar developers for whom we have to compete with the rest of the job market.

I'm not complaining -- I'm doing what I love doing and I am still making enough to be comfortable, so I don't have much to complain about   But donations are still appreciated and remind me how much people like the work I've done. 

Take that for what it's worth.

---

Goatpig -

Want to double-down?  I'll make it 3 BTC if you can take your working project and integrate the latest leveldb with it.  I haven't tried it, and as you said it might just be plug-n-play.  In which case this would be the easiest 1 BTC ever.  Or it may take some work.  But in the interest of optimizing my time, it's worth upping the bounty a bit to get you to investigate that for us   You seem to be quite experienced with C++ and MSVS, so you seem like the right person to send headfirst into this one.

etotheipi,
If you want to close the bounty listed here I would be willing to divert the 5 BTC I pledged to you directly, I didn't realize you were on the cusp of being able to work on Armory full-time or I would have helped participate in investing in you.

Sounds good ... at least the linux build could do with the work, particularly the dynamic lib link stuff was pretty shaky sec. wise last time I looked and we had this discussion ...

And so it begins...

PM me and let me know what you think you can help us with.  By default, we will be trying to do things ourselves with already-paid labor, and that's how we learn anyway.  But if especially if we're bogged down and it's a compact and measurable task we'll consider outsourcing.

We might need help with the Windows build system.  But we also might have figured it out already.  Linux packaging could use some help, but we have a hardc0re linux nerd coming in at the end of the month so I will assume he's got that covered

Does your build system still need work in this next version?

We actually have some money bookmarked for outside help, like what Red Emerald has done in the past.  If we need something that no one on our team knows how to deal with, we may simply offer them some short-term funding at a reasonable hourly rate to help out.  I don't expect us to be doing a lot of that, but it's definitely a "tool" we're keeping in our back pocket.

So when is red emerald going to be joining the armory team

*disclaimer no knowledge of anything that has to do with armory and the company, just speculation*

Regarding LevelDB, I haven't looked at the source too much, however it seems evident that all the system resource and OS talking LevelDB requires is performed by a separate piece of code, confined to the "port" folder of LDB's source. Of what I've seen, it handles threading, atomicity, file access, getting the environment, setting variables and, I suspect, whatever else there is to do on that front. My intuition on this is that as long as you get a proper compile of "port", all the code inside the leveldb/leveldb folder (the db related classes) will compile without errors.

It is true that I don't like leveldbwin's approach, using ATL and  MS's interlocked memory functions to provide environment and atomicity. Ideally you'd like to compile a dll on MS systems, and support x64, so a in house compilation seems like a better long term option. LevelDB uses pthreads, which is easy to compile on msvc, as well as atomics, which vc11 supports natively. I think it won't be too hard to get a proper build going for Windows. I'll be around if you need assistance with that.

As for the bounty, this is my address: 1KPsKCA1VrGdnKqQgrSKZ5M2sEZRP1oUFX

Thank you for contributing to my hookers 'n blow fund =)

Grats!  I'm excited to see the project move forward like this.

Congrats. Love to see Armory live up to its full potential.

Great write up.  Congrats Alan!

[To any of you bitcoin foundation members that haven't voted yet in the final board member election, please consider recognizing Trace Mayer's forward thinking commitment in this, in addition to his other significant qualifications.]

By the way, Coindesk just ran the story, after interviewing me.

http://www.coindesk.com/bitcoin-wallet-armory-raises-600k-seed-funding/

"Super-node" is like having blockchain.info on your own computer.  You will be able to query the balance and UTXO list of any address on the network and get an instant answer without any rescanning (it's all maintained on the fly).  And without contacting any servers.  It is ideal for webservers that are doing lots of Bitcoin processing, and necessary for having encrypted watching-only wallets, so that you don't have to do a long rescan every load (otherwise, your wallet may be encrypted, but it's obvious from the database files which addresses are in your wallets).

However, my original implementation suffered from at least one issue related to LevelDB.  I won't claim that my own code was bugless, but the errors were non-deterministic so I determined it wasn't feasible to continue in the short-term (failed with corruption errors on one run, then succeed on the next run using identical inputs). 

For now, I switched to the "regular full-node" implementation like it was before, which requires rescanning on import/sweep/restore of wallets&addresses.  But now it uses the database to save that data between loads, so that you no longer have to rescan on every load.  Still have a bit of internal testing before I can release a testing version, but it's looking very good so far.

what is supernode supposed to mean?