Miners, You Should Be Earning 7% Fixed Income With Options

[BitcoinOPX]

Hi Miners,

BitcoinOPX.com has recently opened and I wanted to make sure everyone knows of a risk free way to earn 7%, for example, monthly returns on your coins.

This is possible because of the value options provide asset holders who are most likely planning to sell. Below is a great example provided by forum user waltmarkers in a speculation thread:

Actually, I disagree - this could be the perfect vehicle for miners and other bitcoin holders. Covered calls in the money at inception are a great way for the bitcoin owner to make a fixed short term income based on their long term position.

For example.

I want to "lend" 1000 coins.

Current price is 5.75.

I issue a 1000 call at a strike price of 5.50  for 0.635 per coin or a $635 contract price for 28 days from now.

If bitcoin goes up past 6.135, I lose my coins, but I get $5500 plus the contract price of $635. Basically I locked in a sell price of $6.15  (7% monthly return)

If bitcoin is between 5.50 and 6.135, and the contract is exercised, I still get the $6,135. I effective sold at $6.15. (7% monthly return)

If bitcoin goes below 5.50, contract is not exercised. I keep my 1000 coins plus I now have an extra $635 I can pocket or buy more coins with.

We don't need one market maker, we need a group of miners to use covered calls.

BTW - why would someone want to buy a call already in the money? 1. They would like to speculate the coins are going up past the 6.15 with out buying a single coin. 2. They are selling coins lent to them to convert to fiat for a purchase, and want to ensure they can pay their loan in bitcoin later.

This has been your friendly neighborhood covered call lesson.

@waltmarkers: I completely agree. Thanks for that textbook example of the advantage of writing covered calls as applied to Bitcoin.

I would add a 3rd reason for someone wanting to buy a call already in the money: As I noted above options can provide leverage. If a person believes the price is heading to $7.00 for example and has $635 they can either buy the option you mentioned or buy bitcoins directly. If they buy bitcoins directly at the current price of $5.75 they can afford 110 bitcoins. Multiplying that by the difference gives 110 x $1.25 = $138.00 is the maximum they could profit from that price move.

However, buying your option at $635 yields 1000 x 1.50 = $1500, then subtracting the $635 = $865 of profit they could make. Quite a difference. More risky, of course, but no comparison in terms of profit potential.

Perhaps I should be explaining this to the miners...  

The example uses 1000 coins but BitcoinOPX allows creating options of sizes 10 or 100 as well. The 7% return would apply in any case. I'm happy to answer any questions.

[MoneyIsDebt]

If you want to appeal to miners, many of whom are not traders, and many of whom are not native English speakers, you might want to start by explaining the terminology. What is a call, what is covered,what does "in the money" mean, etc.

[Cablez]

Exactly. I am a hardware guy not a finance guy. Walk me through the math and we'll see if its interesting.

[Brunic]

I agree with the above miners. If you could use C++ or at least PHP to explain it, it would be great! 

[BitcoinOPX]

Hmm, can't I just say trust me it works!

Seriously, options are hard to understand in depth, but I'll try to give the basics. Below is the option example given on our site:

Imagine a home buyer finds the perfect house for $300,000, but his loan won't be approved for one month. The house seller might write an option contract giving the potential buyer the right to buy the house for $300,000 one month later if he so chooses. The house seller sells this for $1,000, figuring he wins either way because he wants to sell the house. The buyer gladly pays $1,000 for the contract locking in the price.

Three weeks pass and the buyer learns his loan is declined, but the house he holds the option contract to has doubled in value to $600,000. This means his contract is worth $300,000 of savings to someone, and he can sell it for a tremendous profit. This can show the power of options.

Call and Put Options

A call option gives the holder the right (but not obligation) to buy the underlying asset at a set price. A contract holder will likely exercise this right if the market value of the asset is at or above the contract or "strike" price at maturity.

A put option gives the holder the right to sell the underlying asset at a set price. Put options are likely exercised if the market value of the asset is at or below the strike price at maturity.
_________________________________

Okay, so that's the basics for options. Now, in terms of finance and Wall Street we use terms like "in the money", "covered" etc.

You have to understand options in Wall Street finance are traded mostly for speculation, not investment, and you get these shortened phrases like "writing a covered call". Writing an option means you are the person creating the contract. The option is "covered" if you also own the underlying asset of the contract.

This is what miners should do, because it is a risk free way to make money.

Think of the home owner in the example above. Do you think it was wise for him to write the option contract and pocket the $1,000 since he planned on selling the house anyway? Of course it was. His only downside was not predicting his house value would double. Of course, the value could have went down too, but in that case he looks even smarter because he still has the $1,000 plus the house which he can still sell later.

Now, imagine he is actually a home builder and will be in this situation every single month. Doesn't it make sense for him to write and sell option contracts for added fixed income? It does from a mathematical point of view if prices rise and fall (he keeps the option proceeds either way). He only loses out if the home values always increase substantially and never drop.

Make sense?

BTW in-the-money means the contract holder has a positive position because the market value of the asset is above the strike price of the contract. In the example above the option on the home is in-the-money from the time it's written on forward since it never goes below $300,000.

[Stephen Gornick]

It only generates a password,  I cannot set the password myself.  it is a ... 9 character password.

For sites where my funds are stored, I only trust as being strong a 12 character or more password, which I create using KeePass.

Can't I be trusted to provide my own password?


 

[BitcoinOPX]

It only generates a password,  I cannot set the password myself.  it is a ... 9 character password.

For sites where my funds are stored, I only trust as being strong a 12 character or more password, which I create using KeePass.

Can't I be trusted to provide my own password?

Our site is highly secure. Security experts agree a password at least 6 characters long with a mixture of upper and lowercase letters numbers and symbols is very secure. Our generated passwords meet this criteria, but are at least 8 characters long. Such a password is impossible to guess.

There are two other things that make this secure: 1) The site allows only 7 login attempts before locking the user out so brute force attacks won't work. (otherwise brute forcing would take over 200 years to crack) 2) We use two-factor authentication which means an intruder must not only get the password right, but also your security answer to your security question.

If interested please also check out this informative article on password security:

http://www.baekdal.com/insights/password-security-usability

We don't allow users to set their own password to ensure they don't use a weak one, and also to ensure it's not duplicated from their other Web accounts. You may have heard LinkedIn and Last.fm databases with passwords were recently hacked. This makes all user online accounts vulnerable if they used the same password.

[nedbert9]

Excellent new service.

[lemonz]

I understand where you are coming from, and I'm not saying whether it's right or wrong.  But I do have a couple comments:

1) The site allows only 7 login attempts before locking the user out so brute force attacks won't work. (otherwise brute forcing would take over 200 years to crack)

Stephen's concern might stem from the security of your database, not the threat of a brute force.  Let's say you're hashing the passwords (which I hope you are, with two salts) and someone gains access to your hosting server.  Your salts and methods are now known and you're safe in the mindset that it would take 200 years for a powerful computer to crack it, while the hacker has spawned several thousand EC2 instances and has cracked half your database in less time that it takes for you to even detect the intrusion.

We don't allow users to set their own password to ensure they don't use a weak one, and also to ensure it's not duplicated from their other Web accounts.

You are causing users to write down (or worse, save in a text file on their desktop / in their email) this password.  Also, you can not guarantee that users will not set other accounts to the same password as yours.  You security is now only as strong as your user's personal computer / email address.

I really like the idea of the site it's easy to read and I get the information I'm looking for immediately, and I commend you for your position on trying to protect users from themselves.  However I'm not convinced you're going about it the right way.  You might find it more user friendly to just enforce password restrictions (length / alphanumeric / symbols and any other rules) and call it a day.

[Inaba]

Our site is highly secure. Security experts agree a password at least 6 characters long with a mixture of upper and lowercase letters numbers and symbols is very secure. Our generated passwords meet this criteria, but are at least 8 characters long. Such a password is impossible to guess.

There are two other things that make this secure: 1) The site allows only 7 login attempts before locking the user out so brute force attacks won't work. (otherwise brute forcing would take over 200 years to crack) 2) We use two-factor authentication which means an intruder must not only get the password right, but also your security answer to your security question.

If interested please also check out this informative article on password security:

http://www.baekdal.com/insights/password-security-usability

We don't allow users to set their own password to ensure they don't use a weak one, and also to ensure it's not duplicated from their other Web accounts. You may have heard LinkedIn and Last.fm databases with passwords were recently hacked. This makes all user online accounts vulnerable if they used the same password.

Wow... talk about not understanding security.  This post alone scares me away from this venture.

Hint: Security questions are not 2FA.
Hint: 6 characters are not enough.

[rjk]

Security experts agree a password at least 6 characters long with a mixture of upper and lowercase letters numbers and symbols is very secure.

No. Nno. nononononononooooooooo. NO!

Let me guess. You are using MD5 to store passwords, yes? Because some site said it was secure?

[BitcoinOPX]

@lemonz: I'm happy to discuss and clarify security procedures

First, I have to say I didn't directly address @Stephen Gornick's password concern. He stated he only feels secure with a password length at least 12 characters.

This stems from incomplete information about secure passwords. He may have heard a longer password is more secure, and this is generally true, but what's missing is when it makes a difference to use a very long password.

It only makes a difference if the attack method is brute force. If you are trying to secure your computer's hard drive with TrueCrypt because you don't want the government or anybody else to be able to access the files then yes password length becomes an issue. That's because the attacker/cracker is working mathematics against you, betting he can use pure computing power to brute force crack the password and thus password entropy becomes an issue. A 12 character password versus a 50 character password can mean the difference between them succeeding in 10-20 years or not for at least 100 years.

But that's not the use case here. As I mentioned brute force attacks are not available to attackers because we only allow 7 tries. That's it. It doesn't matter how strong the attacker's computer is, or number of EC2 instances (which cost money by the way) they have. It takes pure luck to get the password correctly guessed in 7 tries. It is simply a statistical impossibility.
______

Last, you mention users writing down their password, possibly on their computer. It's true that a password is only as secure as the person guarding it. For example, the article I linked explained a top vulnerability being simply asking a user (in relation to something else) what it is.

And still nothing is vulnerable to a malware installed keylogger, whether the user creates a super strong password themselves or not. And whether or not they are careful with it or not (memorized only etc.).

That's why we include two-factor authentication. Even a completely compromised password will not guarantee account access.

[BitcoinOPX]

Wow... talk about not understanding security.  This post alone scares me away from this venture.

Hint: Security questions are not 2FA.
Hint: 6 characters are not enough.

@Inaba: Asking for a second item for authentication is indeed a second factor.

I didn't say it's what is typically used. It's true that stronger TFA would include something in another category, such as something physical the user has.

Second, security involves context. You say 6 characters are not enough. But it what context? You are saying you know a way to crack a password that is a random 6 characters of upper and lowercase letters, numbers and symbols in no more than 7 tries?

[BitcoinOPX]

@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?

[rjk]

@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?

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

[BitcoinOPX]

@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.

[lemonz]

Oh boy...

First, I have to say I didn't directly address @Stephen Gornick's password concern. He stated he only feels secure with a password length at least 12 characters.

This stems from incomplete information about secure passwords. He may have heard a longer password is more secure, and this is generally true, but what's missing is when it makes a difference to use a very long password.

It only makes a difference if the attack method is brute force...

But that's not the use case here. As I mentioned brute force attacks are not available to attackers because we only allow 7 tries.

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's why we include two-factor authentication. Even a completely compromised password will not guarantee account access.

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.

It doesn't matter how strong the attacker's computer is, or number of EC2 instances (which cost money by the way) they have.

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.

[Vladimir]

Our site is highly secure. Security experts agree a password at least 6 characters long with a mixture of upper and lowercase letters numbers and symbols is very secure. Our generated passwords meet this criteria, but are at least 8 characters long. Such a password is impossible to guess.

There are two other things that make this secure: 1) The site allows only 7 login attempts before locking the user out so brute force attacks won't work. (otherwise brute forcing would take over 200 years to crack) 2) We use two-factor authentication which means an intruder must not only get the password right, but also your security answer to your security question.

If interested please also check out this informative article on password security:

http://www.baekdal.com/insights/password-security-usability

We don't allow users to set their own password to ensure they don't use a weak one, and also to ensure it's not duplicated from their other Web accounts. You may have heard LinkedIn and Last.fm databases with passwords were recently hacked. This makes all user online accounts vulnerable if they used the same password.

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.

[AzN1337c0d3r]

The example uses 1000 coins but BitcoinOPX allows creating options of sizes 10 or 100 as well. The 7% return would apply in any case. I'm happy to answer any questions.

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.

[Littleshop]

Our site is highly secure. Security experts agree a password at least 6 characters long with a mixture of upper and lowercase letters numbers and symbols is very secure. Our generated passwords meet this criteria, but are at least 8 characters long. Such a password is impossible to guess.

There are two other things that make this secure: 1) The site allows only 7 login attempts before locking the user out so brute force attacks won't work. (otherwise brute forcing would take over 200 years to crack) 2) We use two-factor authentication which means an intruder must not only get the password right, but also your security answer to your security question.

If interested please also check out this informative article on password security:

http://www.baekdal.com/insights/password-security-usability

We don't allow users to set their own password to ensure they don't use a weak one, and also to ensure it's not duplicated from their other Web accounts. You may have heard LinkedIn and Last.fm databases with passwords were recently hacked. This makes all user online accounts vulnerable if they used the same password.

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.

+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.