|
KeePass, already done, free.
|
|
|
|
|
The history stream API IP address has no IPv4 DNS right now, but for those with native IPv6 it has an AAAA address. It also has been half-returned to working status, there is five days of history (instead of all history available), with date ranges working the way it used to. This should allow you, if your backup/remove old SCIDs if you have been down a while, to run with --history=6 and see some perspective history.
I'm going on holiday for a bit, hopefully the IP and full history availability will be restored to the API.
|
|
|
|
|
It's resolved by that exchange's hard drive crashing and losing all account information... Hopefully they will start something up again, it was a nice exchange for BTC->namecoin->BTC.
Confirmations required depends on the service, I know GOX at one time went from 6 confirmations to hours and hours before showing a balance, with no annoucement.
|
|
|
|
|
The ISP of bitcoincharts was hit with a DDOS, and it blackholed many sites to mediate the problem. The site is back up.
I have opened a dialog with the site admin, hopefully this will result in an API that will continue to work for applications such as sierrachartfeed.
|
|
|
|
The linked post is from 2011, and is not very good. It includes complicated steps that are more likely to result in you losing bitcoins. There are two strong ways to store your bitcoins:- On a securely generated offline paper wallet (for savings)
- On a dedicated secure computer only used for Bitcoin running Bitcoin-Qt
Notice I did not say virtual machine, web wallet, copy your wallet all over the place, etc. Here is how I would configure this secure dedicated bitcoin computer: Get a desktop PC, it doesn't have to be anything special. Use a hash-verified ISO Linux distribution CD or DVD image (kubuntu 13.10 32 bit is a good choice). When installing, wipe and create a manageable partition, such as 100GB, on that computer and install the OS. Choose the option to encrypt your whole hard drive, and create a user name, both using a strong and long password you will not forget. Now, get the official binary of Bitcoin-Qt, download it from the http://sourceforge.net/projects/bitcoin/files/Bitcoin/ official repository. Verify the expected hash or signature of this file independently on a normal computer or with communication with others vs your copy. I'll help you out here: 84543f10de5e82ce6e88dd5a501db37c6327edf79a2a04f29199c24843e71f63 *bitcoin-0.8.5-linux.tar.gz
Now set up your wallet securely. First create the ~\.bitcoin directory yourself, and put a bitcoin.conf file there, with these options to lock it down and make a more secure wallet backup: server=0
keypool=1000
paytxfee=0.0001 Run bitcoin, and encrypt your wallet with a different password than the above you also won't forget. Let it catch up on the blockchain (days). Now, we must backup that wallet securely. We are talking about "your house burns down", "your computer is stolen" securely. You must never store the backup wallet.dat on any computer or device that will touch the internet besides your wallet PC; buy a new flash drive for this, or burn a CD from your secure computer. Restart your computer before creating a backup to ensure Bitcoin is not running or accessing the wallet.dat. You must also backup the passwords for both the hard drive encryption and username, along with the password of the wallet. Too many people have forgotten their passwords and lost coins. As you created these, you should be able to write them down. Paper password backups should be stored securely (think safety deposit box), and separately from the secure PC or location of wallet.dat backup media. Advanced Level: TEST YOUR BACKUP Send your new secure PC wallet 0.001 BTC and see that it gets there. Great? Now wipe the hard drive and do it all again! Okay, that's extreme, but imagine the hard drive dies and you must restore your wallet - it must work. Plug in a different cheap hard drive and do all the steps above to install the OS; then restore your wallet backup and spend your test bitcoins. Your backups must work. After verifying that you were able to re-create the OS and restore your backup to spend bitcoins, the second hard drive can be another type of backup you can store securely, or if not, you should wipe it with manufacturer's "erase disk" utilities. |
|
|
|
If you had a balance showing in your Bitcoin-Qt before you backed up the wallet, that balance should still be showing when you restore the wallet. A poster above alluded to a potential problem renaming the file - Windows by default hides the full file name from you (the stupidest thing ever). To fix this: - In Windows Control Panel, go to Folder Options, the View tab,
- select 'Show hidden files, folders and drives', uncheck 'Hide extensions for known file types', uncheck 'Hide protected operating system files'.
Then you will see un-altered file names. You must be 100% sure that Bitcoin is not running when doing anything with the wallet.dat file. The bitcoin data directory on Windows is %appdata%\Bitcoin directory (a shortcut to C:\Users\ yourusername\AppData\Roaming\Bitcoin, or whatever your correct Windows path is). This is where the real wallet.dat used by Bitcoin will be located. Create a text file named bitcoin.conf in that directory if you don't have one, and add these lines, to make bitcoin close when you specify and not accidentally run in the tray: minimizetotray=0
min=0Close Bitcoin. Bitcoin also may take over a minute to close, be sure it is not running in task manager before doing anything wallet-related. After all that, rename whatever wallet.dat file you have in the bitcoin data directory to move it out of the way. Then restore your backup, with the correct name, to this directory. Finally, to ensure that you have a correct balance, when you start Bitcoin-Qt for the first time, run it with the command-line option Bitcoin-Qt -rescan. It will take about 10 minutes before it starts up, as it looks through all blocks to find transactions and your actual balance. If you do not have a balance at this point, your backup does not have the address, or the bitcoins are spent. To see if the wallet even controls the address, in Bitcoin-Qt, go to Help->Debug Window, Console Tab, and type dumpprivkey (using your bitcoin address). You will get either the private key if your wallet includes the address, or a red error message if it does not. If you do not have the address, then your backup is bad, perhaps taken before you encrypted the wallet and created another address, or copied while Bitcoin was running. |
|
|
|
Down. But This time it's different. The bitcoincharts.com DNS record has been changed, and there is no "A record" IP addresses, and the last known IP address is unresponsive. Registrar URL: http://www.1api.net
Updated Date: 2013-11-27T18:34:45Z
Creation Date: 2010-11-08T02:11:21Z
Registrar Registration Expiration Date: 2014-11-08T02:11:21Z
Registrar: 1api GmbHHowever, there is a ipv6 AAAA DNS record that appears to be working, I was able to to access the page once through a barely-responsive overloaded proxy, as my layers of firewall block native ipv6: ;; ANSWER SECTION: bitcoincharts.com. 140 IN AAAA 2400:cb00:2048:1::6ca2:c7b7 bitcoincharts.com. 140 IN AAAA 2400:cb00:2048:1::6ca2:c6b7 traceroute to bitcoincharts.com (2400:cb00:2048:1::6ca2:c7b7), 30 hops max, 40 byte packets
1 2a02:348:82::1 (2a02:348:82::1) 8.580 ms 8.528 ms 8.439 ms
2 xl-internetservices.nl.ip6.jointtransit.nl (2a02:10:0:1::e:3) 11.417 ms 3.475 ms 11.262 ms
3 ge-0.ams-ix.amstnl02.nl.bb.gin.ntt.net (2001:7f8:1::a500:2914:1) 2.668 ms 2.603 ms 2.699 ms
4 * ae-5.r03.amstnl02.nl.bb.gin.ntt.net (2001:728:0:2000::11a) 3.403 ms 3.449 ms
5 2001:590:2:2e::1 (2001:590:2:2e::1) 4.144 ms 4.062 ms 3.981 ms
6 as13335.xe-3-0-2.ar1.ams3.nl.nlayer.net (2001:590::3f8d:df1e) 1.206 ms 1.337 ms 1.553 ms
7 2400:cb00:20:1024::8d65:4b32 (2400:cb00:20:1024::8d65:4b32) 2.214 ms 1.520 ms 2.348 msIPv6 Ping Output: PING 2400:cb00:2048:1::6ca2:c7b7(2400:cb00:2048:1::6ca2:c7b7) 32 data bytes
40 bytes from 2400:cb00:2048:1::6ca2:c7b7: icmp_seq=0 ttl=60 time=1.66 ms
40 bytes from 2400:cb00:2048:1::6ca2:c7b7: icmp_seq=1 ttl=60 time=1.50 ms
40 bytes from 2400:cb00:2048:1::6ca2:c7b7: icmp_seq=2 ttl=60 time=1.65 ms
40 bytes from 2400:cb00:2048:1::6ca2:c7b7: icmp_seq=3 ttl=60 time=1.62 ms
--- 2400:cb00:2048:1::6ca2:c7b7 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3012ms
rtt min/avg/max/mdev = 1.509/1.613/1.668/0.074 ms, pipe 2I know that the admin was thinking of changing hosting, since they messed up his routing twice in the last year. |
|
|
|
I'm doing this on my laptop with an nvidia card (that is otherwise unused). It's running just fine, except sometimes the laptop overheats from the GPU and shuts down. A better approach is to use the nvidia control panel to underclock the GPU core speed. Then vacuum the dust out of the fan hole and slots. And get a desktop PC before you solder-crack your GPU chip. |
|
|
|
Nearly identical thread: The second that you say the word "format" or "repartition", the only hope is to yank the drive from service and scan the whole surface for any recoverable private keys. Data likely will no longer be where it should be, recovery software will find junk in the sectors where "wallet.dat" is indicated to have been.
A year+ ago you formatted your drive. You "recovered" a wallet a year ago, without looking to see if it even has correct data in it? Slim to none would be the odds I place on recover. |
|
|
|
No, I don't want to keep using this wallet. I've been able to make the dumpwallet function on pywallet give me all of my keys. Will this achieve the same effect if I move them all into another wallet?
Yes. You can actually completely close Bitcoin and rename the wallet.dat that you currently use; start Bitcoin again which will create a blank wallet, and then use RPC to import all the private keys: 1. Make a configuration file that enables server=1 2. Start bitcoin-qt 3. create and run a batch file that imports all your private keys at once, with lines like these for every key:
C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe importprivkey Kydi6vXSJrQiJR15W9gFCqFmhYH42ALx5u9zsySyDaYiutPXpjNy import 1
C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe importprivkey 5JN1FUzCAwEywF3ji3RJGNMZnSDFH86szkY3EpE8kdbq1f6hUV3 import 2Bitcoin-Qt will appear to "lock up" for 10 minutes or so while it rescans the blockchain for transactions for the addresses. You now have a wallet free of problems and an accurate balance. You don't say why on earth you would want to use a web service that causes lots of people headache by creating bad transactions instead of using the reference client... |
|
|
|
It's a menu option, under settings. Don't see a menu?? : I'm running Ubuntu 12.04,
One thing I notice is that the menu (File, Help, & such) does not seem to display if the program is shut down, and then restarted. If the window is maximized, these items show up again. You are not the first to report strangeness with Unity (the bastard pile of MacOS wannabe move-the-menu-to-the-top bs that Ubuntu slapped on Gnome in order to keep up with Windows 8 in the stupidifying of GUIs). There is an official issue here: https://github.com/bitcoin/bitcoin/issues/1242 where you can add your steps to replicate on 0.8.0. The workaround is sudo apt-get install kubuntu-desktop. |
|
|
|
I started working on sierrachartfeed to see what can be done. The bitcoincharts history API is purposely borked. It's been modified to only have five days of trades available regardless of the query. The HTML wrap was removed, but the ~ 1 request a minute limitation is still there. The only way to fix this is to get the complete uncompressed CSV download (http://api.bitcoincharts.com/v1/csv/, 300MB for just mtgox) if SCID data is older than five days. I think I tried HTTP byte range requests on these CSV files before and the server didn't support it; there's no Accept-Ranges header. If it did, I would still have to make requests "blind", since I could only approximately index them to find where to continue.....or have a charting app that only goes back five days. Edit: the full history file.csv server supports byte ranges. I wrote a library that will get chunks by ticker... Gameplan: resume history from csv to 1 day old slowly catch up last day from crappy history API Hurdles: -Efficiently index and seek for resume timestamp in csv, without local copy -1 minutes between requests means naive history to live transition will miss trades, will need to buffer live stream until stream trades are also in history, and merge ticker lists. |
|
|
|
I like doing this: So:
1. You had a bitcoin wallet.dat running on windows with password #1,
2. you copy the Bitcoin wallet to an Ubuntu machine,
3. on the Ubuntu machine you change the password to password #2,
4. you are surprised that when you boot back into Windows and the password is still #1?
It is not a good idea to use the same wallet.dat on multiple computers, they will go out-of-sync after many transactions or as soon as you start adding labels. A good way to lose money, as eventually one wallet won't have addresses that are in the other.
Deepceleron's razor #17: If something is worth saying to a noob, deepceleron has probably already said it.
|
|
|
|
|
A miner that originally cost 1 BTC may now only make 0.25 BTC ROI during its lifetime, due to increasing difficulty making it obsolete. However, that 0.25 BTC valued in government currency is worth more - the value of the miner is tied to the exchange rate.
Miners also are a way to obtain Bitcoin that doesn't have the hassle of exchanges, banks, transferring currency, dealing with third-parties, etc.
|
|
|
|
I can see fees becoming a scammers dream.
Imagine "for sale 0.8 BTC , $US at Mt. Gox rate, you pay fees" and your'e buying hundreds of bits of dust.
This is incorrect. Even if the transaction is from many txouts in the sender's wallet (and they have to pay a larger fee), you will be receiving a single consolidated payment for the amount. The only instance where "buyer pays fees" may be services where you withdraw a balance from your account on an exchange or pool to your wallet. Professionals manage their wallets so amplified fees don't occur. |
|
|
|
Please excuse if this has been asked before but quite a while back I mined 1.10024 coins through pools over a period of several weeks receiving payments on average of 0.01xxxxxxx to 0.02 coins.
If I want to send a payment of say 0.5 coins to someone am I going to have to pay a fortune in fees because my one whole coin is comprised of lots of little bits?
If you want to spend 0.5 Bitcoins, (say, $500) and that takes you 30 to 50 of the size coins you've got, you'll be paying 25 to 38 dollars in transaction fees. That's more reasonable than the situation the OP is faced with, but still damned annoying. Like you say the OP is fucked basically and in my scenario nearly fucked as I doubt I would have used all that electric to mine had I known, I believed the "minimal fees" hype that everyone was flouting. It appears to me that Bitcoin is running into the realms of a currency of the wealthy ie. those who can buy whole coins, which will no doubt deter new users coming into the fold. Could it not be built into the system that small fragments that are kept in a wallet for a certain length of time after x notifications are coalesced into larger units? User Cryddit has been posting some misleading responses, using terminology that is not used to describe transactions. There is no such thing "coins" like he is describing, and there is no "whole coin" or bitcoins are "too expensive". Read, understand: http://we.lovebitco.in/how-bitcoin-works/transactions/A transaction is composed of inputs, also known as unspent transaction outputs - individual previous payments that were received by a wallet, either to the same address or to multiple wallet addresses. Those previous payments are then used as needed to fulfill the balance of a payment you may want to send. Here is a some examples of real transactions, demonstrating how large a transaction may be, based on the number of inputs it uses: - 1 input: 257-259 bytes - 1x minimum fee
- 5 inputs: 976-980 bytes - 1x minimum fee
- 8 inputs: 1514 bytes - 2x minimum fee
- 39 inputs: 5848 bytes - 6x minimum fee
Lets make the most extreme example possible: you signed up for some scam-faucet that paid you what we would call "dust", useless payments of 0.00006 (nearly the minimum allowed to be sent, a few pennies). Then the fees would be a significant portion of a payment: - 0.00006 x 39 = 0.00234
- minimum fee 0.0001 * 6kB = 0.00060
You can see that even dust is still spendable. For transactions that aren't bloat-by-design, the minimum fee will not be a multiplier of the minimum or a significant amount. To answer the question, users can manage and consolidate their own coins. When you send your next payment, you can add another recipient, yourself, and send the balance of your wallet back to a new wallet address to solve the dust problem in the most efficient manner. |
|
|
|
Now it is the question how I can relocate this hidden bitcoin-folder. The wiki mentions a "bitcoin.conf [optional]". I looked for it but there is no one. Do I have to set manually?
http://we.lovebitco.in/bitcoin-qt/configuration-file/A configuration file can be put in the .bitcoin folder, however that means you have the .bitcoin directory AND the other data directory where the databases are stored, which is awkward. A better option is to move the contents of this folder to another, and start with a command line option (that you can create a menu option or script to run): bitcoin-qt -datadir /mount/mydrive/bitcoinhttp://we.lovebitco.in/bitcoin-qt/command-line-options/ |
|
|
|
It looks like some more undocumented unannounced changes to break things. 1. Per-IP request limiting to 1 per 60 seconds or so 2. history API no longer works like it did. A "start" only request seems to be the only type of history API request that returns data: A request like: http://api.bitcoincharts.com/v1/trades.csv?symbol=mtgoxUSD&start=1385000001dumps about 1MB of now HTML-header-wrapped trades, but with 0D 0A (linefeed) between trades instead of any HTML: <html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body>1385000001,635.500010000000,0.299400000000
1385000008,635.500010000000,0.250000000000
1385000050,635.500010000000,1.000000000000
1385000063,635.500000000000,1.802060090000
1385000090,635.500000000000,1.197939910000
1385000091,635.500010000000,0.368739030000
1385000092,635.500010000000,0.945989800000
1385000092,635.640000000000,0.756793140000
...These calls were previously documented to not consistently return the correct time periods. For now, you can temporarily backup and remove your C:\SierraChart\Data\*.scid files, and start with the --disable-history and at least see live trades. I will try to correspond and see if it is fruitless to try to write any API interface that is expected to work for more than a few months. |
|
|
|
|
Show Posts
