Just a heads-up...
When I tried to execute an option just after buying a small group of them, it went to a greyed out screen with the message ""Could not get security lock at <4-figure number I can't remember>" and failed to perform the execute.
I got the error 2 or 3 times, but when I came back a few minutes later the execute worked fine doing the same action.
It was ASICMINER-PT call options. I use Yubikey for 2FA.
Topic: [BTC-TC] Virtual Community Exchange [CLOSED] - page 91. (Read 316534 times)
If you want real-time trade data the only thing we have going right now is a feed to #bitcoin-assets on IRC. (http://bitcoin-assets.com/) I know at one point kakobrekla was looking into setting up a websockets feed, you might connect up and ask him how that's going.
Very nice! Thanks!
Browser compatibility, load time, and limited dev time. 
Speaking of that. You said /api/tradeHistory is refreshed about every 10 minutes. It was some kind of xy-problem, so I rephrase: what's the best way to continiously fetch trade data on one or more assets and what are the limitations? Does /api/tradeHistory/SYMBOL has a 10 minute delay, too?
I think just about everything api history-related has a 10 minute cache associated with it. As the site grows and we can throw more hardware at it, we'll probably reduce the cache time, but for now that's where it is. The db queries are just too heavy to do frequently.
If you want real-time trade data the only thing we have going right now is a feed to #bitcoin-assets on IRC. (http://bitcoin-assets.com/) I know at one point kakobrekla was looking into setting up a websockets feed, you might connect up and ask him how that's going.
It is possible that in the future we'll setup a twitter feed or our own websocket setup.
Cheers.
Has anyone made some C# code for the OAuth authentication with BTCT? Unlike PHP and Python, there's no standard OAuth library for C# and user-made classes and examples on the web don't seem to be able to auth properly with BTCT (signature_invalid errors).
edit: Nevermind, managed to butcher some example long enough to make it work.
edit: Nevermind, managed to butcher some example long enough to make it work.
Browser compatibility, load time, and limited dev time.
Speaking of that. You said /api/tradeHistory is refreshed about every 10 minutes. It was some kind of xy-problem, so I rephrase: what's the best way to continiously fetch trade data on one or more assets and what are the limitations? Does /api/tradeHistory/SYMBOL has a 10 minute delay, too?
How to see Price&Volume Graph of all time ?
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Maybe this helps a bit: http://coinflow.co/
I wondering why did Burnside not do this.
Browser compatibility, load time, and limited dev time.
How to see Price&Volume Graph of all time ?
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Maybe this helps a bit: http://coinflow.co/
I wondering why did Burnside not do this.
How to see Price&Volume Graph of all time ?
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Maybe this helps a bit: http://coinflow.co/
How to see Price&Volume Graph of all time ?
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Can I change the period of Price&Volume Graph ?
I'm Chinese,hard to use the website.
Facebook uses a persistant cookie to recognize the endpoint and shuts down the acccout (if enabled) till you confirm via the 2nd factor that it's actually a legit new machine. Google checks geo location and if it's way off, it proceeds with security questions. Via browser characteristics one can generate an almost unique fingerprint by using system fonts and plugins as input.
You could create a delay between each failed login and double the delay duration for each additional fail. If you'd apply that on the normal login, someone evil could easily exploit the mechanism to lock someone else out, but I think for the PIN request it's fine anyway. And even a cap of a few seconds would kill brute force more or less.
Thus logically, an attacker could bruteforce your PIN and change your email address on file.
You could create a delay between each failed login and double the delay duration for each additional fail. If you'd apply that on the normal login, someone evil could easily exploit the mechanism to lock someone else out, but I think for the PIN request it's fine anyway. And even a cap of a few seconds would kill brute force more or less.
We do lock out after X failed PIN requests in Y minutes.
Cookie matching or heuristically matching the hardware making the request is a distant second place to actual 2FA.
Cheers.
Facebook uses a persistant cookie to recognize the endpoint and shuts down the acccout (if enabled) till you confirm via the 2nd factor that it's actually a legit new machine. Google checks geo location and if it's way off, it proceeds with security questions. Via browser characteristics one can generate an almost unique fingerprint by using system fonts and plugins as input.
You could create a delay between each failed login and double the delay duration for each additional fail. If you'd apply that on the normal login, someone evil could easily exploit the mechanism to lock someone else out, but I think for the PIN request it's fine anyway. And even a cap of a few seconds would kill brute force more or less.
+1 Thus logically, an attacker could bruteforce your PIN and change your email address on file.
You could create a delay between each failed login and double the delay duration for each additional fail. If you'd apply that on the normal login, someone evil could easily exploit the mechanism to lock someone else out, but I think for the PIN request it's fine anyway. And even a cap of a few seconds would kill brute force more or less.
Facebook uses a persistant cookie to recognize the endpoint and shuts down the acccout (if enabled) till you confirm via the 2nd factor that it's actually a legit new machine. Google checks geo location and if it's way off, it proceeds with security questions. Via browser characteristics one can generate an almost unique fingerprint by using system fonts and plugins as input.
You could create a delay between each failed login and double the delay duration for each additional fail. If you'd apply that on the normal login, someone evil could easily exploit the mechanism to lock someone else out, but I think for the PIN request it's fine anyway. And even a cap of a few seconds would kill brute force more or less.
Thus logically, an attacker could bruteforce your PIN and change your email address on file.
You could create a delay between each failed login and double the delay duration for each additional fail. If you'd apply that on the normal login, someone evil could easily exploit the mechanism to lock someone else out, but I think for the PIN request it's fine anyway. And even a cap of a few seconds would kill brute force more or less.
I'd recommend anyone in Windows getting at least KeyScrambler FREE to keep the browser protected, https://www.qfxsoftware.com/index.html
It works pretty well against keyloggers.
It works pretty well against keyloggers.
Maybe not the simplest thing to add, but is there a way to add an extra page after normal login (instead of redirecting to /portfolio or elsewhere) that could force extra auth, then allow users to adjust their own security (as is currently done for 2FA). Alice doesn't care and just uses a password and no heuristics. Bob uses 2FA and wants a second form of 2FA to be required if his country/browser/OS leave some predetermined list (usual or manually set). Might also be a way to separate login and normal 2FA similar to some two-step logins that are touted as more secure (I know my bank uses it, remembers my username and it shows as "btha******" then asks for password on the next screen), though I've never understood why it's supposed to help if there's no extra steps beyond the normal password.
I would like the option to lock users out when their country of origin doesn't match up. I think I mentioned that above. It'd be an option on a per-user basis.
The banking two-step setup I'm not sure about either. I do know that the little cartoon or image or whatever that they show you is supposed to help prevent clones of the site from taking your login/password, but how many people do you really think would notice if one time out of ten it just wasn't there?
Personally I think all credit and debit cards should come with a little flexible LCD on them with a rotating 6-digit auth code for use when logging into the corresponding bank's online system. Such a system would also prevent all cardholder-not-present theft for merchants implementing it... far better than the retarded extra three digits on the back of the card that any keylogger can capture. -rant as a visa/mc merchant- ... but it'll be a cold day in hell that the banks actually care about the security of the system because with the current system, the merchants pay for -all- of the theft. (chargeback == money forcefully withdrawn out of the merchant's bank account) there is zero motivation for the bank to pay the extra 50 cents per card as long as it's up to the merchant to bear the brunt of the fraud! In fact... the banks profit from the fraud, as there is frequently a chargeback fee assessed to the merchant and/or percentage processing fees incurred in the transfers. -end rant-
Yet another reason to love Bitcoin.
2FA you offer is only usable if you have a phone that supports it.
Today it is really easy to figure out the geographical location of IP address and clients "typical" location.
If I start suddenly logging in from China, trust me, something is wrong and BTC-TC should ask me for PIN or something before letting me in.
Even better, lock down my account and send me a e-mail.
Today it is really easy to figure out the geographical location of IP address and clients "typical" location.
If I start suddenly logging in from China, trust me, something is wrong and BTC-TC should ask me for PIN or something before letting me in.
Even better, lock down my account and send me a e-mail.
Or a Yubikey, which is cheap, and way better.
But there are desktop versions of google authenticator too. You could conceivably use it on your laptop, when logging in via your desktop for instance, and still have the 2-Factor intact.
I have already (as of about a week ago) started collecting country data on a per-user basis. I don't know if anyone noticed, but in the account settings you can already set your country of residence. The default is set based on your initial login. (as of when I turned it on)
After this evening's incident, I went a step further and added display of the country to the withdrawal queue management interface we use internally. This is not a silver bullet though. Not all withdrawals will be manual.
I suppose the next step could be a country lockout... "Only allow logins on this account from these [multi-select interface] countries.".
A service I'm working on (not really relating to btc-tc) works this way. It also takes in account your browser and operating system, system language, etc with a heuristically based ranking system. For example, signing in from an iPhone when you generally use a mac is a lot less suspicious than if you started using Internet Explorer when you've always signed in from Linux.
And if you're from Australia but your system language is Chinese, this helps you - logging in from a non Chinese computer in Australia will still flag as suspicious.
And if you're from Australia but your system language is Chinese, this helps you - logging in from a non Chinese computer in Australia will still flag as suspicious.
I like this approach. I just don't have a lot of bandwidth to deal with the inevitable customer service overhead this would come with. Outside of a vulnerability in the site, which the heuristics wouldn't help with, the 2FA is going to seal things up pretty tight anyway.
GLBSE had maker-taker. One of the very few things I liked about the site (maybe the only thing - can't think of a second off-hand). So anyone who used GLBSE should be used to it (though I expect most never even noticed).
and bitfloor had it for BTC/USD
GLBSE had maker-taker. One of the very few things I liked about the site (maybe the only thing - can't think of a second off-hand). So anyone who used GLBSE should be used to it (though I expect most never even noticed).
Burnside, have you considered maker/taker pricing?
Yeah. I wouldn't mind doing something that shifted some of the fee to the maker, and reduced it on the taker. Would be curious to hear from the masses what they think?
Hope you mean other way round.
Maker should get the lower or zero fee (for adding liquidity), taker the larger (or whole) fee for removing liquidty. It's great for removing spreads - with people buying bidding 1 satoshi below ask rather than buying so as to avoid a fee.
The other way round (which you said) works to discourage people placing orders - leaving empty order books.
Getting late here. Yes, the reverse of what I said. We want to encourage orders on the books.
Yeah imo its basically THE answer to this whole liquidity/spreads conversation, except that maker should get a rebate, not just zero fee. You could change .2% fee on trades to something like .3% fee on taker, .1% rebate on maker (or .4/.2)
Have fun explaining this to customers though.
meh, customers that don't understand it would probably not notice a difference...to them it would just seem like a fee change from .2% to .3 or .4%. maker/taker pricing is standard on all the major US stock exchanges, how many retail investors do you think are aware or pay attention to it?
http://www.marketswiki.com/mwiki/Maker-taker
Keyloggers are probably he main source of account theft of pretty much any account that has value stored in it. So if you want to prevent unauthorized withdrawals, a 2FA option that is keylogger-proof is needed.
Didn't mean to belittle the current 2FA as it is the safest method. I'm really just noting that there is a market (need?) for more than one option of 2FA for those of us that don't carry smartphones.
There is for BTCT.co: YubiKey (https://www.yubico.com/products/yubikey-hardware/yubikey/). It's effectively the same thing as the smartphone-app, but then in the form of a separate device that you can carry on your keychain or whatever.
Keyloggers are probably he main source of account theft of pretty much any account that has value stored in it. So if you want to prevent unauthorized withdrawals, a 2FA option that is keylogger-proof is needed.
Didn't mean to belittle the current 2FA as it is the safest method. I'm really just noting that there is a market (need?) for more than one option of 2FA for those of us that don't carry smartphones.
Jump to: