The video published on the project's main page mentions Dropbox as one of the examples that could be recreated as a distributed system with this project, but I couldn't find any info on the more interesting question: how?

Which of its facilities would be useful for that? Who would store the data? Would it be a separate system which just happens to use ethereum for user authentication, or would it actually has anything to do with data storage? How would the insanse amount of data stored distributedly in a way that it doesn't choke the individual nodes, but would be readily available any time?

Dropbox really stands out of the other example applications and without at least some basic techincal description it sounds like just a marketing stunt... so can we have some more info?

Ahh I see, thanks. Then it's going to take a while to get anywhere

How is the tournament krill calculated now? The last (and only) info I found about it is: https://sealswithclubs.eu/krill-for-sngs-and-tournaments/ , but I noticed a while back that my krill is increasing veeery slowly, so started to follow it a bit more closely and it's clear that I am not getting anywhere as much points as I would expect based on that announcement. For example I played yesterday a tournament with 5 chips entry, for which I would expect sqrt(5)*2 = 4 krill, but I only got 1. And this has been working like that since I started paying attention to it.

From the code you pasted, it seems that the real issue here is the 10000 rounds of SHA256, not the ECDSA. It may be worth trying to put only the "stretch_key" method on a gpu, and then do the ECDSA on the CPU. Probably much less work to implement, but still a significant speed-up compared to naively running this python script.

rJYyMS7EpEBMQcvZuNETUhYCecu2iPz51u

Lot of people are only playing tournaments, so krill may not be the best way to filter. (Or you could give krill for tournament buy-ins too)

Well, when I first saw it, I was expecting much trouble too, having ported many libraries between unix-based platforms. But the fact that it went so smoothly, only shows that this is a well-maintained piece of software [/quote]

Thank you for acknowledging that. I indeed didn't contribute much, as I had absolutely no idea whether anything I managed is needed, or in what form.

No problem, keep up the good work!

And this is what was achieved much earlier, and made it unclear what the state of the bounty was. Obviously what I mean is not going through, but never mind then. I wasn't doubting whether his solution worked, 10 paragraph email or not.

Because you said that you may want to post bounties later too, here are a few comments:

First of all it would be good to see some progress report occasionally, to know whether there is something else to be done, what is still missing, etc. Pretty much as soon as it turned out that after having the dependencies installed with brew, the app builds trivially, it wasn't clear what else was missing. (codesigning, was it part of that? though that's also only two more lines)

You said in the opening comment that "I'd also like to see this thread used for collaboration". This is difficult without feedback on the process. It seemed like you're not considering anyone else than higuys, but it wasn't clear. Especially after you moved the discussion away from the forum to IRC, pretty much everyone else was closed out.

You also said that the goal is to have a "recipe", but at the end you say the exit criteria was "He gave me a .zip that I downloaded in a fresh install of an OSX virtual machine, double-clicked, and Armory was running.". In that case you should have closed the bounty earlier, or at least indicate that the party was over, because that stage had been reached.

Well, considering that the build instructions say so, this is hardly surprising

Probably because what I said: PyQt needs some small changes to behave properly within the virtualenv. Still, those lines are unnecessary once PyQt is installed by brew.

I am confused. You start with
installing pyqt (and its dependencies, including sip) into the system site-packages. Then you create a virtualenv only to download/build/install these two into it. At this point that seems unneccesary,   line 20-39 can be dropped completely.  (and it indeed worked when I tried, bit I didn't run your script)

edit: not only unnecessary, but it doesn't even work without the brew-installed pyqt package. The makefiles of PyQt are messed up, and don't like to be installed within a virtualenv, some paths will point to the system-wide packages, and will produce problems such as:


This is one of the things that held me back yesterday when trying to do everything strictly inside the virtualenv. The solution is to
replacing all the incorrect include paths.

Okay, last few remarks then I am done for today, I need to sleep.



1. The sip installer in your script has the same idiotic problem I struggled with: it wants to put itself outside the virtualenv.  /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7.  It asks for root password when it gets to that point, that's when I killed it...

2. As I only used this system for iOS development, and I only use python on linux boxes, I didn't really have any "extra" packages. Only wget was missing (in addition to swig), so it's good, no exotic dependencies.

3. the "cd sip-4.14.4.tar.gz" line must be replaced to "cd sip-4.14.4"

I see, but if someones 5 year from now tries to reproduce the steps, and by the time something not backward-compatibly changed in swig, that may lead to some frustration.

Anyway after installing it with brew, Armory compiles and builds.

I have a virtualenv started with -no-site-packages , so that I can be absolutely sure nothing interferes with already installed stuff, and is 100% reproducible in any system. I tried the configure & make route for installing, but unfortunately swig isn't just a python package, so won't respect the virtualenv. So I either give up on being system-independent and use the brew method, or find out where to put what. I copied the content of the built "Lib" dir to "./swig_lib" , which seems to be one of the search paths, but apparently it doesn't work.

Now it works on my mac. (the previous one had the same problem as listed above by picobit)

And for the swig dependency: I am trying to install it within virtualenv, but it again mixes up the global directories and the virtualenv ones. Then I tried to put it in one of the locations the makefiles tries, but even then there is some problem... So the build process is definitely not as straight-forward as your hand-written script suggests    (at least not when insisting on virtualenv)

The check for virtualenv fails, I am not a shell script wizard, but I think it should be "if [ ! -x `which virtualenv` ];"  (added exclamation mark)

It also seems to miss the part needed for swig.

And while I haven't tried that part of the script, I am surprised that PyQt built and installed without any problem. I had to modify all the makefiles, as the include directories pointed to the system dirs instead of the virtualenv ones, crashing the make & make install dance.

The python interpreter itself isn't really big when compiled into an executable. I used the freeze tool earlier (http://wiki.python.org/moin/Freeze) and it's pretty straightforward, and the result is truly stand-alone, and very convenient to deploy.

I spent the last hour or so trying to get PyQt and friends compiled/installed in a virtualenv, and this seems to be a nightmare. After this I am convinced that any user-friendly distributions should include it as compiled into the frozen bytecode.

Or paypal caught wind of the nature of their business and disabled their account...

Well, to be pedantic this one isn't exactly true. They themselves never said anything about EDI GREEN, it's just that their domains have been registered with this contact info.

Also the location in the third point is only the address of their accountant company. Without knowing how the domain ended up being registered, and what role EDI GREEN is supposed to have, this doesn't mean much.


But at this point the rest of the bulletpoints seem to stand, and haven't been refuted.

Based on the sign in the window, that's an accountant and tax consultant company. Edi green must be one of their many clients. They also probably let their clients use their address as the official address when registering. They forward their mails, answer any inquiries from the tax office or other government entities, but that doesn't mean that they know anything about the company.

(also google maps shows at least 5 other companies registered to the same address)