Topic: [BTC-TC] Virtual Community Exchange [CLOSED] - page 92. (Read 316457 times)

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)

Getting late here.  Yes, the reverse of what I said.  We want to encourage orders on the books. 

I guess. Keyloggers don't really bother me 
I was just looking for a 2FA alternative, to prevent unauthorised withdrawals, other than the 'link to address' method you offer.

TBH, I never really understood how an email account was a 2nd factor against something like a keylogger?  99% of us probably use their email account on the same PC as their browser?

Would like to see a 2FA email option similar to Blockchain.info. 

google 2FA bugs me !

Oh, while we are at it... the problem here is that the PIN is totally useless: if they sniffed your password, they most likely sniffed your PIN too, so it doesn't actually offer any protection...

I think it would be much better to remove it completely, since it may offer a false sense of protection to some users, and an annoyance with no benefit for the others...

I'd stick with real 2FAs, maybe adding an email 2FA in case you find the time to code it.
(let me know if you need any help)

Or did I miss something?

- The account page still uses PIN codes for many account settings, including the password, PIN, and email account changing interface.

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.

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.

mmmh... I have always kept it enabled for trades and withdrawals, and disabled for login, assuming in this case an eventual attacker may do nothing more than just looking at my portfolio... or did I miss something?

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.

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.

~~ PSA PSA PSA ~~

btct.co accounts are definitely on the radar for hackers.  I just finished replying to a very unhappy user with a compromised account.  (Logs showed logins from China, South Korea, and Japan, all in a 24 hour window.)  It's only the second such case I've heard of over the last 6 months, but that makes two accounts too many.

TURN ON 2FA.
 

~~ PSA PSA PSA ~~

btct.co accounts are definitely on the radar for hackers.  I just finished replying to a very unhappy user with a compromised account.  (Logs showed logins from China, South Korea, and Japan, all in a 24 hour window.)  It's only the second such case I've heard of over the last 6 months, but that makes two accounts too many.

TURN ON 2FA.
 

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.

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?

Burnside, have you considered maker/taker pricing?

Well, with an increased minimum increment the other bidder either has to place the same bid that I placed, and therefore not have priority on order execution (at least, that's how I assume it work. Burnside, can you confirm that if 2 orders are placed at the same price, the oldest is executed first if a market order comes in?) or at an increased price that actually has a non-trivial markup over my bid.

I agree that the we should err on the side of caution when increasing the increment. It should not be so large that the market is distorted. Currently, there is 0.2% fee on each trade, so I would say that the minimum increment should be somewhere between 0.05% and 0.1% or so. But there is at least a lot of improvement to be had from the current situation where you can have 0.003% increments (or less).

The number-of-decimals solution that Burnside proposed looks to be the most effective way to address the issue. It also avoid the problem that you rightfully pointed out (and that I didn't quote) of bid increments only applying to the top bid (or bottom ask) and that bots can circumvent it by placing a dummy top bid and taking it down directly after.

I don't like the solution that was posted above, where a minimum total bid value (measured in BTC or LTC) is required to overbid the top bid. Small players should be able to set their price just like big players (and it still doesn't limit well-designed bots). Overbidding is an essential part of the market, but we should make sure that people (or bots) are actually overbidding and not just abusing the system to get priority on execution by placing what comes down to effectively the same order with a little trickery.