Sure, he did.  I am sleeping.  I thought this was the new info he promised.  Sorry, wachtwoord!

Are you just teasing us, or did casascius tell you?

 

Found a scrypt implementation for Python written in C, so it should be pretty fast.  100 attempts in 52 sec on my Mac.  Still, that will take 44 days if I had 52 CPUs to run on.  Giving that I still have to implement all the rest of the BIP key decryption in Python (I planned to steal most of it from Armory), I doubt that I will be first to collect the price (and I don't have 52 CPUs to spare).  So I pass.  But it was fun to looking into this.

If something like that gives you a loss today, it will give you a corresponding winning tomorrow at the next clearing - or when you close your positions.  So in the long run, it has no effect unless your positions are forced close, which of course could happen.

Just for the record:  It seems likely that the Mac OS X problems are related to this Qt bug, at least when reading the comments.
https://bugreports.qt-project.org/browse/QTBUG-17913

I would think this points towards supporting a lighter (but not entirely light) mode in Armory: https://en.bitcoin.it/wiki/BIP_0037

That would of course require that Armory maintains the blockchain itself instead of relying on the reference client.  But as the ref. client is open source, it should be possible to merge the relevant parts into Armory.  That would drop the requirement of running the reference client in the background, and could form the basis for a development where only a partial block chain is downloaded and stored.  I am sure it will take ages before BIP 37 is implemented, but etotheipi has probably lots of other more urgent things to keep him busy anyway :-)

If I use such a broker, will assets formally be issued to me, or to the broker?

I guess that MPex will GPG sign that the asset was issued to the broker, so if the broker goes broke, do I have a problem?

I think this quote from Jimmy Wales makes sense, and reflects my own sentiments pretty well.  Bitcoin is not particularly user-friendly, although I think that can and will change.

However, there are many other reasons for being sceptical about Bitcoins long-term survival.  Personally, I think Bitcoin is a great idea, but its odds of long-term survival are not too good.  Until then, I will use bitcoins, partly because it is too great a concept to stay away from, partly because if all of us being sceptical abandon it then the odds of success will be even lower.

So, lets all hope that I am wrong   Time will show.

Another Mac OS X bug 

I exercised the newest Armory from the threading branch, almost everything works fine, although it does tend to exhibit brief "freezes" when you expect a window to open or close, and nothing happens for 5-10 seconds (while one core of the CPU runs at 100%).

There is however a rare but important function that fails on Mac OS X: Printing a paper backup.  Again the problem is that Qt pops up a native print dialog, and it is dead.  However, in this case there is no non-native dialog to fall back upon, apparently the native print dialog is always used on Windows and Mac OS.

In this case I was actually able to open a second print dialog by pressing the Print button again while the dead first dialog was open.  That was followed by a segfault a second later.

It suspiciously looks like a Qt bug, which would make it really hard for you to work around it.

Personally, I can live with this bug.  I can print any paper backup from the offline computer (running Linux).  But it is annoying, and I will continue to investigate.

Yes, hashing a single file is sequential.  But attempting to brute-force a wallet password requires hashing a dictionary of likely passwords (typically computer generated based on vast experience with leaked passwords, so the dictionary will contain the apparently hard-to-guess passwords we typically come up with).  And hashing a dictionary is of course "embarrassingly parallel" as the computer science guys call it.

I found a workaround!   

Not a solution, but something looking like an acceptable workaround.  I added options=QFileDialog.DontUseNativeDialog to the QFileDialog.getSaveFileName function call (ArmoryQt.py line 1505).  Then it opens a not too petty Qt-style file save dialog instead of the Mac OS X style file save dialog.  And it works!

Of course it should only be done on Mac OS X, but that should be easy to implement.

It is the only place in the code that save dialogs are created, so it fixes both the offline transactions and the export transactions problems.  It really looks like a bug in the Qt library.

I'll give it a try - but I am not sure I get time to do it this week.  I am, however, quite motivated to see Armory keep working on OSX, it has become my favourite client.  Not that I can put my finger on what makes it particularly attractive - I guess you have just made an overall good design.

I looked a bit at the code, and experimented with a few print statements.

It looks like it is the call to QFileDialog.getSaveFileName() that fails.  It is called with sensible arguments, but never returns, as the resulting dialog is mostly dead.  It looks like the events generated by that dialog are never processed.  I can change the file name, and TAB will move between the file name, the search bar, and the sidebar.  It never gives focus to the buttons at the bottom (New Folder, Cancel and Save).

Since this only happens in the multithreaded version of Armory, it is most likely either a bug in Qt manifesting itself under MacOS (but then why does it not affect other programs - there does not seem to be any open bug reports on it).  Or Armory is doing something with threads which is technically not allowed, but just happens to work in most circumstances.  It it the same Python thread making all Qt calls?  Does Qt make callbacks into Python from a different thread?  Does the swig library mess up the thread state of Python?

Of course I am idly speculating, and it is not likely that it will be useful.  But just in case...

@etotheipi
Could you be a little more specific, then I would like to look into it.  Not that I have great hopes...

But I have used swig a lot some years ago - abandoned it to writing the C/Python interface manually, as 90% of the work had to be done anyway in the form of typemaps, and debugging was kind of hard.  No experience with threading and swig, though.

@Red Emerald
Which Qt are you using?  Homebrew, fink, macports or a fourth option?  Are you using the Apple-supplied Python or the one provided by homebrew/macports/whatever?

The strange thing is that the behaviour is different in the two versions, perhaps multithreading is somehow interfering with Qt's own multithreading.  I will try to look at it myself, and also try if I can get another version of Qt.  I use the version in homebrew:
qt: stable 4.8.3 (bottled), HEAD
pyqt: stable 4.9.4



Good.  I think this way of doing it is the least of many evils.  Any attempt to be "smart" is just going to cause grief, and as you say the failure mode in this case is benign.

Hi etotheipi,

I am afraid that the threading branch does not work well on Mac OS X.  The file save dialogs are unresponsive, you can write a file name, but no other widgets react, and pressing return does not result in the file being saved.  This essentially renders offline mode useless, as I cannot save the unsigned transactions. 

Suspecting an update of a library or something, I reverted to the master branch and recompiled, and then it works as it always did (but I immediately miss the multithreading stuff).

I actually do suspect some kind of race conditions, for even in the master branch the save window behaves slightly inconsistently.  Sometimes the file name is prefilled with a file name for the unsigned transition, sometimes it is not, apparently randomly.  Is it possible that the save window is somehow popped up before it is 100% initialized?

All this mess leads me to an unrelated question regarding offline transactions.  I now created a number of unsigned transactions that never got saved.  Will Armory remember these and by trying to avoid creating double spends prevent me from spending some of my funds.  If not, what if I create two or more offline transactions and wait signing them to later, will I then risk that they contain double spends when I transmit them?

Should I still use the "threading" branch, or has it been merged into the trunk?

Typically when people send btc around from one address to another, they start by spreading out the btc, but eventually they tend to be combined into the same transaction much later, showing that they have stayed with the same owner.  So it is very unreliable to hide your tracks with long chains of transactions.  Much better would be to send all the BTC to MtGox, sell them, buy them back a few days later, take the loss from price going up and then transfer them to a new wallet.  I assume that would hide your tracks.

Thanks for your answers!


That seems short enough to make them interesting. 

Oh, and while I am here I have a question for you, Fireball.

On "judgment day" when the BUZ2 contracts are settled, will the settlement price be limited by the max 10% per day rule?

I am thinking about the situation where there happens to be extreme volatility in the BTC price just prior to the 15th December, and/or somebody successfully manipulates the BUZ2 rate the last couple of clearings.

And will a new future (BUZ3?) be introduced?  I assume it will.  Will the two overlap in time?  And how long will the new future run?  The longer until settlement, the less the price will be coupled to the spot market price, and the less useful it will be for e.g. hedging.