[BTC-TC] Virtual Community Exchange [CLOSED]

[ajolly]

I'm getting 'Access temporarily denied." errors when trying to log in. Anyone else having this issue?

[pascal257]

Thank you.  I have found two potential points of exit from the code where the security lock was not being released prior to exiting:

  - One related to backend bitcoind failure, which I do not think was the cause here because there's logging that would have been seen if this were the case.
  - Another which may be the smoking gun was a DDoS prevention piece that was intended to run once at init, but was being called twice because of a double layer of validation in the bid/ask processing methods.  I've fixed it to only do the DDoS test the first call per run.

Hopefully it ends up being taken care of now, but I've also added more logging/debugging code a bunch of places to help out if this doesn't end up taking care of it.

Cheers.

Have you already applied the code. I just tested it and the problem occurred again.

   yes. 

    

Any progress on this? As I said the problem occurs when filling an existing bid/ask order via the API.

[Trillian]

Are the buy/sell fees 0.2% with 2FA, because my 2FA is turned on and my fees are 0.25% according to the My Trades page?

[Rannasha]

Are the buy/sell fees 0.2% with 2FA, because my 2FA is turned on and my fees are 0.25% according to the My Trades page?

Apparently the fee-discount only applies if you use 2FA for trades. If you only enable 2FA for logging in, you still pay 0.25%. This should be clarified on the website, because I had also assumed that using 2FA just for logins already provided the fee-discount.

edit: scratch what was in the edit, turns out I fail at math.

[junkonator]

Are the buy/sell fees 0.2% with 2FA, because my 2FA is turned on and my fees are 0.25% according to the My Trades page?

Apparently the fee-discount only applies if you use 2FA for trades. If you only enable 2FA for logging in, you still pay 0.25%. This should be clarified on the website, because I had also assumed that using 2FA just for logins already provided the fee-discount.

Ugh. I simply assumed .2%, too and didn't check. This sucks, thanks for the heads-up Trillian/Rannasha!

[Trillian]

That clarifies everything, thx.

So you really have to work for that 0.05% discount!

[Rannasha]

Ok, turns out I fail at math, so there was no discrepancy between email and trade history. Conclusion is that if you use 2FA only for logins, you still pay 0.25%.

The FAQ says

    Trades using 2FA (Buyer): 0.2% (Trade Value X 0.002)
    Trades using 2FA (Seller): 0.2% (Trade Value X 0.002)
    Trades not using 2FA (Buyer): 0.25% (Trade Value X 0.0025)
    Trades not using 2FA (Seller): 0.25% (Trade Value X 0.0025)

So I guess that this does imply that you have to actually *trade* with 2FA, not just log in with it, to get the discount.

[MonkeyMarcel]

When can I expect an iPhone App?

[Progressive]

Even more important: why the Android app stopped working? It was great.

[pascal257]

I'm getting 'Access temporarily denied." errors when trying to log in. Anyone else having this issue?

Please make sure to use another username then on the forum. I guess there are some jokers blocking the accounts of others.

[piecinitup]

When can I expect an iPhone App?

iOS app would be amazing!

[Rannasha]

Quick question regarding the timestamp of trades in the trade history csv from the API: In which timezone are these timestamps? I'm currently getting GMT+1 (while being in GMT+2 myself) and I'm wondering if this will stay GMT+1 all year round or if it'll switch back to GMT when summertime ends (that is, the timestamp follows British time, BST).

[ajolly]

I'm getting 'Access temporarily denied." errors when trying to log in. Anyone else having this issue?

Please make sure to use another username then on the forum. I guess there are some jokers blocking the accounts of others.

I doubt that is the case - I have different usernames per site to avoid that issue.  I did manage fine to login from a different IP, not sure what the problem was.

[burnside]

Thank you.  I have found two potential points of exit from the code where the security lock was not being released prior to exiting:

  - One related to backend bitcoind failure, which I do not think was the cause here because there's logging that would have been seen if this were the case.
  - Another which may be the smoking gun was a DDoS prevention piece that was intended to run once at init, but was being called twice because of a double layer of validation in the bid/ask processing methods.  I've fixed it to only do the DDoS test the first call per run.

Hopefully it ends up being taken care of now, but I've also added more logging/debugging code a bunch of places to help out if this doesn't end up taking care of it.

Cheers.

Have you already applied the code. I just tested it and the problem occurred again.

   yes. 

    

Any progress on this? As I said the problem occurs when filling an existing bid/ask order via the API.

I think it may actually be working for you.  I see a trade in the logs:  Aug  8 15:52:16 UTC.  I think some of the code caching or something on the site made it so the update took a few hours the other day.  It shouldn't work like that, but I saw a post shortly after that saying it was working so I left it be. 

Logs show two failed lock errors in the last 12 hours.  (in comparison, there were sometimes hundreds over the last couple weeks.)  The two that did fail in the last 12 hours look like legitimate failures.  Both are on labcoin, and I know there was some high volume going on when they occurred.

My next steps:
    - Extend the wait time.  It's 30 seconds right now, I may extend it to 60 seconds.
    - Speed up the trade engine.  This has been an ongoing process and I'll keep after it.

Cheers.

[burnside]

When can I expect an iPhone App?

iOS app would be amazing!

Apple isn't too keen on Bitcoin at the moment unfortunately. 

[burnside]

Quick question regarding the timestamp of trades in the trade history csv from the API: In which timezone are these timestamps? I'm currently getting GMT+1 (while being in GMT+2 myself) and I'm wondering if this will stay GMT+1 all year round or if it'll switch back to GMT when summertime ends (that is, the timestamp follows British time, BST).

The timezone selector stores your option not as GMT+/-, but as the actual locale you select.  So part of the year (unfortunately, and I need to fix this...) the drop-down is actually incorrect for locales that recognize DST.

So for instance, if you select "Europe/Brussels", that is what gets stored in the DB, and that is what all the time calculations will be based on, taking DST into account IF that locale recognizes it per Linux's locale settings.

Hope that helps make sense of it.  I do need to dynamically generate the display in the dropdown of GMT+XX:00 or GMT-XX:00, etc.  PHP makes it a bit of a PITA though.

[junkonator]

My next steps:
    - Extend the wait time.  It's 30 seconds right now, I may extend it to 60 seconds.
    - Speed up the trade engine.  This has been an ongoing process and I'll keep after it.

Does that mean the time between two API trades is 30 seconds? If so please don't extend it to 60 

[pascal257]

Any progress on this? As I said the problem occurs when filling an existing bid/ask order via the API.

I think it may actually be working for you.

Cheers.

Yes I can confirm it works flawlessly on direct bid and direct ask. Awesome!

[Rannasha]

Quick question regarding the timestamp of trades in the trade history csv from the API: In which timezone are these timestamps? I'm currently getting GMT+1 (while being in GMT+2 myself) and I'm wondering if this will stay GMT+1 all year round or if it'll switch back to GMT when summertime ends (that is, the timestamp follows British time, BST).

The timezone selector stores your option not as GMT+/-, but as the actual locale you select.  So part of the year (unfortunately, and I need to fix this...) the drop-down is actually incorrect for locales that recognize DST.

So for instance, if you select "Europe/Brussels", that is what gets stored in the DB, and that is what all the time calculations will be based on, taking DST into account IF that locale recognizes it per Linux's locale settings.

Hope that helps make sense of it.  I do need to dynamically generate the display in the dropdown of GMT+XX:00 or GMT-XX:00, etc.  PHP makes it a bit of a PITA though.

Does this also cause the CSV-trade-history and the trade history on the webpage to be different? Right now the webpage shows my local time for my trades, while the time in the CSV is an hour behind.

Also, would it be possible to just select UTC as timezone and then deal with timezone business / DST locally? Or just have the API always return time-data in UTC.

[stslimited]

"Access Temporarily Denied"
grr