I just had the same fatal DB error, went to copy the folder contents and the blkindex.dat would not copy over, said I/O error. I downloaded the new 0.8.0, and ran it, receiving the same error. I then deleted the blkindex.dat and reran the installer, it re-indexed the blocks and finished downloading the remaining ones in 75 minutes. My p2pool transactions were missing for a while, it found those as well. Hope this helps someone.
cheers.
There is no need to "copy over" anything. You just close Bitcoin (likely the cause of some problems), and install the new version. |
|
|
|
|
Your address link doesn't work (or was removed).
If you have a mtgox account, you can permanently add a private key to your account to be swept to a mtgox bitcoin balance.
The Bitcoin client allows you to import private keys if you have the patience to install it and let it download the blockchain. In the debug console window: importprivkey 5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF "This is a test" with your address's key and a label.
|
|
|
|
It's a Ubuntu Unity GUI bug, the standard menu location was moved to the top of the screen in all applications by Canonical. They don't intercept Qt menus consistently with their Gnome mods. Developers of apps like Firefox have made patches to compensate for Unity suckage. Apparently the menu might occasionally come back if you minimize/maximize a few times or close and restart. https://github.com/bitcoin/bitcoin/issues/1242The server=1 command only turns on the RPC server (you also need a rpcuser/rpcpassword options in bitcoin.conf for it to work). It will still launch the Qt GUI if you are running bitcoin-qt. You can open a console window when Bitcoin is running and access bitcoind to do your RPC work: ./bitcoind help |
|
|
|
It will be no problem until your clients start to generate new addresses. Obviously they going to be different and your clients will be showing different balance. Merging them will be kind difficult.
Your client starts generating new addresses immediately to replace those used from the reserve pool. You must replace the wallet copy with the original again and again before there is any possibility of a new pool addresses being used. You will of course lose information if you add addresses to the address book or label addresses in the wallet copy and then replace the copy with the one from the original computer - you can't use it for the basic functions you would want in a wallet. The alternative is to never copy them, then both wallets will become independent and eventually will have their own unique addresses. Change sent back to one wallet may not be spendable in the other, the balance of one wallet may suddenly drop. TL;DR - a bad idea. |
|
|
|
|
Blocks are created in consecutive order about every 10 minutes. The first blocks you start downloading are from 2009.
If someone sent you a payment now, your Bitcoin client will only recognize the payment to you when the final block containing it is downloaded - your client will have no way to send money without downloading the whole blockchain up to the block that contains your payment.
In addition, you can't trust a payment if Bitcoin can't see where the sender received money from. The lineage of every Bitcoin amount that has been transferred can be traced back to the block in which it was created. You must have the history to fully verify a payment is authentic.
Lite clients store most of the blockchain on another computer, you only request block information when it is needed. Your client doesn't have the information needed to become a full node and support the Bitcoin network.
Web wallets require you trust someone else's services with your Bitcoins, or for sites like blockchain.info that can't spend your address balances, you must at least trust the service won't disappear.
|
|
|
|
OK, I started mining in December 2012. I put together 6 radeon cards I had lying around, and have been chipping away my little measly .1x BTC per day.
You got lucky! You don't say your hashrate, but your income would indicate you would average a block found every 8.3 months (so it's as likely for you to solo mine for years without finding one as you would find a block in three months). I am one of the many waiting on BFL ASICs and will then be new to mining, and was wondering, when you find a block in your pool, you get the same amount you normally do mining or a larger reward for finding the block?
Sorry for the newb question!
Rewarding the block finder increases variability, when the goal of a pool is even distribution of rewards for work performed. It's just a fun statistic to show who found a block. |
|
|
|
|
What should alleviate the hysteria is pools not responding to the clamorings of a few repeat trollers to enable faster block growth with an agenda of gambling more cheaply.
Size is not an issue anyway:
Block size of ozcoin's last blocks, with count of '1dice' ins or outs (of total transactions):
225257 2013-03-10 22:46:11 82.80 KB - 187 (195)
225254 2013-03-10 22:33:52 126.50 KB - 323 (373)
225253 2013-03-10 22:27:52 30.43 KB - 48 (80)
225238 2013-03-10 20:25:03 356.82 KB - 861 (1019)
225188 2013-03-10 13:47:53 266.71 KB - 646 (840)
225175 2013-03-10 11:41:32 65.82 KB - 139 (155)
225173 2013-03-10 11:33:25 221.28 KB - 542 (674)
225161 2013-03-10 10:25:58 174.79 KB - 345 (416)
225157 2013-03-10 09:47:16 142.34 KB - 341 (345)
|
|
|
|
I'll assume RAM is replaced every 5 years, and that Moore's law for it holds for at least 5 more years. 16GB costs $115 today and consumes about 5W of power. * Take $0.10/kWh for electricity, and it costs (5/1000 kW)*(4*365*24 hours)*$0.10 + $115 = $133 to buy and run 16GB of RAM for 5 years. Assuming a factor of 1/4 reduction in this price after 5 years (roughly doubling size/unit cost ever 2.5 years), we have $166 for 16GB for 10 years. Assuming 50 bytes per utxo on average, this is 320M utxos per 16GB of RAM, giving $0.0000005 to store a utxo for 10 years. But we have to scale this by the number of full nodes, say 100K: $0.05 for the whole network to store a utxo for 10 years. I only went to 10 years cause I don't know if Moore's law holds for longer. But we can safely say it's roughly $0.05 for a network of 100,000 nodes to hold a utxo for as long as Moore's law for memory holds. * http://www.newegg.com/Product/Product.aspx?Item=N82E16820104302http://www.kingston.com/dataSheets/KHX1600C10D3B1K2_16G.pdfI did this quickly so please correct me if I did something stupid... Yes, the thing you didn't consider is that if I am a new user and fire up my brand new install of Bitcoin in five years, I'm being paid nothing for having to download 10GB of blockchain even with pruned transactions, and might just give up. Blockchain bloat has a higher price. |
|
|
|
Without changing any other Bitcoin rules though, I would say it is a payment that as an input, when evaluated by minimum fee rules in aggregate with like inputs, would cost more to send in fees than the value of the payment. This is a payment likely to become an unspent TXO - for most it is cheaper to discard than to spend. This is the scenario with Satoshi Dice, a gambler will be getting hundreds of like payments of small value.
Grabbing some sample transactions with two outputs (payment + change), and determining the minimum per-input amount that would result in a post-fee value greater than zero:
1 input: 257-259 bytes = minimum payment .00050001
2 inputs: 436-439 bytes = minimum payment .00025001
5 inputs: 976-980 bytes = minimum payment .00010001
6 inputs: 1157-9 bytes = minimum payment .00016668
8 inputs: 1514 bytes = minimum payment 0.00012501
39 inputs: 5848 bytes = minimum payment 0.00008975
So it looks like a good "receiving this payment will cost the recipient" threshold is any output that is less than 1/5 of minimum fee, from the examples, 20%-40% of minimum fee should be required.
I forgot to be recursive - if these miner rules are enforced, clearing the spams also must follow rules; the examples I gave above to spend dust can't be used: 5 inputs: 976-980 bytes = minimum input .00010001 -> sends .00000005 5 inputs: 976-980 bytes = minimum input .00012000 -> sends .00020000 6 inputs: 1157-9 bytes = minimum input .00016668 -> sends .00000008 6 inputs: 1157-9 bytes = minimum input .00020000 -> sends .00020000 I would say the minimum output should be 0.0002 BTC (40% of min per-kb fee). That only costs SD 40% more to spam the blockchain with spendable outputs. |
|
|
|
Bitcoin didn't anticipate that people would pay fees to spam the blockchain - we required a fee for anything below .01, and if you have a profit model you can pay that... Payments need to be self-funding, that the recipient will have a net gain by receiving the payment after including retransmittal costs. So then what is the definition of not making "economic sense to spend"? A single 0.0005 payment meets the most simple definition of this - received alone, it can't be spent. However, if my wallet had 1000 BTC in it, I can currently send someone or myself 1000.0005 for free immediately. I can also spend lots of dust. This is why free transactions should be removed - if you are wealthy, Bitcoin works differently for you. Without changing any other Bitcoin rules though, I would say it is a payment that as an input, when evaluated by minimum fee rules in aggregate with like inputs, would cost more to send in fees than the value of the payment. This is a payment likely to become an unspent TXO - for most it is cheaper to discard than to spend. This is the scenario with Satoshi Dice, a gambler will be getting hundreds of like payments of small value. Grabbing some sample transactions with two outputs (payment + change), and determining the minimum per-input amount that would result in a post-fee value greater than zero: 1 input: 257-259 bytes = minimum payment .00050001 2 inputs: 436-439 bytes = minimum payment .00025001 5 inputs: 976-980 bytes = minimum payment .00010001 6 inputs: 1157-9 bytes = minimum payment .00016668 8 inputs: 1514 bytes = minimum payment 0.00012501 39 inputs: 5848 bytes = minimum payment 0.00008975 So it looks like a good "receiving this payment will cost the recipient" threshold is any output that is less than 1/5 of minimum fee, from the examples, 20%-40% of minimum fee should be required. |
|
|
|
|
There is no cancellation available at the protocol level. The best one could do would be to double-spend a duplicate transaction. Clients consider spent = spent, the spent funds being removed from your balance and unavailable, even if the transaction never will confirm.
The way a client could do this would be to offer a "modify and retransmit" feature, allowing one to re-spend the identical inputs and outputs of a transaction with more fees (adding more inputs if needed to increase the fee). Implementing a double-spend feature with this method shouldn't make an unconfirmed payment less trustable if the resent payment was recognized as a replacement.
The reference client doesn't let you create inadequately-fee'd transactions, so this is a feature unnecessary in any client that understands the rules. Only if larger-than-minimum fees become required for timely processing in the future, by everyone else paying more than standard fees for preferential treatment on an extremely busy network, would this be useful. I would expect new clients which start automatically recommending higher fees based on network activity if Bitcoin becomes this busy.
|
|
|
|
This is a known rule when creating website : if we fail to explain things to the user within a few seconds, then we just lose these visitors. Period. We can gain full attention of our visitors only if we succeed to explain things in a very concise way first. And only then, more extensive content can be added (and is in fact very needed in my opinion). But it should never be the starting point otherwise the website will do the opposite of what we want : it will confuse or scare people.
... The problems with the site design that make it not ready for prime-time: A. The actual content is small - it has merely: 1. Four pages of bullet points for individuals - enthusiasts. 2. One page of Bitcoin terms and one page of "sort of" how it works 3. A "you need to backup your wallet" page 4. Pages of off-site links B. It has a sparse design that has little in the way of box model or templates for rich content creation. I had to repurpose the only box in CSS, used as a table-of-contents elsewhere, to do anything interesting (geek facts shown at http://we.lovebitco.in/how-bitcoin-works/). This will make adding pages with structured content more difficult and less uniform. The menu doesn't allow much room for expansion or deep content either, and in appearance it also says "not much here". C. The redesign apparently has the same mission of weusecoins.com, but doesn't do it as well. What bitcoin.org should be is a home page for the reference Bitcoin client, the Bitcoin protocol, for promotion of the currency as a viable system, and only as a sub-mission be a gateway to other resources. Every other third-party wallet, service, and merchant site has a home page, Bitcoin as a client that runs virtually 100% of the backbone of Bitcoin sites and nodes needs one. Inclusion of some third-party sites and services will result in the omission of others, thereby creating a perception of recommendation or trustworthiness; it may be better to omit all third party references and defer to other directories of services. As an example of a modern site that is simple, but does not lack content for the benefit of the noob: http://www.ubuntu.com/ |
|
|
|
The possibility of evaluating transaction fees based on input/output quantity crossed my mind earlier this week with my evaluation of fee structure that led me to one change, removing all free transactions. Upon reflection, the current system is adequate and perfectly charges for the resources used. It is possible to make very large inputs, so inputs must also be taxed on a basis of size, not on a per-input basis, and especially must not be free. In fact, it is the inputs that take CPU work, it's the digital signatures in them that must be verified. In addition, sorting out and programming what part of any possible script is the "input" or "output" that should be evaluated is quite a task. Secondly, while generally only the number of outputs are under a user's control when creating a transaction, it is also within a user's control to not fill up their wallet with satoshis. If you want to reward efficient transactions, one could consider a .0000005 BTC per byte fee. However this makes nearly every transaction have a different minimum fee, making it nearly impossible to predict what amount to send to empty a wallet, to estimate or educate on the standard fee, and would punish the user who's wallet merely selects one extra input or sends change. This optimization I also discount. Many services would be impacted by any fee change - consider dozens of pools, exchanges, merchant sites, etc that would have to re-code their sending logic and algorithms after a fee change breaks their site. There must be a net benefit to the entire network. |
|
|
|
|
You can download and install Bitcoin version 0.8.0. It has vast improvements to the block download speed, plus it includes a new database system that will reread and import any prior blocks you have downloaded to your hard drive, ignoring any errors in blkindex.dat.
|
|
|
|
|
Everything related to your bitcoin identity is stored in the wallet:
addresses
reserve addresses and the time they were created
address labels
address book (other people's addresses)
past transactions
the last block height seen
There were other things previously stored in the wallet, like program settings, but these have largely been moved out.
|
|
|
|
However, as soon as you request for a new address, the satoshi client generates a new key. Your wallet now has 101 keys. This will keep adding up, essentially forever, or however how many transactions you have.
WAT? It doesn't take change address from the 100 already generated? It would mean that after every outbound tx you have to do backup. If you take a penny out of the penny jar, Bitcoin puts one back in. Use one of the reserve addresses, and Bitcoin will generate another to keep the reserve address pool size constant. |
|
|
|
Definitely gox main income.
-1 An occasional person who 1. thinks that mtgox is a wallet service and 2. can't read the first line on the satoshidice "how to play" page is not mtgox's main source of income. Mtgox makes 0.6%-1.2% per trade on millions of dollars of currency trades a day. I remember a help desk system I used, somebody had put in a solution "training issue"->"user is a l0ser". It was removed after it consistently ranked in the top five problem solutions. |
|
|
|
Dude, random.org. Also, this idea won't work. Why? Because Geiger counters measure radiation, and the amount of radiation around you (on any significant, detectable level) is probably strongly non-random.
-1 A Geiger counter measures radioactive decay. Radioactivity is the process whereby unstable atomic nuclei release energetic subatomic particles. Radioactivity is a random process, meaning that it is physically impossible to predict whether or not a given atomic nucleus will decay and emit radiation at any given moment. The amount of it doesn't change the randomness of it. dude, http://www.fourmilab.ch/hotbits/ |
|
|
|
|
For the love of god, why can't he please go back to his old nick and steal someone's Bitcoins?? I've been waiting for "You got donged!" to be a meme for so long!
|
|
|
|
|
Show Posts
