I'll answer new questions in a second. I want to explain a bit more about the motivation to use covered calls.
In the example above we say the price will typically move 10% for the term of our option. But we already locked in a 10% increase. This is to further address the concern from @P4man about losing the opportunity of selling coins for a higher price.
Look at the scenarios again. We're covered for every possible price up to $7.15. Moving higher than that is not likely since that would be more than a 10% swing. The risk is all on the option speculator. And if the price does go above $7.15 we still don't lose from our pocket, we only lose what might have been made. So there is an almost 100% chance of only coming out ahead, if the typical 10% price swing holds.
But let's say you're still not convinced. The math and logic sounds good, but your gut feeling expects a price spike. Then only use 200 coins for the option and hold 100! That way you're hedged. You get a $7.15 sale price ahead of time for 200 coins, and you keep 100 coins as a wildcard.
Your options don't stop there. Say you've included all 300 coins in writing options, and in a week the price starts shooting up. You think "I knew it, now I'll miss out on higher pricing." Here you could sell some puts! This begins to inject risk, but I'm explaining your options. Put options are the opposite of calls and you pay the difference when the market price is lower than the strike price.
Say the price was $6.50, but moved up to $6.75. You could issue a put option for the same strike price of $6.75 expiring around the same time or maybe a week after the earlier options. You make it for 300 coins. Projecting a 10% downside swing from $6.75 would be $.68 x 300 = $204.00. So that's how you price your puts. You would be betting the price wouldn't end up below $6.07 by expiration, or you start to lose money. However, if you're right that the price will only continue upward then you've gained an additional $.68 per coin, or up to $7.83 per coin before you miss out on profits from the original 300 coins ending higher than $7.15.
Topic: Miners, You Should Be Earning 7% Fixed Income With Options - page 4. (Read 10909 times)
I for one absolutely LOVE what you are trying to do. Being a finance geek, I would love the opportunity to sell call options against my future production.
Clearly the biggest issue you are going to face is generating sufficient volume in the contracts. I doubt you would be willing to be the counterparty to thousands of contracts miners will sell short?
Clearly the biggest issue you are going to face is generating sufficient volume in the contracts. I doubt you would be willing to be the counterparty to thousands of contracts miners will sell short?
I'm still wondering how you are going to handle counter-party risk ?
Interesting site.
How do you see who has open bids/asks for the options? I don't see any volume.
You might look at cutting back to bi weekly expiration dates or monthly until volume shows up.
How do you see who has open bids/asks for the options? I don't see any volume.
You might look at cutting back to bi weekly expiration dates or monthly until volume shows up.
If BTC value goes up, obviously you do lose. You lose the opportunity to sell your coins at that price.
I meant you don't lose if the option doesn't sell.
As for the opportunity to sell your coins at a higher price, yes, the predictive timing dilemma always exists.
Options simply allow you to guarantee you get something upfront. Yes, the trade-off is that you lose out on price movement above your locked in sale price, but the point is at least you got something higher. By not using options if the price ends up stagnant or lower you get nothing extra or lose money guaranteed.
In other words it's great for people intent on selling. A bird in the hand is worth two in the bush, as they say.
If BTC value goes up, obviously you do lose. You lose the opportunity to sell your coins at that price.
Well; getting $6.5 when the exchange rate is $7.5 is not exactly what I would call "coming out ahead".
You also miss the scenario where no one buys your contracts.
That said, interesting service, subbed.
You also miss the scenario where no one buys your contracts.
That said, interesting service, subbed.
No, don't forget you also have the $193.05.
Divide the $193.05 by 300 coins = $.64 additional per coin! In other words, it's like selling at $7.15.
As for the scenario of no one buying the contract that's partly my job. I have to make sure people know speculative opportunities are available. However, Bitcoin grows overall every day and services are added every day, so that problem diminishes every day.
But, that's not really the point. The point is you have the opportunity to ensure you collect something above and beyond any given price point. It's if the option sells, yes, but it doesn't cost anything if it doesn't. You either lock in extra money or not. You don't lose.
In all cases you come out ahead, because you were going to sell and not hold anyway.
Well; getting $6.5 when the exchange rate is $7.5 is not exactly what I would call "coming out ahead".
You also miss the scenario where no one buys your contracts.
That said, interesting service, subbed.
Update: Okay, we still assign passwords upon signup, but users can now also choose their own password.
To choose your own password please click 'reset password' from My Account and select that option. We wouldn't want to deny anyone the ability to use a 150 character password.
To choose your own password please click 'reset password' from My Account and select that option. We wouldn't want to deny anyone the ability to use a 150 character password.
Regarding the comment about no options on the site yet, yes, we've only recently opened. That's what I'm doing in the Mining forum 
During our Beta soft launch there seemed to be good interest
However, after going live with real money we have yet to see much activity. I think it's because many don't understand how to make money with options. For example, there was repeated confusion about the difference between the Trade screen to place orders, and the Create options section. I don't think that's only due to the UI. I think many people are learning the fundamentals of how options work.
Let me answer the specific question from @Brunic:
This is a perfect example. Notice he says "they are going to be sold". That means his mind is already made up about selling, which is the key benefit of what I'm talking about.
Right now June 16, 2012 say the average price of bitcoins is $6.50, and @Brunic knows he wants to sell 300 coins at the end of the month. At BitcoinOPX every Friday options reach Maturity, meaning they can be exercised/settled. So let's pick the target date Friday, June 29, 2012 as our option Maturity.
Here is the dilemma: @Brunic knows he will sell in the future, but he doesn't know what the BTC price will be then. It can be higher or lower (or the same). Without using options he would probably just buy or sell whatever the price. All things being equal he would win, lose or break even 33% of the time. Say the price typically swings 10% bi-weekly. At our current price of $6.50 by Friday June 29 the price will be either $7.15 or $5.85 (or still be $6.50).
Selling 300 coins means a difference of 300 x $.65 = $195 potential gain or loss from the current price of $6.50. By selling regardless of price as bitcoin goes so @Brunic goes, some months good, some bad etc.
Options provide an... option. He knows the price is now $6.50, and he knows he will sell, so why not lock in an additional 10% on the current price free and clear? By creating and selling options he can do just that. He can lock in a future sell price of $7.15 for June 29th, today. Here's how:
1. Go to BitcoinOPX.com and create a free account
2. From My Account click 'Create Option' to create a free option
3. Create an option as CALL, maturity Friday 6 p.m. June 29, 2012, strike price $6.50, for 100 coins (we will create 3 such options)
4. Click 'Continue'
The system, using a formula, will calculate the amount of escrow required to cover this option. An insufficient USD message with the amount required for escrow will show, since we haven't deposited any money yet. For this option the amount is $105.99.
Since we will create 3 such options we go to Mt.Gox and generate a USD redeemable code for $105.99 x 3 = $317.97. We actually make it for $325.00 to cover any price moves while we create the option.
Go back to BitcoinOPX and click 'Deposit' from My Account and use the redeemable code for instant deposit. Next, go back and create the 3 options described above.
The 3 options will now be in your account ready to be put on sale. Under my account you will see your resulting USD and escrow balances. To this point you've spent no money, and taken no irreversible action. You can cancel the options and your balances will be updated.
Go ahead and click 'Sell to Open' on one of the options, which brings up the Trade screen. We are going to open a position. All the relevant information is already filled in except the "limit" amount, the lowest possible price we will accept for this option. Remember we want to lock in a bitcoin sale price $.65 higher than now, so we multiply number of coins which is 100 x $.65 = $65.00.
Click to send the order. If the option sells you will receive $65.00 minus a .65 trade fee = $64.35 USD in your account. Do this for the other two options. If all of them sell you will have $193.05 USD added to your account.
Notice this is approximately the $195 amount from above representing how much we gain or lose from a future price swing of 10%. What we have done is ensure we gain 10% up front.
Now let's look at what is going on.
You can withdraw the $193.05 and pocket it. That's profit free and clear. We have approx. $318 in escrow, and 3 open positions. Each position is a June 29 $6.50 CALL for 100 BTC. This means on that date if the weighted average BTC price is above $6.50 we owe the difference multiplied by number of coins to the option holder.
Let's say Dave bought all 3 options. Here are the possible scenarios:
1. Price is higher than $6.50
Let's say the price is $7.50. This is what Dave was hoping for and the reason he bought the options in the first place. He was speculating the price would go higher than $7.15, because anything past that and he makes his invested money back plus profit. Remember, on each option he paid $65.00. So pricing from $6.50 to $7.15 means he only recovers his $65.00.
You owe $7.50 - $6.50 (strike price) multiplied by 300 = $300.00
The system will automatically settle the options out of your escrow funds. You lose almost the entire amount. The remainder is returned to your USD balance which you can withdraw anytime.
So now you are minus $300.00 from your escrow. Other than that you have all your original invested money - plus the $193.05. All you need to do is sell your 300 coins on Mt.Gox which yields 300 x $7.50 = $2250. Now take off $300 to cover that escrow = $1950. Now divide $1950 by 300 coins = $6.50
You get $6.50 per coin plus the $193.05 (and Dave profits $105.00 on $195.00)
______
2. Price is exactly $6.50
Here you owe Dave nothing since there is no contract price difference. You sell your 300 coins on Mt.Gox at $6.50 = $1950, and you keep the earlier $193.05. You still made 10%
______
3. Price is lower than $6.50
Let's say the price is $6.00 Here you owe Dave nothing because CALL options only pay when market value is above the strike price. However, you still keep the earlier $193.05. You can sell your coins at $6.00 if you like, or hold them until the price rises again to $6.50, then sell, or... create more options on them!
In all cases you come out ahead, because you were going to sell and not hold anyway.
During our Beta soft launch there seemed to be good interest
However, after going live with real money we have yet to see much activity. I think it's because many don't understand how to make money with options. For example, there was repeated confusion about the difference between the Trade screen to place orders, and the Create options section. I don't think that's only due to the UI. I think many people are learning the fundamentals of how options work.
Let me answer the specific question from @Brunic:
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?
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?
This is a perfect example. Notice he says "they are going to be sold". That means his mind is already made up about selling, which is the key benefit of what I'm talking about.
Right now June 16, 2012 say the average price of bitcoins is $6.50, and @Brunic knows he wants to sell 300 coins at the end of the month. At BitcoinOPX every Friday options reach Maturity, meaning they can be exercised/settled. So let's pick the target date Friday, June 29, 2012 as our option Maturity.
Here is the dilemma: @Brunic knows he will sell in the future, but he doesn't know what the BTC price will be then. It can be higher or lower (or the same). Without using options he would probably just buy or sell whatever the price. All things being equal he would win, lose or break even 33% of the time. Say the price typically swings 10% bi-weekly. At our current price of $6.50 by Friday June 29 the price will be either $7.15 or $5.85 (or still be $6.50).
Selling 300 coins means a difference of 300 x $.65 = $195 potential gain or loss from the current price of $6.50. By selling regardless of price as bitcoin goes so @Brunic goes, some months good, some bad etc.
Options provide an... option. He knows the price is now $6.50, and he knows he will sell, so why not lock in an additional 10% on the current price free and clear? By creating and selling options he can do just that. He can lock in a future sell price of $7.15 for June 29th, today. Here's how:
1. Go to BitcoinOPX.com and create a free account
2. From My Account click 'Create Option' to create a free option
3. Create an option as CALL, maturity Friday 6 p.m. June 29, 2012, strike price $6.50, for 100 coins (we will create 3 such options)
4. Click 'Continue'
The system, using a formula, will calculate the amount of escrow required to cover this option. An insufficient USD message with the amount required for escrow will show, since we haven't deposited any money yet. For this option the amount is $105.99.
Since we will create 3 such options we go to Mt.Gox and generate a USD redeemable code for $105.99 x 3 = $317.97. We actually make it for $325.00 to cover any price moves while we create the option.
Go back to BitcoinOPX and click 'Deposit' from My Account and use the redeemable code for instant deposit. Next, go back and create the 3 options described above.
The 3 options will now be in your account ready to be put on sale. Under my account you will see your resulting USD and escrow balances. To this point you've spent no money, and taken no irreversible action. You can cancel the options and your balances will be updated.
Go ahead and click 'Sell to Open' on one of the options, which brings up the Trade screen. We are going to open a position. All the relevant information is already filled in except the "limit" amount, the lowest possible price we will accept for this option. Remember we want to lock in a bitcoin sale price $.65 higher than now, so we multiply number of coins which is 100 x $.65 = $65.00.
Click to send the order. If the option sells you will receive $65.00 minus a .65 trade fee = $64.35 USD in your account. Do this for the other two options. If all of them sell you will have $193.05 USD added to your account.
Notice this is approximately the $195 amount from above representing how much we gain or lose from a future price swing of 10%. What we have done is ensure we gain 10% up front.
Now let's look at what is going on.
You can withdraw the $193.05 and pocket it. That's profit free and clear. We have approx. $318 in escrow, and 3 open positions. Each position is a June 29 $6.50 CALL for 100 BTC. This means on that date if the weighted average BTC price is above $6.50 we owe the difference multiplied by number of coins to the option holder.
Let's say Dave bought all 3 options. Here are the possible scenarios:
1. Price is higher than $6.50
Let's say the price is $7.50. This is what Dave was hoping for and the reason he bought the options in the first place. He was speculating the price would go higher than $7.15, because anything past that and he makes his invested money back plus profit. Remember, on each option he paid $65.00. So pricing from $6.50 to $7.15 means he only recovers his $65.00.
You owe $7.50 - $6.50 (strike price) multiplied by 300 = $300.00
The system will automatically settle the options out of your escrow funds. You lose almost the entire amount. The remainder is returned to your USD balance which you can withdraw anytime.
So now you are minus $300.00 from your escrow. Other than that you have all your original invested money - plus the $193.05. All you need to do is sell your 300 coins on Mt.Gox which yields 300 x $7.50 = $2250. Now take off $300 to cover that escrow = $1950. Now divide $1950 by 300 coins = $6.50
You get $6.50 per coin plus the $193.05 (and Dave profits $105.00 on $195.00)______
2. Price is exactly $6.50
Here you owe Dave nothing since there is no contract price difference. You sell your 300 coins on Mt.Gox at $6.50 = $1950, and you keep the earlier $193.05. You still made 10%
______
3. Price is lower than $6.50
Let's say the price is $6.00 Here you owe Dave nothing because CALL options only pay when market value is above the strike price. However, you still keep the earlier $193.05. You can sell your coins at $6.00 if you like, or hold them until the price rises again to $6.50, then sell, or... create more options on them!
In all cases you come out ahead, because you were going to sell and not hold anyway.
Hey everyone,
By the way, yes we do salt and hash passwords with bcrypt, and we've made 12 characters the minimum password length now.
To receive a minimum 12 character password please click 'My Account' then 'reset password'.
I'll answer more questions shortly.
By the way, yes we do salt and hash passwords with bcrypt, and we've made 12 characters the minimum password length now.
To receive a minimum 12 character password please click 'My Account' then 'reset password'.
I'll answer more questions shortly.
Wow, that's what I get for not remembering where I am...
Trying to defend the integrity of a 6 character password to a room full of network professionals. *shakes head*
Okay, for the record I don't endorse using 6 character passwords as general practice. I was speaking extremely generally, in other words in terms of every use case requiring a password. As mentioned I believe security involves context. Securing a neighborhood forum site is not the same as a bank. My statement was about the lower bound of password length. That's where the 6 characters came from. For a neighborhood forum or dating site or similar I don't think it's wrong to say security experts agree at least 6 random characters, upper and lower, symbols etc. regard that as secure - for those kinds of sites - whereas common words like "love" are insecure.
I should have qualified that statement. That's my mistake.
The length of 12 characters seems to be popular in this thread as "very secure", but if it's a question of securing the data against the government suddenly that length doesn't seem so adequate. That's what I mean about context.
Of course longer passwords are always going to be more secure. I would love to require 150 character passwords, but usability becomes an issue. That's the only reason for adopting shorter passwords.
I wasn't trying to lecture anyone, least of all here... I was trying to make a case and defend the thought process behind our procedures. I'm certainly willing to take suggestions on security. Improving is always a goal. I feel we're all on the same side. We are the productive side of society, not the ones looking to steal, circumvent, and hack.
Continuing the rationale of assigning users passwords, it does seem to ensure users don't use one which unlocks their email for example. They would have to change their password to ours retroactively, and it would still unlikely be one used at other sites like LinkedIn, for example.
Not every user has the same security practices. But certainly we could change to user supplied passwords if that would be an improvement.
_______________________
Next, to address very valid concerns about level of funds and our operations, we purposely look to limit fund amounts. Storing 10,000 BTC would indeed change security context. Originally, we planned to back options with actual bitcoins, and were set up to work with BTCrow.com. However, that's now replaced with a contract for difference model where only the amount of funds representing the change in price movement is posted.
In any case, no funds are stored on the site and we manually approve every withdrawal. Even if our system is completely compromised the hacker couldn't move any funds. I also neglected to say every withdrawal request requires email confirmation, so a hacker would not only need account access, but to have access to the user's email account as well.
Regarding anonymity please see here: https://bitcointalksearch.org/topic/m.935881
I'll try and reply to the other questions later.
Trying to defend the integrity of a 6 character password to a room full of network professionals. *shakes head*
Okay, for the record I don't endorse using 6 character passwords as general practice. I was speaking extremely generally, in other words in terms of every use case requiring a password. As mentioned I believe security involves context. Securing a neighborhood forum site is not the same as a bank. My statement was about the lower bound of password length. That's where the 6 characters came from. For a neighborhood forum or dating site or similar I don't think it's wrong to say security experts agree at least 6 random characters, upper and lower, symbols etc. regard that as secure - for those kinds of sites - whereas common words like "love" are insecure.
I should have qualified that statement. That's my mistake.
The length of 12 characters seems to be popular in this thread as "very secure", but if it's a question of securing the data against the government suddenly that length doesn't seem so adequate. That's what I mean about context.
Of course longer passwords are always going to be more secure. I would love to require 150 character passwords, but usability becomes an issue. That's the only reason for adopting shorter passwords.
I wasn't trying to lecture anyone, least of all here... I was trying to make a case and defend the thought process behind our procedures. I'm certainly willing to take suggestions on security. Improving is always a goal. I feel we're all on the same side. We are the productive side of society, not the ones looking to steal, circumvent, and hack.
Continuing the rationale of assigning users passwords, it does seem to ensure users don't use one which unlocks their email for example. They would have to change their password to ours retroactively, and it would still unlikely be one used at other sites like LinkedIn, for example.
Not every user has the same security practices. But certainly we could change to user supplied passwords if that would be an improvement.
_______________________
Next, to address very valid concerns about level of funds and our operations, we purposely look to limit fund amounts. Storing 10,000 BTC would indeed change security context. Originally, we planned to back options with actual bitcoins, and were set up to work with BTCrow.com. However, that's now replaced with a contract for difference model where only the amount of funds representing the change in price movement is posted.
In any case, no funds are stored on the site and we manually approve every withdrawal. Even if our system is completely compromised the hacker couldn't move any funds. I also neglected to say every withdrawal request requires email confirmation, so a hacker would not only need account access, but to have access to the user's email account as well.
Regarding anonymity please see here: https://bitcointalksearch.org/topic/m.935881
I'll try and reply to the other questions later.
Old fashioned brute force. 000000000,000000001,0000000002,0000000003..........etc......etc (well actually one assumes that the the system is using at least a 8 characters so you generally start from there, also many people use the default passwords on their ISP routers. They are random but always the same length.)
Remember, one is preforming it locally with a captured handshake sequence, so there is no network traffic or logging going on.
Remember, one is preforming it locally with a captured handshake sequence, so there is no network traffic or logging going on.
Well, at cost 10 (compare to Vladimir's 15, which is a lot harder), my PC bcrypt's around 12 passwords per second. Assuming 92 symbols, you have slightly higher than 58 bits of entropy at length 9. So you'd need something 300 billion times more powerful than my PC to scan the complete range in 36 hours. Even with application specific hardware that would be impractical. Of course this assumes that the passwords are "truly" random.
The 36 hour example is when the length and parameters of the password are know.
The example used are ATT Uverse routers that use a 10 digit passkey. so the range is 0000000000 - 999999999. I usually split the range between two computers. Using a couple GPUS and the proper programs, I was able to throw around 100,000 - 125,000 passwords a sec at the packets, so 12 passwords a second is not even close to what a "hacker" would be able to do even on a normal PC.This was years ago, so GPU processing is even faster now, look at current mining rates.
I guess the main point I am trying to make, is the mistake of limiting the range of a password. One of the most valuable things a "hacker" can have when trying to crack encryption is hints on the range of the password. If he knows the length (or range), excluded symbols...etc. It greatly (exponentially) cuts down on the range the "hacker" has to brute force.
Random passwords are great, but provide no more protection to a true brute force (not dictionary, or rainbow table) crack of encryption done at a local level,with password parameters known, and the right hardware/software.
Some of the best server side password requirements allow for a large range (I suggest a minimum of 10 up to 64) of length and symbols (including the ever ignored space) and maybe a quick dictionary check to make sure common words are not used.
Even then, one will run into the human side of security. Make passwords requirements too complex and they end up on post-it's or text files placed the computer desktop.
Two-factor authorization is truly a way to thwart brute force hack, as brute forcing a password may not be all that difficult to a skilled hacker with the right equipment, once the second factor is introduced, I see it as end game- Into the realm of dam near impossible without government alphabet soup agency like abilities.
Old fashioned brute force. 000000000,000000001,0000000002,0000000003..........etc......etc (well actually one assumes that the the system is using at least a 8 characters so you generally start from there, also many people use the default passwords on their ISP routers. They are random but always the same length.)
Remember, one is preforming it locally with a captured handshake sequence, so there is no network traffic or logging going on.
Remember, one is preforming it locally with a captured handshake sequence, so there is no network traffic or logging going on.
Well, at cost 10 (compare to Vladimir's 15, which is a lot harder), my PC bcrypt's around 12 passwords per second. Assuming 92 symbols, you have slightly higher than 58 bits of entropy at length 9. So you'd need something 300 billion times more powerful than my PC to scan the complete range in 36 hours. Even with application specific hardware that would be impractical. Of course this assumes that the passwords are "truly" random.
Code:
#!/usr/bin/perl
use common::sense ;
use Digest;
use Data::SimplePassword;
my $user = 'username' ;
my $password = 'cleartext';
# $salt must be exactly 16 octets long
my $salt = Data::SimplePassword->new->make_password(16) ;
# $cost is an integer between 1 and 31, $hash will be 31 b64 symbols
my $hash = Digest->new('Bcrypt')->cost(15)->salt($salt)->add($password)->b64digest;
say "$user $salt $hash" ;
use common::sense ;
use Digest;
use Data::SimplePassword;
my $user = 'username' ;
my $password = 'cleartext';
# $salt must be exactly 16 octets long
my $salt = Data::SimplePassword->new->make_password(16) ;
# $cost is an integer between 1 and 31, $hash will be 31 b64 symbols
my $hash = Digest->new('Bcrypt')->cost(15)->salt($salt)->add($password)->b64digest;
say "$user $salt $hash" ;
Here this is how you hash passwords, once and for all people, just pass username and password, calculate hash, then either store username, salt and hash in db when creating the user or changing the password, or check against the database to do auth. Just wrap it into a function or a class and you are golden.
Want to be even more cool? Make user's browser to calculate SHA256 in browser (i.e. client side javascript) then pass it to you instead of cleartext and your servers will never even see the cleartext password in the first place (but still do hashing as above, of course).
Stop pulling linkedin thing FFS!
The above code is hereby released into public domain.
THIS SOFTWARE IS PROVIDED BY THE ME "AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE I BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
That's why hash functions better fit for this purpose exist. (EDIT: Hmm, apparently WPA uses PBKDF2, but then again how on earth are you able to brute force 10 character random strings is beyond me.)
Old fashioned brute force. 000000000,000000001,0000000002,0000000003..........etc......etc (well actually one assumes that the the system is using at least a 8 characters so you generally start from there, also many people use the default passwords on their ISP routers. They are random but always the same length.)
Remember, one is preforming it locally with a captured handshake sequence, so there is no network traffic or logging going on.
I remember attending a conference at a network security company recently (for the ethical hacking class I took last semester), that pointed out websites that advertise their password requirements help the hackers out, now they have parameters and do not have to use the whole range of combinations to brute force.
In fact, 7 character password you say, you just knocked the the time down to crack stolen account data exponentially, because the hacker knows the exact length of the password and only has to locally brute force that range.
9 characters is NOTHING, in past ventures with only a couple of Nvidia GPU, one was about to brute force WPA2 encrypted handshakes with 10 character pass phrases in about 36 hours only doing passwords in the Kilos per second range.
My current mining rig can do about 3 Billion SHA256 hashes per second.
My current mining rig can do about 3 Billion SHA256 hashes per second.
That's why hash functions better fit for this purpose exist. (EDIT: Hmm, apparently WPA uses PBKDF2, but then again how on earth are you able to brute force 10 character random strings is beyond me.)
Most successful hacks are in the form of social engineering (Easier to have the owner/user hand you the keys than to pick the lock).
After that, most breaches are a result of exploiting un-patched software, finding a 0 day exploit or even something as simple as default user/password combos not being changed.
Once one has access to your server, it is just a matter of coping over what they want
After that, most breaches are a result of exploiting un-patched software, finding a 0 day exploit or even something as simple as default user/password combos not being changed.
Once one has access to your server, it is just a matter of coping over what they want
+1
Seriously? To log into the accounts and withdraw the funds ($ and Bitcoin) from the users.
Ah, I was mostly focused on the "passwords are now in the open and they might get cracked in the future" scenario. I don't think it is realistic to assume that 9 character fully random passwords can be brute-forced in a practical amount of time, with the assumption that they are properly stored (bcrypt, PBKDF2, etc.), though I don't think salting is actually necessary. If they aren't properly hashed, then there is still no sense in debating password length. I'm not vouching for the service or anything, it's just that 9 random characters instead of user-supplied passwords is not a bad idea by itself, which seems to be the main reason you feel the site is insecure. We can move the debate elsewhere though, all this is probably off-topic.
9 characters is NOTHING, in past ventures with only a couple of Nvidia GPU, one was able to brute force WPA2 encrypted handshakes with 10 character pass phrases in about 36 hours only doing passwords in the Kilos per second range.
My current mining rig can do about 3 Billion SHA256 hashes per second.
People really need to stop taking the "Hacking" they see on TV as the way it is. (Two hackers do not use the same keyboard to try and counteract a hack..LMAO)
No hacker is brute forcing the front end of a web site (7 tries is in reality kind of loose, most high security systems lock out after three, requiring contact with a systems administrator to reinstate.)
Most successful hacks are in the form of social engineering (Easier to have the owner/user hand you the keys than to pick the lock).
After that, most breaches are a result of exploiting un-patched software, finding a 0 day exploit or even something as simple as default user/password combos not being changed.
Once one has access to your server, it is just a matter of coping over what they want, and break the encryption on the database, file , etc ... locally with their multi-GH system.
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.
Your miners are irrelevant; the ROI he is talking about will be in addition.
The only thing you give up is the increase in value if the price rises to more than the strike price. Else, it's just free money.
Essentially, you are selling your promise to sell a certain number of bitcoins at a certain price. Say, 10 coins at $6. The person you are selling your promise to can choose to call you up at anytime until the expiration date of your promise with the $60 and you'll have to sell 6 coins to her at the $60, regardless if it's $2 or $10 at mtgox at that time.
Of course, she'll not call unless mtgox is more than $6.
It wouldn't be a bad idea to get a copy of the Characteristics and Risks of Standardized Options. It is free and would give a good outline of how options in general works, and the upsides/risks involved.
Seriously? To log into the accounts and withdraw the funds ($ and Bitcoin) from the users.
Ah, I was mostly focused on the "passwords are now in the open and they might get cracked in the future" scenario. I don't think it is realistic to assume that 9 character fully random passwords can be brute-forced in a practical amount of time, with the assumption that they are properly stored (bcrypt, PBKDF2, etc.), though I don't think salting is actually necessary. If they aren't properly hashed, then there is still no sense in debating password length. I'm not vouching for the service or anything, it's just that 9 random characters instead of user-supplied passwords is not a bad idea by itself, which seems to be the main reason you feel the site is insecure. We can move the debate elsewhere though, all this is probably off-topic.
Jump to: