What do you think about p2p rt datafeed solution? Is it possible or not?
Right now I'm working through fixing the first obstacle I found in trying to produce shareable data (such as importable txt files or other people's SCID files) - putting all times in UTC/GMT. The bridge has a design problem, it converts all times to local times, which is wrong according to SierraChart docs, and it even messes up the data during the switch to daylight savings time or moving the computer between timezones, so basically all of you have somewhat erroneous history. The data should be UTC, and import/export should also be in UTC. Fixing this will mean a new program version, and users must wipe all SCIDs and old history before using it. Since API is so slow, I'll probably include a feature to get the full csv history direct-download daily-generated files when appropriate and/or might throw up my own importable files you can use before starting bridge. Peer to peer is not an awesome idea, bad peers could feed you bogus info or exploit your open port. |
|
|
|
Man none of this stuff is working for me, I installed python33 and it keeps giving me errors. Can someone ELI5 how to pull data from btc-e. Willing to tip for your efforts.
I didn't link to python 3.3 above, so "none of this stuff is working" would not be stuff I posted. Most python programming is still done on 2.7, because libraries for 3+ are limited. |
|
|
|
For some reason, this "fix" fails to download anything past the last week or so of trade data. Is there any way to download data farther back? My mtgoxUSD.scid file is missing historical trade data from April 19, 20, 21, and 22  Usage: sierrachartfeed.py [options]
...
-l HISTORY, --history=HISTORY
Number of days of history to retrieve (**default=7**). Update 017: refine rate adaptation, enforce max history when catching up scid, give a user-agent Because of how poor the API has performed, with about 10% gateway errors and noticeable random long requests (and the fact that we are already abusing the "one API request per 15 minute"), I put in enforcement of the number of days downloaded when catching up an old SCID also, so that if you haven't used the program for six months or if your SCID ends with 2011 data from previous fail versions, it doesn't go crazy and hammer the server, unless you specifically tell it to get more history at the command line. If you have already created an SCID with a gap, the program can't go back and fill it in, as data is expected chronologically. Besides the method two posts above to remove data after a gap (my version of Sierrachart doesn't have that exact option), from the edit menu you can also "export and edit to txt", cut lines off the end, and then "import and load". The file format is 54 bytes of header + 40 bytes per record, so you can also use a utility like GNU split to experimentally cut off extra new data from the tail of the SCID file if you have received bad data at the end, from the original version failing, or from not seeing my change. |
|
|
|
|
The first alert is "bought private keys". What? Some things like paper wallets or casascius coins have their value stored in a single private key, but you should not be "buying" them as standard practice - people should send payments to your wallet.
I will document the behavior of Bitcoin-qt, which is what you should get accustomed to using if you have more than a passing interest in Bitcoin.
If you want a payment to seem to be coming from one address, you will want to first import those private keys into your wallet, and then send the entire balance of your wallet to a new address of yours that you create in "receive coins". Then the next payment that you send will appear to come from that new address.
|
|
|
|
The age of the coins and the amount you are sending will determine whether you can send for free. Sending without the minimum fee when it is required will cause you headaches later, and the Bitcoin client won't let you do it.
First, recognize that a transaction is made of:
- inputs - the funding source(s), the individual payments you previously received, and
- outputs - the amount(s) you are sending to different addresses. Typically only one or two outputs, but you can send to many people in one transaction if you want.
The baseline calculation for "when it becomes free" is 1 BTC after one day. If the input of your transaction is a single 1 BTC payment you received over a day ago (144 confirmations), then Bitcoin-qt won't require a fee, even if you are only sending .1 BTC to someone else (the other .9 is also sent, but it's sent back to your wallet as another output). Likewise, if your balance is from a single 0.1 BTC, a transaction using that payment would be free to send after 10 days of confirmations.
The above examples are when your transaction is made of one input. Often a transaction will be made of many smaller previous payments to you, put together by Bitcoin in whatever way it calculates will minimize the change that needs to be sent back to you. Therefore, it can be harder to know if you will need a fee without actually attempting to send the transaction. No "warning, requires a fee" message? That means a fee was not required, and only your optional fee (if set above 0) will be included.
If any output of your transaction is less than 0.01 BTC, a minimum fee is required regardless, to keep people from cheaply spamming the blockchain by sending the same money over and over.
A transaction sending 0.4 BTC with 100 confirmations is not high enough priority to send with no fee.
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
((0.4 * 100,000,000) * 100) / 258 = 15,503,875
Transactions need to have a priority above 57,600,000 to avoid the enforced limit. I would recommend ANY payment include a fee even if it would qualify to be free, as "free transaction" space in blocks is limited, and profit-motivated miners have no incentive to include free transactions over those with fees.
|
|
|
|
|
"Barter transaction rules apply where BitCoins are used to purchase goods or services," Canada Revenue Agency spokesman Philippe Brideau said in an email."
...
"But as the CRA statement shows, governments are starting to pay attention."
So the reporter emailed for a comment, was pointed to existing 1995 rules, and concludes that governments are "paying attention"?
|
|
|
|
Joo got scooped: http://www.huffingtonpost.com/john-pavley/miner-mike-the-bitcoin-mi_b_3171118.html?utm_hp_ref=technology"Bitcoin fixes Blizzard's World of Warcraft gold mining?" Really? The emphasis of any article these days should not be on mining, except mentioning that it's completely pointless to mine unless you want to put thousands of dollars into capital and have a sound plan to obtain a solid ROI; that the currency is best obtained by and used for commerce. The mistake reporters make is to rehash what has already been written many times about Bitcoin filtered through their own noob misunderstandings. Every article about what shirt Miley Cyrus is wearing today doesn't have a background on who she is, where she came from, how many records she sold, along with interviews of the "weirdos" who are fans and editorializing from the writer about how she isn't a legitimate artist. You can't report on just what Bitcoin is, because it was news two years ago; if your beat is Bitcoin, go find some news. |
|
|
|
|
Just make every button ftp you his wallet?
|
|
|
|
There is a lot of irrelevant stuff in the log. This is what a block download looks like: Committing 446 changed transactions to coin database...
SetBestChain: new best=000000000000001271cfcf276630c89b8c5efb05b714d525cf49ebe2e6ba531b height=233478 work=1089949624432044523893 tx=16862064 date=2013-04-28 00:10:55
ProcessBlock: ACCEPTED
received block 000000000000010e64ac023847f26c317191da1e3beaafa4d3ac42623bcd856d
Committing 170 changed transactions to coin database...
SetBestChain: new best=000000000000010e64ac023847f26c317191da1e3beaafa4d3ac42623bcd856d height=233479 work=1089988169328081528408 tx=16862127 date=2013-04-28 00:12:22
ProcessBlock: ACCEPTED
received block 000000000000015bb9d9c0ba36dec83f2aa14692789e121a26c50759917a50c8
Committing 585 changed transactions to coin database...
SetBestChain: new best=000000000000015bb9d9c0ba36dec83f2aa14692789e121a26c50759917a50c8 height=233480 work=1090026714224118532923 tx=16862343 date=2013-04-28 00:21:36
ProcessBlock: ACCEPTED
received block 000000000000017ca936f9d8679a1860b88338c866aca212ae0d75db11d4f65b
Committing 356 changed transactions to coin database...
SetBestChain: new best=000000000000017ca936f9d8679a1860b88338c866aca212ae0d75db11d4f65b height=233481 work=1090065259120155537438 tx=16862538 date=2013-04-28 00:23:17
ProcessBlock: ACCEPTED
received block 000000000000006213c4d4c2c218c9b4088767600bc514ae3d5428823cc5f7ef
as long as you see continuing block downloads, everything is fine. The number of blocks remaining is obtained from a calculation of the most recent block number from multiple peers - if you don't have enough peers for consensus, or one is sending you bad data, then Bitcoin will use block 216116 as the best height in it's display calculations instead. |
|
|
|
Alright I got this scumbag!He replied back to my second email address. Any recommendations on what to do now?
Send him an email asking please for a refund, as you see that ASICs won't ship for a long time. But first go to spypig.com and get a tracking image you can put in the email you send so you can get the person's real IP address. Thanks for that, I got his IP, his location, the type of computer and browser he is using. He is in Wisconsin. So what should be the next step? Should I report him to the police or something? There are websites where you can see if the IP address is a Tor exit node - if it is, then the information is useless. You can at least use the information to more forcefully demand a refund. |
|
|
|
bitcoincharts is alive again. Every attempt I make to download the whole history, it often gets through a month or two but always ends up crapping out with a 502 error. These errors persist even with the rebirth of bitcoincharts. They seem completely random, with no relation to the amount of data or the amount of time since the last request. I can wait five seconds between requests that are 1/20 the size of maximum and they still randomly happen. Of course the bitcoincharts API overview does say "Don't query more often than once every 15 minutes!", but that would make getting any amount of history beyond a single request take forever. Therefore I have tried to make code that figures out what bitcoincharts wants and only gives up if it has way too many 502 errors. It slows down and requests less data upon errors to reduce hammering the server: Link to post with download: https://bitcointalk.org/index.php?topic=6019.msg1929339#msg1929339 |
|
|
|
Alright I got this scumbag!He replied back to my second email address. Any recommendations on what to do now?
Send him an email asking please for a refund, as you see that ASICs won't ship for a long time. But first go to spypig.com and get a tracking image you can put in the email you send so you can get the person's real IP address. |
|
|
|
|
I made it work with the latest drivers and cgminer, just answer the default questions, and you'll soon be on your way to making less than one "minimum transaction fee" in BTC per month.
|
|
|
|
I'm very confused as to why a senior member with nearly 300 posts is asking the most basic question possible?
"Empty vessels make always the loudest sound; the less virtue, the greater report. Deep rivers pass away in silence ; profound knowledge says little ; but what a murmur and bubbling, yea, sometimes what a roaring, do they make in the shallows ! The full vessel gives you a soft answer, but sound liquor. Samson slew a lion, but he made no words of it: the greatest talkers are the least doers. As when a rabbi, little learned, and less modest, usurped all the discourse at table; one much admiring him, asked his friend in private, whether he did not take such a man for a great scholar: to whom he plainly answered, For aught I know he may be learned, but I never heard learning make such a noise." |
|
|
|
So that you can see your original and only question is clearly answered, end of thread:Is anyone familiar with the 8800 GTS in regards to mining? Yes.
|
|
|
|
I would suggest that if you don't have the skill to read arbitrary code from the Internet and understand it, especially if the author is targeting Bitcoin users, that you do not run such code on your computer - it could as easily have obfuscated "upload wallet.dat to hacker" code. The code snippet you linked is for executing a trade on btc-e, you must do more than just click on it, it requires your api key and secret key be added to the code, and you must use command-line parameters to specify what currency and type of order you wish to execute. It says that on line four of the code. Original thread: https://bitcointalk.org/index.php?topic=97359.msg1075244#msg1075244All that is needed is to download and install Python. For Windows: http://www.python.org/ftp/python/2.7/python-2.7.msiThe code only requires standard libraries, but you may find other advanced code that require other common-but-not-included libraries, such as greenlet, twisted, zope, boost, etc. Here is some code which takes command line options; try saving this as example.py and running it from the command line. Master this first: import sys; print ' '.join(sys.argv) |
|
|
|
|
I've got one, it rips out a considerable 14MHash/s, which is enough to earn 1 BTC in approximately never.
|
|
|
|
anyone else seeing the error message about mysql server failure using deepceleron's exe?
if so, anyone got a clue when it'll be sorted?
if not, uh... help?
All of http://bitcoincharts.com is currently down (the source of Sierrachartfeed data), replaced only with "Our MySQL server started to fail this night. We're migrating to postgres now, but this will take some time." This is a first in two years. This may also create a gap in history if they don't have a separate grabber, so anybody else that has some alternate mtgox API logging, KEEP IT GOING so that bitcoincharts can resurrect any missing data! |
|
|
|
on SC data feed since the data is properly formatted and you can use tick charts for example the only problem is they dont have data since day 1
With the exe version I just uploaded, data should be tick-accurate, although you need to set chart display appropriately (apparently the SCID can't set appropriate defaults). Permanent fix for tick (adjust appropriately for other exchanges):Go into Menu -> Tools -> Chart Settings. Pick "Edit Global Symbol Settings". Choose Service "SC Historical Data", and press New. Then edit on the "General" Tab: -Symbol: mtgoxUSD -Price Display Format: .00001 -Tick Size: 0.0000100 -Currency Value Per Tick: 0.0000100 Now in Menu -> Tools -> Chart Settings, "Price Display Format" and "Tick Size" is auto set to ".00001" Temporary Volume Fix until next SierraChart Launch:Go into Menu -> Tools -> Chart Settings. Go to "Advanced Settings 2" tab and change "Volume/Open Int. Multiplier" to "0.01". Press Apply See volume:Menu -> Analysis -> Studies. select "Volume" and press "Add>>", and OK. Looks like:  Bar analysisGo into Menu -> Tools -> Chart Settings. Set Bar Period to "Number Of Ticks", "Range Of Ticks", set the number, and do whatever analysis you want. |
|
|
|
I wonder if there is any way to get Sierra Chart to display Level II data like: Orderbook and Sales For daytrading it is quite important to receive the most actual tick data possible. I was comparing the chart display on MTGOX USD to the chart @ http://bitcoin.clarkmoody.com/ and I had the impression it was lagging behind that website. I wonder which feed is more up2date: the one from bitcoincharts or the one SierraChart is feeding? I just logged trade times vs actual UTC time I received them on my computer (I have sub-1-second accuracy using NTP). Here are the results: rec date rec time timestamp delay
4/26/2013 13:49:21 13:49:18 3.6
4/26/2013 13:49:51 13:49:21 30.5
4/26/2013 13:49:51 13:49:24 27.6
4/26/2013 13:49:51 13:49:24 27.6
4/26/2013 13:49:51 13:49:29 22.6
4/26/2013 13:49:51 13:49:32 19.6
4/26/2013 13:49:51 13:49:35 16.6
4/26/2013 13:49:51 13:49:39 12.6
4/26/2013 13:49:51 13:49:42 9.6
4/26/2013 13:49:51 13:49:42 9.6
4/26/2013 13:49:51 13:49:45 6.6
4/26/2013 13:49:51 13:49:45 6.6
4/26/2013 13:50:21 13:50:02 19.7
4/26/2013 13:50:22 13:50:17 5.1
4/26/2013 13:50:22 13:50:18 4.1
4/26/2013 13:50:52 13:50:22 30.6
4/26/2013 13:50:52 13:50:22 30.6
4/26/2013 13:50:52 13:50:31 21.6
4/26/2013 13:50:52 13:50:33 19.6
4/26/2013 13:50:52 13:50:36 16.6
4/26/2013 13:50:52 13:50:39 13.6
4/26/2013 13:50:52 13:50:44 8.6
4/26/2013 13:50:52 13:50:48 4.6
4/26/2013 13:51:22 13:51:00 22.6
4/26/2013 13:51:22 13:51:03 19.9
4/26/2013 13:51:22 13:51:11 11.9
4/26/2013 13:51:52 13:51:24 28.7
4/26/2013 13:51:52 13:51:29 23.8
4/26/2013 13:51:52 13:51:31 21.8
4/26/2013 13:51:52 13:51:33 19.8
4/26/2013 13:51:52 13:51:36 16.8
4/26/2013 13:51:52 13:51:38 14.8
4/26/2013 13:51:52 13:51:41 11.8
4/26/2013 13:51:52 13:51:43 9.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:45 7.8
4/26/2013 13:51:52 13:51:47 6.0
4/26/2013 13:51:52 13:51:50 3.0
4/26/2013 13:52:24 13:51:52 32.0
4/26/2013 13:52:24 13:51:57 27.1
4/26/2013 13:52:24 13:51:57 27.1
4/26/2013 13:52:24 13:52:01 23.1
4/26/2013 13:52:24 13:52:02 22.1
4/26/2013 13:52:24 13:52:04 20.1
4/26/2013 13:52:24 13:52:08 16.1
4/26/2013 13:52:24 13:52:08 16.1
4/26/2013 13:52:24 13:52:11 13.1
4/26/2013 13:52:24 13:52:11 13.1
4/26/2013 13:52:24 13:52:13 11.1
4/26/2013 13:52:24 13:52:15 9.3
4/26/2013 13:52:24 13:52:17 7.3
4/26/2013 13:52:24 13:52:20 4.3
4/26/2013 13:52:24 13:52:22 2.3
4/26/2013 13:52:24 13:52:22 2.3
4/26/2013 13:52:24 13:52:23 1.3
4/26/2013 13:52:24 13:52:23 1.3
4/26/2013 13:52:54 13:52:24 30.3
4/26/2013 13:52:54 13:52:28 26.4
4/26/2013 13:52:54 13:52:28 26.4
4/26/2013 13:52:54 13:52:28 26.4
4/26/2013 13:52:54 13:52:28 26.4
4/26/2013 13:52:54 13:52:30 24.4
4/26/2013 13:52:54 13:52:34 20.4
4/26/2013 13:52:54 13:52:37 17.4
4/26/2013 13:52:54 13:52:43 11.4
4/26/2013 13:52:54 13:52:45 9.4
4/26/2013 13:52:54 13:52:46 8.4
4/26/2013 13:52:54 13:52:50 4.6
4/26/2013 13:52:54 13:52:52 2.6
4/26/2013 13:53:24 13:52:54 30.4
4/26/2013 13:53:24 13:52:56 28.8
4/26/2013 13:53:24 13:52:56 28.8
4/26/2013 13:53:24 13:52:58 26.8
4/26/2013 13:53:24 13:53:02 22.8
4/26/2013 13:53:55 13:53:31 24.1
4/26/2013 13:53:55 13:53:32 23.1
4/26/2013 13:53:55 13:53:32 23.1
4/26/2013 13:53:55 13:53:34 21.1
4/26/2013 13:53:55 13:53:36 19.1
4/26/2013 13:53:55 13:53:44 11.1
4/26/2013 13:53:55 13:53:46 9.1
4/26/2013 13:53:55 13:53:47 8.1
4/26/2013 13:53:55 13:53:48 7.1
4/26/2013 13:54:25 13:53:58 27.5
4/26/2013 13:54:25 13:54:09 16.8
4/26/2013 13:54:25 13:54:09 16.8
4/26/2013 13:54:25 13:54:09 16.8
4/26/2013 13:54:25 13:54:13 12.8
4/26/2013 13:54:25 13:54:21 4.8
4/26/2013 13:55:26 13:54:57 29.7
4/26/2013 13:55:26 13:55:00 26.7
4/26/2013 13:55:26 13:55:14 12.7
4/26/2013 13:55:26 13:55:18 8.7
4/26/2013 13:55:26 13:55:20 6.7
4/26/2013 13:55:26 13:55:23 3.7
4/26/2013 13:55:26 13:55:23 3.7
4/26/2013 13:55:55 13:55:38 17.9
4/26/2013 13:55:56 13:55:38 18.3
4/26/2013 13:55:56 13:55:38 18.3
4/26/2013 13:55:56 13:55:40 16.3
4/26/2013 13:55:56 13:55:40 16.3
4/26/2013 13:55:56 13:55:48 8.3
4/26/2013 13:55:56 13:55:48 8.3
4/26/2013 13:55:56 13:55:50 6.3
4/26/2013 13:55:56 13:55:52 4.3
The average delay time is 15 seconds. If you use clarkmoody, it gets its trades to your browser directly from mtgox websocket; you can compare it's console and see that the bitcoincharts data is pushed in approximately ~30 second chunks (which is adequate for charting 1-minute intervals, there is no trading in bridge-connected sierrachart). I might take a look at getting data from MtGox again, which is how SC is getting their feed (but how much do they delay?...). It was the original method, but was switched due to problems: Version 0.4 released, fixes non-working streaming from MtGox. It is now using socket interface to bitcoincharts instead of MtGox's socket.io.
Pros - sierrachart now supports live streaming of all bitcoin charts, not just MtGox.
Cons - there's currently implemented only polling between bitcoincharts and mtgox and chart updates are delayed 5 seconds in average. But tcatm is working on socket.io support on his side, so it will gets better soon.
Enjoy! :-)
|
|
|
|
|
Show Posts
