My brain made me send 0.20 btc to bitlotto instead of 0.25 btc 

a DONATION to this months jackpot  (trying to bribe the lottery gods !)

As they state on their website: if one defaults on a margin call the option position is closed and the holder of the option is being compensated with the amount of collateral that was posted... so the counterparty risk is not on BitcoinOPX but on the buyer of the option (or at least that is how I read it), see my earlier post

Im no security expert so I will leave the password hashing/salting/cracking to others

I do however have some questions about the finance side of your business: the counterparty risk

In the absence of a central clearer, the margin system you are proposing seems to skew the risk of the options contract to the buyer instead of the writer of the options....

as is stated on the website, margin calls will go out to writers of the options if the initial margin isn't high enough to cover the outstanding amount owed. This is completely natural, but there is NO way for you to enforce people to actually post more collateral, hence you state that in the event the writer of the options fail to post more collateral, you will close the options and payout to the holder, ie buyer

This basically means that a seller of the options can choose to default and never be on the hook for more than his initial margin, while the holder of the option is left holding the bag: counterparty risk

for example: someone sells me a call, strikeprice 6, maturity 2 weeks. He has to put up 15% margin, 0.90 $
Now the price of btc shoots up overnight to $8 (stranger things have happened) the seller has to put up at least $1.10 more as collateral, and probably much more as the volatility spiked. He now thinks to himself, this could cost me more money than I expected and declines to post the collateral. You have no way to enforce him to pay up, so you settle the option with the amount of money that was put in as the initial margin, $0.90

I now am left with a much smaller profit than I expected and have no more exposure to btc, which will cost me now more premium to get back on as the volatility has risen as a result of the price jump

That is why regulated derivatives have central clearing houses and OTC markets see their particpants in heated discussions at the end of the business day to agree on the amount of collateral that needs to be posted

edit: such a nightmare to try and post something in this forum from my Samsung Tab !!! 

Thanks once again Clipse !

first beta site I have ever seen, where I get paid more then anywhere else, even after the outages !!! 

Received the interest on the account, reinvested, all looks good !!! 

Thanks !

Looks great !

Thanks !!!

Thanks again !!!

I switched back to 2.4.1 that didn't help....still the "share became stale before submitting, discarding" message, I let it run on another pool for a while.... Clipse came back to me, saying he had NOT banned my IP

I restarted 2.4.2 and now it works again, there was NO reason for it NOT to work and there is NO real reason why it is working again now

I'd suggest keep trying to reconnect

I am having a similar problem:

woke up and 1 of my rigs (separate IP from the others) was discarding every share as being stale.... Restarted the rig and now it won't connect to Bonuspool anymore

CGMiner reports it as being dead, while my other rigs are hashing away

My guess is that Clipse banned my IP for submitting too many rejects or smtg

Using 2.4.2.

Clipse: I'll IM you my IP that's giving the problems

Sent PM

Yeah even for us in the UK 3 am is too late to be actively involved

Just putting in my bids and then off to bed

If you say I won, I'll believe you, no need to verify

Ps: 3% donation if I win 

my 0.25 BTC made it in just before the close

That will be 1 BFL ASIC pls

if it was specific to this pool, all my mining rigs would stay connected to my backup pool.... they don't.... sometimes 1 or 2 of them keep hashing away at the backup pool, while the others happily switch back to Clipse.... seems clear enough to me !

Think it is a flaw in CGMiner.... Pool goes in reject state after 3 mins of rejects, then on next LP it looks to see if the main pool is back online

In most instances it works perfectly, but in sometimes it doesn't see the pool back alive... strange thing is, on one rig it does see the pool and on another it doesn't, even on the same IP address....

strange !

CGMiner 2.4.1. did not resolve this issue, sometimes the pool stays on 'rejecting' state even though it is working fine again

And a statement will come in June, so although all this speculation is fun, it's also useless

Let's just see what they say and if they can back it up with a working product

Then people can rant how BFL will be the end of Bitcoin while they are filling out the order form for a nice and shiny ASIC, as they don't want to be left out of the party 

And yet so many miners do

Reject rate is steadily dropping again

Thx !