When SegWit happens we will re-adjust.

Sorry but I could not understand..?

Dear staff,

I really understand that importance of 2FA, even more so when money is involved. Steam gives you a code that I like to call the 'please write this down, because your phone might explode code'. Your Google auth recovery protocol has no such thing.
----This results in either having to say: 'Without codes generated by your old device we can\'t do anything for you.' or 'Well you can login to your steam account, so it must be you.'. The first leaves no room for recovery after the device/app is lost/broken and the second defeats the purpose of 2FA.
----I am no IT advisor and my advice should never be taken as gospel, but this is a quick summary of my understanding of the Google auth: When you setup Google auth you share a secret seed with the user, through the QR code. Upon importing the secret through scanning the code, the time synced cryptographic hash function, both you and the users device know, can generate hashes of which you take the first six chars in base 10. The only way someone can know the resulting 6-digit code is by knowing the secret seed. This assures that the person trying to authenticate has a copy of the secret seed and is (if the shared secret seed hasn't been stolen) authorised by the owner of the phone and by extention the owner of this steam account, to do whatever important stuff the user did on the site that required more authentication, F.e. sending funds to an external wallet.
----My proposed problem: This works great, but there is the problem of losing/destroying the phone/app or in some other way not being able to generate new codes. This leaves you with the delemma that the user is no longer able to do any calculations on the shared secret. This leaves you with a user that knows their steam username/password/steamMobileAuth-combo that can't identify themselves using the established shared secret seed.
----My proposed solution: When the user has added the Google auth succesfully display the result of a calculation similar to this -> [substr(hash('sha256', $sharedSecret . 'ICE' . $generationAttempt), 0, 8)] on the screen a require the user to write it down*. This will give the user something that looks like 'c3820f17'. This could be hashed ones again in your database and when the user requests and Google auth reset and presents this, you can hash it and compare that to the hash you made. If they match, that user has witnessed the activation of the Google auth and now has a way to prove their identity. $generationAttempt could be incremented by one, if the user wants to generate a new recovery code, in case they suspect that someone nefarious has seen their code. Generating a new code like this should require: 'A fresh session from steam (no cookie resumed session) and a current Google auth code'.
----A second less 'code heavy' solution could be requesting the user to sign a message with the bitcoin private key, this proves their identity on the blockchain and in turn proves that they had access to the Google auth at the time that the first transaction you did to that address took place.

----I, myself, really hate it when someone tells me what to do or how to do it. Please don't take this as an insult, but merely a way to improve. I just want my funds to be safe and would like that all users of your site can have the same feeling.

----Up until ths point I have presumed that you have the shared seed and not Google. If all this stuff is handeled by Google, you could replace the shared seed in the calculation between these things ->[] with something completely random. Do not use the first received 6-digit code (as was my first idea), since keyloggers and stuff. Upon a request to change the back-up code, you could simply generate some new random noise data.

----*Do not require the user to retype the displayed code, since this would allow keyloggers to see it. I know that there are still problems with screen capture or any other form of user side capture or the network traffic between you and the user being compromised (long live https). If the users computer had screencapture malware running they could just as easily have grabbed the secret seed. (Ones again I presume that the shared secret seed is actually in the QR code and not just a one time URL to a place where the secret is received from, that only allows a single use. If that is the case the screencap argument falls apart.)

Many thanks for your time and attention. I am really sorry tha tit took so long to explain. Please don't take my advise as gospel and talk to your security expert.

Yours faithfully,

RadioQueue

P.S. EDIT: The tabs/spacing was removed, so I dumped in some '-' as a replacement.

Suggestion to change the way we set out btc fees.
I have read a few pages of the bitcoin related problems forum. Many people have complained in the past about their transactions getting stuck because of unknown transaction sizes making it way harder to judge the most appropriate fee level. May I recommend using a different measure than just raw fee level, such as shatoshi's fee per byte, as displayed on bitcoinfees.21.co. This allows way greater control and gives the certainty to the user.
One might still end up with the problem that setting a fee of x shatoshi's per byte on low value transactions may cause them to lose a great percentage of their value to fees if the transaction happens to contain many inputs. This should be stated very clearly when choosing this option. Being allowed to set something like, 100 shatoshi's per byte up to 40000 shatoshi's, would be nice for people who know what they are doing.
Adding the text, Please keep in mind that your withdrawal will have to be manually verified. This may take up to 48 hours., to the withdraw confirm message, would inform people that they will have to wait a bit longer than many may expect when first using the withdraw option.
P.S. The amount of available fee levels is quite low. F.e. 0.0001btc and 0.0005btc is a factor of five. A slider that goes from 0.0001 to 0.003 would give more options and clean up the user interface.

Since Steam no longer allows gift trading we have already shifted our focus on something else. I would use LTC but no longer want to spend the time on updating this website.

How about add PUBG keys as deposit? Thanks for reply

I will look into PUBG item support, thanks for the suggestion.

Please add KEY-mBTC market. I want to be able to set price in mBTC and not USD, so people don't take advantage of temporary dips in BTC value to take keys at low BTC prices. (1000 mBTC = 1 BTC)