[REQ] BTC-E prices - Page 1

March 15, 2014, 6:18 p.m.

I know the choice of using Bitstamp's price could not please everybody, but it's just a price. If Bitstamp price is too 'high' you could always reduce the price of your goods.

The whole website has to use the same Bitcoin price. It cannot be $636 in one shop and $625 in another.

Potato

March 15, 2014, 7:23 p.m.

https://bitcoinaverage.com/api.htm

The BitcoinAverage price might keep people safer from any strange price fluctuation on 1 exchange? (for example, the price on BTC-E dropped to below 200 for about 1 minute last month, because someone cashed out US$4 million worth of BTC all at once)

Nick

March 15, 2014, 11:21 p.m. (Last edited by Nick on March 16, 2014, 12:45 a.m.)

I honestly don't see why it can't, if user A wants to sell their product at one site's rate because they trust their community more than they trust another's, I feel that should be their judgement.

As for selling (And reducing the price of our goods), this is actually inverted, Bitstamp has a higher value per bitcoin, which means the value per USD is actually less (Imagine BTC was $1 per, and, I was selling something for $5, $5/1 = 5BTC, if it was $100 per, however, $5/100 = 0.05BTC.), so, users on bitstamp will actually have to increase their prices to match BTC-E's rate, even then, that's not very accurate, as, BTC-E isn't always X much higher than bitstamp.

Oh, on another note, can I ask what actually triggers the deposit? I've made two deposits so far, one got into my account after about twenty minutes and one confirmation, the other took about two hours and eight confirmations, any insight as to why? It currently seems to me like you're doing something incorrect in the backend to have such fluctuations on time, and, will drive away new customers. Imagine someone who isn't into trading, and, just wishes to buy a single game from someone on here and that's that, they'll deposit their money (Which, I still think drives people away, the whole 'deposit then trade', but, I understand why you did it, reserving items for people while BTC confirms = bad idea), have to wait an unknown insanely long time (I recommend either one confirmation, or, two (Two protects against orphaned blocks about 99.999999% of the time)), to trade with a bot, to then have some left over money in their account their account they have to pay a withdraw fee (I understand you're not applying that fee to them).

Another idea would be something like:-
1. User selects what game they want (While logged out of the service, this all assumes they don't want to "Sign in through steam", as, lots of people assume this as phishing, as a developer myself, I do realize this is just an OpenID setup, but, unfortunately, the majority of people don't)
2. Site gives bot a four digit code (Like it already does)
3. User sends the bot the code
4. Bot sends user an address & an amount
5. User sends money to address with amount or more within thirty minutes (If it takes longer, re-do price check to make sure they're not trying to play the price using the volatility of BTC)
6. Bot confirms the item the user paid for is still valid, if it's NOT, check the user selling the product to see if he's selling any more of the same itemID for the same price (As many users sell 10 copies of the same thing at the same price), if he is, just switch to that item behind the scenes
7. If the user isn't selling any other copies, check the entire site, it really doesn't matter at this point who it comes from, as, we've verified the user the user originally wanted to buy from is no longer selling, and, we can't profit him in anyway, if someone else is selling, jump to their item.
8. If nobody else is selling, tell the user that the item is no longer for sale, and, they have three choices:-
8. A. Refund the money at a slight fee (0.0001 (As of bitcoin-qt version 0.8.6) or 0.00001 (As of bitcoin-qt version 0.9))
8. B. Refund the money at no fee, but, delayed refund (If they select this, pool up everyone who selected this and send one huge transaction along side a user who selected A, to reduce the fees on everyone)
8. C. Credit my account in the DB (I.E. their int64 ID), so, the next time they buy something they can use said funds

I understand this is a LOT of extra programming, and, honestly, I don't blame you if you reply with "No." (As, personally, I would if someone recommended this to me, hell, even if I thought of it), but, I can assure you, it'd boost sales as the amount of people that have contacted me, "Yeah, I'd like to buy X.Y.Z, but, I don't want to use dispenser.tf, as, it requires my password" is insane, nobody really seems to trust you, even though you're using OpenID.

Oh, P.S., can you also add the option for Yubikey authentication? It's a super simple API, takes literally a minute to implement (I've implemented it before), and, it's what I, and, many people I know, prefer over google authenticatior, as, it's a physical, non-computational, piece of hardware that can't have the private keys extracted from it (Unlike a jail broken/buggy phone), here's their github filled with examples:-
https://github.com/Yubico/

Here's the core data you need to know though, basically, you have five servers:-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoClient.java#L60-L64

You submit a request off to each one of them (I.E. five different requests):-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoValidationService.java#L79-L133

with the key that the user sent:-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoClient.java#L221-L235

And basically, there's ten ways the server can reply:-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoResponseStatus.java

OK:- If a server replies this, ignore all other servers and accept the key
BAD_OTP:- If a server replies this, ignore all other servers and decline the key
REPLAYED_OPT:- If a server replies this, ignore that server and keep listening to the other servers (This means that another server has received the request before it)
REPLAYED_REQUEST:- If a server replies this, ignore all other server and decline the key

The rest of them are basically back-end errors that you rarely get, catch them and report them to the user, but, other than that, there's not much you can fix.

For reference on who supports Yubikey:-
1. MTGox (Though they're shutdown)
2. PayPal (Using a different method than this, but, they still do)
3. Blockchain.info
4. Lastpass

Etc..., so, it's commonly used, and, it's a great little thing:-
https://www.yubico.com/products/yubikey-hardware/yubikey/

Joto

March 17, 2014, 3:53 p.m. (Last edited by Joto on March 17, 2014, 3:56 p.m.)

I honestly don't see why it can't, if user A wants to sell their product at one site's rate because they trust their community more than they trust another's, I feel that should be their judgement.

As for selling (And reducing the price of our goods), this is actually inverted, Bitstamp has a higher value per bitcoin, which means the value per USD is actually less (Imagine BTC was $1 per, and, I was selling something for $5, $5/1 = 5BTC, if it was $100 per, however, $5/100 = 0.05BTC.), so, users on bitstamp will actually have to increase their prices to match BTC-E's rate, even then, that's not very accurate, as, BTC-E isn't always X much higher than bitstamp.

Oh, on another note, can I ask what actually triggers the deposit? I've made two deposits so far, one got into my account after about twenty minutes and one confirmation, the other took about two hours and eight confirmations, any insight as to why? It currently seems to me like you're doing something incorrect in the backend to have such fluctuations on time, and, will drive away new customers. Imagine someone who isn't into trading, and, just wishes to buy a single game from someone on here and that's that, they'll deposit their money (Which, I still think drives people away, the whole 'deposit then trade', but, I understand why you did it, reserving items for people while BTC confirms = bad idea), have to wait an unknown insanely long time (I recommend either one confirmation, or, two (Two protects against orphaned blocks about 99.999999% of the time), to trade with a bot, to then have some left over money in their account their account they have to pay a withdraw fee (I understand you're not applying that fee to them).

Another idea would be something like:-
1. User selects what game they want (While logged out of the service, this all assumes they don't want to "Sign in through steam", as, lots of people assume this as phishing, as a developer myself, I do realize this is just an OpenID setup, but, unfortunately, the majority of people don't)
2. Site gives bot a four digit code (Like it already does)
3. User sends the bot the code
4. Bot sends user an address & an amount
5. User sends money to address with amount or more within thirty minutes (If it takes longer, re-do price check to make sure they're not trying to play the price using the volatility of BTC)
6. Bot confirms the item the user paid for is still valid, if it's NOT, check the user selling the product to see if he's selling any more of the same itemID for the same price (As many users sell 10 copies of the same thing at the same price), if he is, just switch to that item behind the scenes
7. If the user isn't selling any other copies, check the entire site, it really doesn't matter at this point who it comes from, as, we've verified the user the user originally wanted to buy from is no longer selling, and, we can't profit him in anyway, if someone else is selling, jump to their item.
8. If nobody else is selling, tell the user that the item is no longer for sale, and, they have three choices:-
8. A. Refund the money at a slight fee (0.0001 (As of bitcoin-qt version 0.8.6) or 0.00001 (As of bitcoin-qt version 0.9)
8. B. Refund the money at no fee, but, delayed refund (If they select this, pool up everyone who selected this and send one huge transaction along side a user who selected A, to reduce the fees on everyone)
8. C. Credit my account in the DB (I.E. their int64 ID), so, the next time they buy something they can use said funds

I understand this is a LOT of extra programming, and, honestly, I don't blame you if you reply with "No." (As, personally, I would if someone recommended this to me, hell, even if I thought of it), but, I can assure you, it'd boost sales as the amount of people that have contacted me, "Yeah, I'd like to buy X.Y.Z, but, I don't want to use dispenser.tf, as, it requires my password" is insane, nobody really seems to trust you, even though you're using OpenID.

Oh, P.S., can you also add the option for Yubikey authentication? It's a super simple API, takes literally a minute to implement (I've implemented it before), and, it's what I, and, many people I know, prefer over google authenticatior, as, it's a physical, non-computational, piece of hardware that can't have the private keys extracted from it (Unlike a jail broken/buggy phone), here's their github filled with examples:-
https://github.com/Yubico/

Here's the core data you need to know though, basically, you have five servers:-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoClient.java#L60-L64

You submit a request off to each one of them (I.E. five different requests):-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoValidationService.java#L79-L133

with the key that the user sent:-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoClient.java#L221-L235

And basically, there's ten ways the server can reply:-
https://github.com/Yubico/yubico-java-client/blob/master/v2client/src/main/java/com/yubico/client/v2/YubicoResponseStatus.java

OK:- If a server replies this, ignore all other servers and accept the key
BAD_OTP:- If a server replies this, ignore all other servers and decline the key
REPLAYED_OPT:- If a server replies this, ignore that server and keep listening to the other servers (This means that another server has received the request before it)
REPLAYED_REQUEST:- If a server replies this, ignore all other server and decline the key

The rest of them are basically back-end errors that you rarely get, catch them and report them to the user, but, other than that, there's not much you can fix.

For reference on who supports Yubikey:-
1. MTGox (Though they're shutdown)
2. PayPal (Using a different method than this, but, they still do)
3. Blockchain.info
4. Lastpass

Etc..., so, it's commonly used, and, it's a great little thing:-
https://www.yubico.com/products/yubikey-hardware/yubikey/

If using Bitstamp's price is not a good idea using BTC-E's won't be good either. We will go with the BitcoinAverage's price. And the reason why there won't be 'custom' BTC price on Dispenser.tf is we want to maintain 'simplicity'. Think from the user's perspective: how are they going to compare price when both the price of the item and the price of BTC are different across every shops.

As for why we must first deposit and then spend. It is mainly because, as you have already put it, getting blockchain confirmation could be slow and putting someone's item on hold while waiting for fund won't be a good idea. People can troll buying every single thing on the site but not actually sending any coins. Plus, we cannot really have a working system for users to send 2-10 USD worth of Bitcoin each time to buy a single item. Such transaction cannot afford the fee and would be very low priority on the blockchain (at the end we will put an item on hold for a even longer time).

On yubikey, the reason why we do not choose it is simple: It's not free! Not many people would have already own one. Google Authenticator is not great but is already enough for a site of our scale. We are not holding 850k BTC so yubikey is going to be overkill.