How much GH is one ASICMINER share?
(1/400000)*current hash rate in GH |
|
|
|
Burnside, Would it be possible to make the API always return an array for the order list in the get_portfolio oauth response? If there's one order, it's not an array, but if there's more than one order it IS an array. This inconsistency makes me have to do some hacky work-arounds in parsing the JSON since it's not consistent. Thanks  |
|
|
|
We saw you mention this earlier in the thread already...  |
|
|
|
Here's the code I mentioned earlier on IRC: http://dpaste.com/hold/1197404/Just change the credentials at the top. This requires python 2.7 with a couple of dependencies (you'll get errors if they aren't there, just use pip to install them) This takes the consumer key and consumer secret and generates the other tokens. It will ask you to visit in the browser and grab the verification string, like you have been doing, then paste it back to the app to generate your oauth client secret. You should save those, since this authorization is only needed once and you can skip the verification steps in the future if you have these stored. I also put in an example of using the credentials to call the get_portfolio method to return your info. I'm actually having the exact opposite problem. It seems like the api is treating ALL callback_url as if they are oob. I place an url into the callback_url parameter, but it never hits my callback url. The python code is working fine for me, so I assume it must be an issue with the oauth package i was using ( http://godoc.org/github.com/garyburd/go-oauth/oauth) and not with BTC-TC. Whew. One less thing to worry about.  Thank you for the update! OK so I lied  Looks like the problem is that the RFC states that the server should accept an HTTP POST for the token request, however it only seems to work when the token is requested using a GET. Just to help clarify, the code gets a set of temporary credentials, then it uses those plus the verification string to request an access token for future use. I was trying to use the packages built in request-token method, which uses a POST per the standard. In order to get it to work I had to manually create the token request and send it using a GET. Hope that makes sense |
|
|
|
Really? I haven't had any luck at all. I can fetch the URL to approve application access to my account, and when I approve it the page reloads again, this time with the verification string in the URL. When I take that string and try to use it in my program, the website API says that it's invalid. I'll see if I can find some other oauth code to work with and test it out, the stuff I'm using has worked fine on other sites but maybe something is off with the way it works with btct.co.
Here's the code I mentioned earlier on IRC: http://dpaste.com/hold/1197404/Just change the credentials at the top. This requires python 2.7 with a couple of dependencies (you'll get errors if they aren't there, just use pip to install them) This takes the consumer key and consumer secret and generates the other tokens. It will ask you to visit in the browser and grab the verification string, like you have been doing, then paste it back to the app to generate your oauth client secret. You should save those, since this authorization is only needed once and you can skip the verification steps in the future if you have these stored. I also put in an example of using the credentials to call the get_portfolio method to return your info. I'm actually having the exact opposite problem. It seems like the api is treating ALL callback_url as if they are oob. I place an url into the callback_url parameter, but it never hits my callback url. The python code is working fine for me, so I assume it must be an issue with the oauth package i was using ( http://godoc.org/github.com/garyburd/go-oauth/oauth) and not with BTC-TC. |
|
|
|
Burnside, would it be possible to have the oauth verifier not expire when the page for a specific token is called again? I can browse to https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc with my browser, and approve it, but then it reloads the same page with the oauth verifier token appended to the URL and when I use that verifier the API tells me it's already invalid  I hate to say it but that confused me pretty good. Something tells me though that if it doesn't invalidate it the first time around, it may be open to replay attacks? I don't think so. Each time you visit the URL, for example https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc and approve the access request, it returns the verification code in the form of a URL like https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc&oauth_verifier=<verifiestringhere> Each time I grant access, a NEW verifier string is generated, and the old one is invalidated. The problem is that once I approve access, the page redirects to https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc&oauth_verifier=<verifier here> and it prompts for access again. If I just ignore the request and paste the verifier string from the URL in to my program, it comes back with this error: OAuth server status 401, oauth_problem=verifier_invalid Hope that helps clears things up. What I think is happening is whenever the page is called, the program invalidates any credentials used for the token in the request URL, so when the page refreshes, BAM, the verifier string in the URL is already invalid. When you grant access, it should redirect back to your callback page, correct? Is this the oob situation we were discussing earlier? No callback causes it to call itself again? With the DDoS issues lately I haven't had any time to fix the oob functionality. It's high on the list though. Correct. When I pass 'oob' for the callback, the webpage reloads itself as the callback URL. When you grant access, it should redirect back to your callback page, correct? Is this the oob situation we were discussing earlier? No callback causes it to call itself again? With the DDoS issues lately I haven't had any time to fix the oob functionality. It's high on the list though.
I think oob is working okay. At least, I've been able to register and retrieve working credentials with it. Really? I haven't had any luck at all. I can fetch the URL to approve application access to my account, and when I approve it the page reloads again, this time with the verification string in the URL. When I take that string and try to use it in my program, the website API says that it's invalid. I'll see if I can find some other oauth code to work with and test it out, the stuff I'm using has worked fine on other sites but maybe something is off with the way it works with btct.co. |
|
|
|
Burnside, would it be possible to have the oauth verifier not expire when the page for a specific token is called again? I can browse to https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc with my browser, and approve it, but then it reloads the same page with the oauth verifier token appended to the URL and when I use that verifier the API tells me it's already invalid I hate to say it but that confused me pretty good. Something tells me though that if it doesn't invalidate it the first time around, it may be open to replay attacks? I don't think so. Each time you visit the URL, for example https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc and approve the access request, it returns the verification code in the form of a URL like https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc&oauth_verifier=<verifiestringhere> Each time I grant access, a NEW verifier string is generated, and the old one is invalidated. The problem is that once I approve access, the page redirects to https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc&oauth_verifier=<verifier here> and it prompts for access again. If I just ignore the request and paste the verifier string from the URL in to my program, it comes back with this error: OAuth server status 401, oauth_problem=verifier_invalid Hope that helps clears things up. What I think is happening is whenever the page is called, the program invalidates any credentials used for the token in the request URL, so when the page refreshes, BAM, the verifier string in the URL is already invalid. |
|
|
|
Burnside, would it be possible to have the oauth verifier not expire when the page for a specific token is called again? I can browse to https://btct.co/authorize?oauth_token=c6da005d45642ba73589e37444304412020f36bc with my browser, and approve it, but then it reloads the same page with the oauth verifier token appended to the URL and when I use that verifier the API tells me it's already invalid |
|
|
|
No Ziggap? |
|
|
|
MPex -> Lost most of its trading volume (stocks) -> going down
Still more trade than the sum of all others, for one. The fact that it won't list bullshit "assets" (such as the Asciminer passthroughs) isn't really a valid objection. ...blah blah blah... If on the other hand you have a legitimate business you have no chance making it outside of MPEx. This is a point of fact, not a point of argument: there have been bet sites coming and going for about two years. Once one listed on MPEx that was the end of that market, BitBet now dominates it. Same with dice games, same with everything else: kids can play around and pretend they're doing things until the adult exchange lists some adults... Sounds like I should get myself listed on MPEx so I can live forever and dominate over everyone else that didn't list themselves there. I hope you could hear me all the way up there on your high horse. If not I'll be glad to get a step-ladder and/or a megaphone. |
|
|
|
So is this comparison thread still going on or...?
I hope not  |
|
|
|
I'm working with the oauth API right now, and it seems it doesn't support 'oob' for situations when you don't have a callback url available. If you could implement this, I'd be really grateful. All it needs to do is if there is no callback url, or the callback url is 'oob', just display a page with the token and verification information in it so the user can copy and paste it where they need it to go.
After doing more testing, it appears that with "oob" passed as the callback, the page uses itself as the callback URL with the verifier string in the URL as well. This would be fine except I think as soon as the page is loaded with the same token, it invalidates the old verifier, so I can't just copy the verifier from the URL and use it because it's already invalid If you could make it show a new page that just displays the verifier string when the callback URL is "oob" that would be most excellent. I'll definitely spend some time on this soon as I can. I've been looking a bit at some other implementations to see what the "right way" to implement it is. Awesome, thank you very much, oauth is such a PITA! I was basing my statements on how Twitter does it. I made an app at https://dev.twitter.com and it generates the consumer secret and key. Then of course the user (with my sample code) has to hit up the URL http://api.twitter.com/oauth/authorize?oauth_token=<token> and once the user OK's the app, it takes you to a page with just the verification string that is normally returned through the callback URL. Just wanted to post that as a sample of the work flow for something that is probably doing it right. |
|
|
|
I'm working with the oauth API right now, and it seems it doesn't support 'oob' for situations when you don't have a callback url available. If you could implement this, I'd be really grateful. All it needs to do is if there is no callback url, or the callback url is 'oob', just display a page with the token and verification information in it so the user can copy and paste it where they need it to go.
After doing more testing, it appears that with "oob" passed as the callback, the page uses itself as the callback URL with the verifier string in the URL as well. This would be fine except I think as soon as the page is loaded with the same token, it invalidates the old verifier, so I can't just copy the verifier from the URL and use it because it's already invalid If you could make it show a new page that just displays the verifier string when the callback URL is "oob" that would be most excellent. |
|
|
|
It is normal for pts to have a delay in paying dividends. If you know issuers are trusted, you have nothing to worry about.
Yes, it can take a day or two sometimes. |
|
|
|
|
I'm working with the oauth API right now, and it seems it doesn't support 'oob' for situations when you don't have a callback url available. If you could implement this, I'd be really grateful. All it needs to do is if there is no callback url, or the callback url is 'oob', just display a page with the token and verification information in it so the user can copy and paste it where they need it to go.
|
|
|
|
Well then, idiot: 1) For the July 1st BFL bet, what exactly is the advertised performance?
Exactly what it was at the time the bet was introduced. Which is what? Post the specifications or a link to them so we can see what the decision will be based on. |
|
|
|
|
Add me to the list that think power is not performance and that old forum posts for a canceled product probably aren't the greatest source for the currently advertised specifications.
|
|
|
|
I want to play, how do I make an account? |
|
|
|
Looking forward to this so I can take my G.ASICMINER-PT dividends and buy some of your split shares until I have enough for a full share. |
|
|
|
That would be nice, especially with a line to show average ticker price as well. |
|
|
|
|
Show Posts
