Topic: Miners, You Should Be Earning 7% Fixed Income With Options - page 5. (Read 10909 times)

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

Hey BitcoinOPX.


How does your marginal system works? How can one be sure that the other party actually pays, and that BitcoinOPX doesn't go default?

I had to spend significant amount of time in discussions and getting advice from people with finance educational background to figure out how to build one for the ICBIT futures market.

I wonder how you solve this problem.

Seriously?  To log into the accounts and withdraw the funds ($ and Bitcoin) from the users.  

I think the link that you're probably missing is that passwords are (or should be!) stored in the database after being hashed by a one way algorithm, not in plain text.  This means that by just having a copy of the database, one couldn't log into a users account.  You would have to start using the same hashing algorithm that was used to create the hash, and start hashing random strings, until you find a hash that matches one from the database.  For each match that you find, you can gain access to a user's account.

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 !!! 

6 character passwords have a huge benefit: when a user forgets his password it can be computed from the hash within a few seconds.

Frankly I stopped reading this thread at this point - it seems that these days even hobby sites are more secure than some financial sites.

Why would anyone want to crack the passwords if they've got the database? Passwords are random, so they're not of use anywhere else. (Maybe they have the passwords but can't access the wallet though. Can happen.) Also I'd expect 9 randomly generated characters to be far better than 12 character user provided passwords.

Having said that, I'd comply with the demands. It's hard to prove people wrong on this matter and it is bad for PR.

EDIT: I'm more interested in security matters like how you store the coins and what my options are if you disappear tomorrow.

This is the most important part of this whole thread, where did you come from and why do you suddenly want people to deposit money with you?

Look, 6 chars is enough to prevent a remote brute force (since only 7 tries are given), but it is not enough if your database is copied (since billions of tries are given).

Even you admit this.

It doesn't matter if you think that 6 char passwords are enough, the people in this thread are your potential clients. Concede, and give them what they want, even if it doesn't quite fit with your view.

Call me oldfashioned, but even before I look at the security "conversation"

Who are you? I don't entrust my BTC to random internet nicks with only an email for contact.

Where are you based? are you a registered company in any jurisdiction?

You say "We" who are the other people involved?

I see you are hosting in Panama, are you on a VM or a dedicated server or your own server colocated?
After the Linode experience, I hope the last.

And on the security issue, you do realise that the other thing GPUs are really good for apart from mining Bitcoins and playing games is password cracking?

I've made an account, to try it out. I'm a newbie in those sorts of thing, and all this seems as easy as making a worldwide speech in japanese.

So, here's my real life situation. At the end of the month, I'm going to sell 300 Bitcoins. I'm mining them right now, and they are going to be sold. Let's say you want to teach me how to use BitcoinOPX for my first time knowing that I'm selling 300 Bitcoins at the end of the month, what do you tell me?

Is there any volume?  I see no bids or asks on any contract.....

unfortunately, on bitcointalk good advice comes with a bit of exaggerated ass raping. 

I understand your financial concept and I find it really interesting.

BUT

As others mentioned, review your security method. We are hardware and software guys here. We maybe have difficulties to understand finances correctly, but we swim in network security everyday. I personally always use random passwords of around 12 characters that I generate myself with some software I own. I'm a sort of maniac that put different passwords everywhere.

We are ready to help you secure your project, ESPECIALLY if we invest money in it. If you agree to review your security method, I'm sure you'll find a shitload of good advices to enhance security. 

+1

Also, while good sercurity is always a great idea....

The security of a site does depend on how much you are storing/moving with it.  Storing 50 BTC and you can afford to loose it?  Maybe a basic dedicated server will do.  Storing 10,000 BTC + and know that the BEST OF THE BEST are going to be attacking you.  Anyone working for you hosting/colo company can be working against you. 

107% return per month results in 225% ROI per year.

My 3x7970 rig already does better at 241% ROI per year after cost and depreciation if the exchange rate stays constant.

Actually this is not the best option for me. A 5970 setup would result in ~300% ROI for me. I didn't choose this as I was hedging against the risk of reward halving making HD5xxx worth little to nothing.

That's was a good laugh.

Look, we all already know that you have no idea what you are talking about. So I have a suggestion for you. Stop arguing. Shut up. And listen.

- Start with abandoning that silly notion that you can lecture people who posted in this thread on infosec matters.
- Ask them what you need to do on infosec.
- Listen and implement the reasonable suggestions.

For starters I have a few quick suggestions (others will add to it, I am sure):
- Let users to chose their own passwords.
- Do not accept ones that are less than 12 symbols and do not contain lowercase, uppercase and digits.
- Use proper salting and bcrypt or some variation of thereof for hashing.
- Move away from any form of cloud computing, some dedicated servers are a good start, but do look into colocation options.
- A good litmus paper here would be ability to have properly encrypted partitions (all of them). If you cannot do it and do not need to enter the password in order to decrypt those during system startup, chances are you are doing it wrong. (BTW most hosting providers you kids are using these days will not give you this functionality).

There is more, but this is a good start.

Oh boy...


If an attacker was trying to brute force your login, you would be down due to a denial of service long before they got in.  That wasn't the original concern raised.  It seems you missed the point about someone getting a copy of your database.  This is where the brute force will take place, and your 7 tries logic doesn't do anything here.



That is good!  But without knowing the implementation, I have to assume the worst: that this two factor auth is stored in plain text, with maybe a LIKE query to match for case insensitivity?  Remember, if the database is compromised, the attacker has everything.


I'm very aware EC2 instances cost money.  I pay a bill every month   But hackers will generally use stolen credit cards to pay for these services, so the cost isn't really a concern to them.  And even if they did have to pay out of their own pocket, they are betting that the reward of getting into your users accounts, and accessing their $ / bitcoins is greater than the investment (which it would be).

Again, I think you've got a great service here... I'm just not comfortable with the implementation, and I think I'm entitled to that.

@rjk: we may have been talking slightly past each other.

I never said a 6 character password is impossible for a hacker to figure out if they are successful in hacking into a database and then using brute force to retrieve that password. It's not obviously, for reasons as I explained about password entropy above.

What I said is that security experts agree such criteria is regarded as secure.

I'm sure you agree that security is relative, and people to this day honestly use dictionary words like "love" or even the brilliant choice "password".

What I was trying to say is that at a minimum the threshold to begin to enter the realm of secure, especially in the context of the above, is using at least 6 characters which are random upper and lowercase, numbers, and symbols.

Again, regarding the two-factor authentication, yes, I know it's not the strongest possible, but it is an additional item.

Regarding usability, we've done our best to maintain a balance of security and usability. We think that users will indeed write down assigned passwords and not be put off by the requirement when considering security. Users can indeed request a new password anytime, but they can never choose it. And we would never use a password less than 8 characters whether assigned or not.

Nope. As has been demonstrated in the past, bitcoin-related services have been hacked repeatedly, resulting in the compromise of user passwords. Even with hash+salt, a 6 character password really isn't that hard to retrieve.

The reason I am making something of it is because I am certain that the policy of a generated password with no way for the user to change it is going to result in usability issues, namely that of people not bothering to use the system because they have to write down or remember yet another password. And then you might make a change allowing them to edit their passwords, while allowing 6 chars to be the minimum, and that would be bad practice.

Sure, your method is reasonably secure, but it isn't user friendly.

EDIT: Also, http://thedailywtf.com/Articles/WishItWas-TwoFactor-.aspx

@rjk: I'll ask you the same question. You're saying a random 6 characters of upper and lowercase letters, numbers, and symbols is NOT secure from being guessed in a maximum of 7 tries?