What is the status with respect to testing under MacOS?  Should I build from source, and manage bitcoind/bitcoin-qt myself?

Did you really mean to post that very relevant picture in this thread?  And if you think this is a ride, try a real crash!  The price "crashed" down to what it was four days ago.  How dramatic!   

The fees may be a problem for daytrading, but if you hold a position a few days they will hardly make a scratch in your profit (or loss).

He announced recently that he would increase the margin for long positions, looks like that is what happened.  I guess he got tired of paying for short users going bankrupt during the rapid rise, and wanted to avoid the same for long users during the unavoidable crash.  Now the crash has come, and it was not bad at all (only four days of value increase wiped out.  FOUR DAYS, hmm this was not a crash but a minor correction).

Anyway, ICBIT has not really worked during these last crazy weeks, as nobody in their right mind would go short (even if you think it is a bubble, "the market may remain irrational longer than you can remain solvent").  During most of the spring, I suppose the bulls have lived from the arbitrageurs, and the arbitrageurs have profited from the contango the bulls caused (use USD, buy BTC on an exchange, short the same amount of USD on ICBIT, profit: the difference in BTC, same amount in BTC regardless of what happens to the rate).

But the contango went away, either because ICBIT could not move fast enough or because nobody wanted to take the role as arbitrageur - or no-one wanted to pay a large contango and then be forcibly closed.  If things settle now, and this correction cause the price to rise slower (or even fall - was this the signal to "the long slide to 20$" ?) then ICBIT should begin functioning better again.  And to return on topic: then I assume Fireball would reduce the margin requirement, so ICBIT becomes attractive again.  The current margin requirement may be necessary, but it really sucks, and I doubt that I will increase my position under these conditions (not that I have been able to do so when I tried - no-one wanted to sell anyway)

I think I saw that error when testing one of higuys builds - i don't know what he did to fix it.

If it is needed at runtime, then I would think it needs to be copied.

If you don't redirect output to /dev/null then perhaps you will see an error message.

What on Earth happened at 10:13 this morning

At 9:02:58, I have sold 550 BUM at 150$, this looks like a forced close (the majority of my contracts ).  Then something weird happens: At 10:13:38 I have apparently sold another 550 BUM3 at 155$, and then bought them all back at 10:15:20 at the same price.  550 contracts is somewhat more than I had, so I have been short for 2 minutes.  And why did this result in TWO variation margin lines in the log at 10:13:38?  Was this an erroneous forced closure, or something like that?

I know this extra "clearing" should not affect my profit, since the real clearing happened soon after, regaining the lost money.  But the two variation margin lines worries me a bit, since something clearly went wrong I may have taken a loss for all 550 contracts, and not just for the 300-something that I actually owned?


Edit: spelling.

The Gold and Oil futures will settle in a week or so.  Will they be replaced?

blockchain.info has stopped reporting new blocks approximately 15 blocks ago.  The last reported block has been orphaned according to blockexplorer.com.  My own Armory client choked at the same block, and needed restarting, so something must have been slightly confusing about this reorg.

@Fireball

Something is again wrong with the trading range of gold.  For two days, there have been asks all the way down to the bottom of the trading range (13.04 BTC/oz, corresponding to a bitcoin price of around 119 USD), but no-one wants to buy at that unfavorable rate, to the last trade price does not change, and at the last clearing the trading range did not move.  In this kind of situations, the trading range should be recentered around the lowest ask (or highest bid if movement goes the other way), so trading can be resumed.  It may need doing this for two clearings to get to a reasonable trading range for Gold.


EDIT: Again at todays clearing, the trading range did not move.  This instrument is temporarily deadlocked.

If that is what you use it for, you should not even publish the value.  The evil manipulator might experiment with moving the market until he worked out the formula, or perhaps just enough correlations to be able to manipulate it.

No explanation at all.  Give me a formula, then there is a chance I will understand it. 

In particular if they are nonstandard as the one mentioned in the link above (tries to send a negative amount!).  Then they will never propagate nor confirm.

LOL

I would like to know how these numbers are defined. 

Has anyone been able to use tormail since last week?  There seems to be a database error, you can get to the onion site, and attempt to log in, and then an error. 

Yes, a few days ago.  I followed the instructions here: https://gist.github.com/FiloSottile/3646033
but instead of applying the patch to the Makefile, I went through it by hand and made the same changes.  I also had to remove $(STATICPYTHON) from the command line where the shared object (.so) is built.

Also, be aware that he refers to another page on how to build the cross compiler, and below that writes that you also have to enable building the C++ compiler.  If you overlook that you waste three hours of compiling!

I cannot walk you through it, as I will go offline for a week or so in half an hour


EDIT:  You will also need to install a number of dependencies on the RPi, the error messages when attempting to start Armory without them will point you in the right direction.  I chose to take it online and install them with apt-get, the truly paranoid should probably move the packages with an USB stick, although if the RPi never goes online after the wallet has been created I am not worried (and the yet non-existing wallet-stealing malware could have infected the installation image, too). 

But if you do that, you might just install all dependencies on the RPi and compile there.  It may take forever, but should complete unless there is too little RAM to compile the huge _wrap.cpp file that Swig generates.

The miners fee is negative, it is guaranteed never to confirm, and the transactions building on this one will never confirm either.  Presumably the transactions will expire after a day or two, and the money will be back in the sender's wallet.

If you are at the receiving end of any of these payments you will not see the money.

A negative miners fee!  Somebody must have played with raw transactions.  I assume it will never confirm, but how on earth did it propagate?


EDIT: The outputs have been spent.  Surely, somebody is trying to creating correctly-looking transactions that will never confirm probably attempting a double spend.

The main problem is that no-one can be sure where the user installs Bitcoin-Qt.  Sure, it is most likely to go in /Applications/Bitcoin-Qt.app, but a user may choose to install it anywhere ($HOME/Applications or $HOME/Desktop would be likely candidates).  This makes placing a command-line executable inside the .app directory a bit awkward.

There is a "correct" way to do it, but I doubt you can sell it to Gavin Andresen:  Several apps that have command-line tools (The Aquamacs editor and Xcode come to mind) have a menu point called "install command-line tools" that then copies or links the tools into /usr/bin.  But not only does the app need to have this menu point, it should also have code detecting when it has been updated so it can pop up a dialog requesting permission to upgrade the command line tools.  Clearly some work to implement.

Another "correct" way is not to distribute Bitcoin-Qt as a simple app that is dragged into the application folder, but to use an installer. Again extra work, and I have no clue how to do that.

A simple possibility might be to include bitcoind in an "Extras" folder in the installation disk image, so interested parties (Armory users) can open that folder, where they find bitcoind and a link to /usr/bin so they can drag it over.  I suppose this would work.

Finally, Armory could have a heuristic for locating Bitcoin-Qt and then find bitcoind in a subfolder there.