 Show Posts
|
|
Pages: [1] 2 »
|
I'm getting an html error page from Incapsula returned on bitstamp private api calls.
At first it was sporadic, now it's every time. Getting it on multiple ip's and multiple bitstamp accounts.
The incapsula tech said it had to do with a security rule implemented by bitstamp.
Anyone else getting this?
Yes, I am getting it as well. Still getting this regularly from bitstamp. I've opened a ticket which has been "forwarded to their system administrator" but haven't heard back yet. It's been days getting this error. Anyone home bitstamp? I'm trying the workaround mentioned here: https://bitcointalk.org/index.php?topic=351714Been running with the captcha cookies since last night, seems to be working so far but I can't be sure yet. The bug didn't recur predictably. Thanks, I will look into implementing that workaround. It would be great to hear from Bitstamp on this matter. Looks like a number of users have been affected recently: http://www.reddit.com/r/Bitcoin/comments/22zplb/bitstamp_api_incapsula_incidents/That fix isn't helping me at this point. I'm getting other API errors as well: https://bitcointalk.org/index.php?topic=570248.msg6236126 |
|
|
|
|
Same. When they aren't failing due to the incapsula page, the POST /api/xxx calls are getting a 302 redirect to GET /api/xxx. And of course failing.
|
|
|
|
I'm getting an html error page from Incapsula returned on bitstamp private api calls.
At first it was sporadic, now it's every time. Getting it on multiple ip's and multiple bitstamp accounts.
The incapsula tech said it had to do with a security rule implemented by bitstamp.
Anyone else getting this?
Yes, I am getting it as well. Still getting this regularly from bitstamp. I've opened a ticket which has been "forwarded to their system administrator" but haven't heard back yet. It's been days getting this error. Anyone home bitstamp? I'm trying the workaround mentioned here: https://bitcointalk.org/index.php?topic=351714Been running with the captcha cookies since last night, seems to be working so far but I can't be sure yet. The bug didn't recur predictably. |
|
|
|
|
I'm getting an html error page from Incapsula returned on bitstamp private api calls.
At first it was sporadic, now it's every time. Getting it on multiple ip's and multiple bitstamp accounts.
The incapsula tech said it had to do with a security rule implemented by bitstamp.
Anyone else getting this?
|
|
|
|
There isn't a spec for the alt coins as far as I'm aware. It'd be nice if there was.
TBH, I was hoping that my version bytes would become the standard. Hypothetically, if my implementation were actually used by alt-coiners then when drafting the spec it'd be more of an issue that the spec has to deal with (that people have already adopted a standard to use). Unfortunately, there's just no BIP-style development for any of the other coins, so I was forced to improvise if I wanted to support altcoins.
I was indeed going with XXpv/XXub for the public/private keypair prefixes. For testnet, I was a little less concerned about consistency but it seems you have gotten the general gist of things.
The code isn't set in stone. If you guys want the version bytes changed, let me know:)
I like the mainnet convention you're using. It's probably the most human-readable to be done in 4 characters. Would you consider changing the testnet prefix to XXtv, XXtb for private and public extended keys, respectively? I just want to enable my users to send and withdraw bitcoin. I'm trying to see if the approach suggested by just_someguy at https://bitcointalk.org/index.php?topic=22368.msg5058875#msg5058875 is the way to go. I've already spent 2 months to see if I can integrate Bitcoin to my web app. Do I need to understand cryptography, Depth, Parent Fingerprint, Child Index, Chain Code, Derivation Path, Derived Private Key, Private Key (WIF), Derived Public Key, Public Key (Hex), XXpv/XXub, base58_decode, magic bytes, encode, DOGE, Ltpv, Ltub, dgpv, dgub, etc. in order to do so? BIP32 is likely not the relevant standard if you want users to send and withdraw bitcoin. Also that post is from 2011 and the approach may no longer be best. |
|
|
|
|
Sarchar, the "version" values your BIP32 implementation uses for DOGE/DOGE-testnet and LTC/LTC-testnet, are these in some specification somewhere or is this your own? I'm implementing BIP32 for some alts and I'm curious what version values I ought to use.
I see in Base58 yours result in: Ltpv, Ltub, dgpv, dgub prepended to the extended keys. Ok so I get the convention you're using -- first two characters denote coin, ub/pv denote public/private. Is this a standard defined or discussed somewhere? The testnet version strings are problematic since yours are: ttpv, ttub, tgpv, tgub. This leaves only one character to denote the coin and in these cases already it's awfully ambiguous.
For altcoins something like XXmP/XXmp to denote mainnet public/private keys (where XX is the coin code) and XXtP/XXtp to denote testnet public/private keys would at least leave two characters to denote the coin.
DGmP/DGmp, DGtP/DGtp, LTmP/LTmp, LTtP/LTtp?
What are your thoughts?
|
|
|
|
Huh? You want me to prove that selling at a random time isn't better than what the bot does? That doesn't even remotely make sense  Done arguing, the math to me is pretty easy. And since I'm up a few hundred bucks over the last few days, I'm good. No, no, that part was a supposition, what I want you to prove is your statement that the BOT actually wields profit like you said. So, yeah, just post an example for MtGox that works in all time frame and I'll send you 1BTC. Pretty simple. Here's one that yields more BTC over 2 years (the max time frame). Buy in was at 2.515 dollars each, so 100/2.515 = 39.76 BTC for $100. Holding that 39.76 BTC for 2 years, then selling for $800 yields $31809. The bot manages $34287 in the same time, which also obviously is more in BTC (42.85 > 39.76). QED. Feel free to send my BTC to the address in my sig.  Feel free to read my question that was quite correctly worded. Post some settings that make BTC profit in ALL the backtest timeframes of Gox and you get your 1BTC.If you fiddle with the past numbers you can always find one case where it works, thats easy and... doesn't mean absolutely nothing. Is this offer open to everyone?  My settings yield a real BTC increase on every time frame on BTC-e, my preferred exchange. 2x BTC increase after 1 year. I hear a lot of confusion in his thread about how EMA trading works. This may not be a strategy for most newbies... With half-automated trading (I manually exit the short position) I'm up 20% in BTC the past two weeks. Again, YMMV  |
|
|
|
|
The discussions of profiting USD vs BTC are missing the point.
The real question is, does the EMA strategy beat buy-and-hold (i.e., will I have more or less converted BTC after using the bot)? The answer seems to be it depends on the conditions of the market.
During this recent insane rally, I don't see any EMA beating buy-and-hold. Another algorithmic strategy I'm using similarly performed worse than buy-and-hold in this period. I have had success trading half-manually with this bot entering the short position and then manually buying back BTC when I have some gains and I see a trend reversal. EMA has a lag in tracking the trend reversal and the market is moving very fast.
I've been using the bot with close supervision for about 2 weeks and I'm up about 8% in BTC. The largest gain was made by manually buying back during the flash crash two days ago. YMMV.
|
|
|
|
|
Hi I'm a newish butter-bot user. I've read in this thread advice against using any trade frequency below 30 minutes, but I'm using a 15 minute strategy that performs very well in backtesting. Is there any reason that this is a bad idea, despite the success in backtesting (over all intervals)?
|
|
|
|
|
Aha. Thank you I hadn't seen that.
Bug: in 1.8 the Hide Used Addresses option in lite mode does not hide addresses used once, only addresses used > 2 times.
|
|
|
|
Title pretty much sums it up. I have a jillion (that's 10^shit ton) receive addresses used and it's a UX frustration to scroll scroll scroll down to the bottom to pull out the next unused address each time I do a transaction. Either being able to reverse sort the receiving addresses OR being able to hide used receiving addresses would solve this. Just a suggestion. (btw electrum rules  ) |
|
|
|
Doesn't criterion 4, "Seller or redeemer of traveler's checks, money orders or stored value", pretty much fit the bill? Our responses in this thread will be limited until we get some resolution however it is important to understand state law and federal law don't necessarily have the same definitions even for terms with the same "name". Generally speaking the law will define a term and it has that meaning and only that meaning in the scope of that definition. As we indicated in the response at the federal level however FinCEN has provided guidance that Bitcoins are not stored value and virtual currency does not fall under the definition of "currency dealer or exchanger". FinCEN has changed the definition to "stored value" to be more inclusive of other prepaid products by using the term "prepaid access" however at the federal level "stored value" and "prepaid access" can be considered synonymous. http://fincen.gov/statutes_regs/guidance/html/FIN-2013-G001.htmlProviders and Sellers of Prepaid Access
A person's acceptance and/or transmission of convertible virtual currency cannot be characterized as providing or selling prepaid access because prepaid access is limited to real currencies. 18
Dealers in Foreign Exchange
A person must exchange the currency of two or more countries to be considered a dealer in foreign exchange.19 Virtual currency does not meet the criteria to be considered "currency" under the BSA, because it is not legal tender. Therefore, a person who accepts real currency in exchange for virtual currency, or vice versa, is not a dealer in foreign exchange under FinCEN's regulations.
Ok. Fair argument. |
|
|
|
The company has been given thirty days to provide written explanation on why our activity is exempt from licensing under current law. The commission has formally stated that unless exempt from licensing we must stop further activity until such time as we apply for and obtain a Money Transmitter license.
I see that Tangible Cryptography's MSB registration (#31000023734880), dated March 23, 2013, lists MSB Activities as "Mone transmitter". - http://www.fincen.gov/financial_institutions/msb/msbstateselector.htmlThe types of activities to choose from include: Money Services Business - The term "money services business" includes any person doing business, whether or not on a regular basis or as an organized business concern, in one or more of the following capacities:
(1) Currency dealer or exchanger.
(2) Check casher.
(3) Issuer of traveler's checks, money orders or stored value.
(4) Seller or redeemer of traveler's checks, money orders or stored value.
(5) Money transmitter.
(6) U.S. Postal Service.
- http://www.fincen.gov/whatsnew/html/LaunchNewMSBRegistrationSite.htmlIf Tangible Cryptography were to have wanted to choose something other than Money transmitter, there's nothing else that really applies. And money transmitter isn't really correct either. Bitcoins simply is a round peg that doesn't fit in any of the regulator's square holes. Doesn't criterion 4, " Seller or redeemer of traveler's checks, money orders or stored value", pretty much fit the bill? |
|
|
|
S.S. Failboat Go!!!
Im sorry, I love the idea, But its not going to work in This manner....
In the wallet? Good idea.
Solar recharge panel? <-What the fuck is that doing there for an in wallet/pocket device, Green energy recharge? I'd rather buy a connectable solar panel!
Initial cost is going to be nuts. like, $~1,300 per unit.
Daaaaaaayumm
Even still to this day we dont have good meshnets, We keep trying!
Bitinstant reviewed some prototypes. The company says $10-$25 per unit. Seems too good to be true. I guess we'll see in January 2013 (release date). |
|
|
|
|
Well shipping info is needed. What else do you mean?
|
|
|
|
I get the following error in windows: C:\Electrum-1.3>python electrum
File "electrum", line 204
except SystemExit, e:
^
SyntaxError: invalid syntax Anyone? you are probably using python3. try with python2. Ok not sure if I'm doing something wrong but I did get it to work. I needed to use python2 like you mentioned. But I also needed to download ecdsa, slowaes and setuptools as dependencies. Looks good! On a different note, I'm not sure if this has been covered elsewhere, but Electrum 1.01 (which I was using this morning before I saw the new release) was not listing new transactions. I had a few transactions last night that didn't show up in 1.01 (all had 80+ confirmations) until I changed the server to ecdsa.org (all the other servers allowed synchronization but didn't display the latest transactions). Same thing in Electrum for Android. The transactions that occurred last night are not showing up, even though it says it's synchronized. I'd try ecdsa.org to see if that fixes it too but it doesn't seem to want to let me use that server. Edit: Switched to ecdsa.org on e4a and now everything is good. |
|
|
|
I get the following error in windows: C:\Electrum-1.3>python electrum
File "electrum", line 204
except SystemExit, e:
^
SyntaxError: invalid syntax Anyone? |
|
|
|
More commerce! One of the benefits of bitcoins is that it can eliminate fraud in e-commerce. That means online stores don't have to charge a 1-2% markup to cover fraud losses. The savings can be passed on to the customer. Not to mention it will facilitate international commerce, as the rate of fraud from international sales is 2 to 3 times higher than domestic. Imagine if Amazon.com said all prices in BTC will be 2% lower than USD? Think that would help bitcoin take off? Once there's a strong enough economic ecosystem around bitcoin, the currency exchange losses can be avoided too. There will be no need to exchange BTC for USD. All in all, speculation and investment vehicles may be the most popular avenues for bitcoin on this forum, but they'll be more and more a drop in the bucket as the market penetration increases. |
|
|
|
So if the purchaser doesn't have a Gox account, they will simply pay in BTC and then, assuming the autosell option is on, they will be sold for dollars after 6 confirms. Do you know if the vendor already has enough BTC as a buffer in his Gox account, can the autosell happen instantly? Example...
I have a Gox account with 20 BTC and a non-Gox buyer purchases a product for 10 BTC. 10 of my 20 BTC are sold and the 10 from the purchaser get credited to my account, meaning I have 10 BTC + 10 BTC with no confirms. Is there any way to make this work if it doesn't work that way already?
That's a good question. I don't use the autosell feature so I'm not sure. Let me know if you get an answer! One of the reasons I haven't used the autosell is because I assumed that it'd have to wait for the 6 confirmations, so if there was a fire-sale due to falling valuation I could get stuck losing on each transaction. |
|
|
|
I'm having trouble setting this up.
Has anyone used this before?
I'm using a host where I can automatically add the carts to my database/server I don't have to FTP upload them. I cant get these plugins to work, even when I upload using an FTP. I did the mtgox one, and I need API keys, or something.
If you got the MtGox plugin successfully installed in Magento (you should see a "Bitcoin" option under System -> Configuration -> Payment Methods) then you'll need to enter your MtGox info there. You can get an API key by logging into MtGox and going to Security Center -> Advanced API Key Creation. It'll need Deposit and Merchant permissions. The documentation was a little sparse and I had to code up my own currency import modules. But all's working. Do you know how one could use Magento along with the Mt Gox merchange API system, where users can pay without being members of Mt Gox? The Mt Gox Magento plugin allows customers to pay without having Mt Gox accounts. Mt Gox simply handles the incoming bitcoins. However, if the customer does have a Mt Gox account then the bitcoins are credited to the vendor immediately, without having to wait for 6 blockchain confirmations. |
|
|
|
|
