Okay thanks that makes it somewhat clearer. In that case I shall just let it rescan to its heart's content.
ETA: actually I'll ask while I'm here: what's the difference, if any, between the process you just described, and the process of 'reindexing' that you can force it to do with the '--reindex' option? I ask because I've just started it up again and the status bar at the bottom says "Synchronizing with network..." which is what made me worry it's redownloading blocks.
It should say "reindexing blocks on disk..." when it is reindexing. However, yours doesn't. Perhaps it is because you haven't downloaded to entire blockchain yet. Since it indexes the blocks as it downloads, I think that since you don't have the full blockchain on the disk yet, it will both reindex and download the blocks, and say "Synchronizing with network..." I shall scoot along to the wiki to see if I can get to grips with what all the different files are trying to do... I understand the blk00xxx.dat files themselves, but I don't yet understand the rev00xxx.dat files, the index/000xxx.ldb files (and a .log file in with them too), and the stuff in the chainstate dir. Anyway ta for the pointers.
You can read some more about the data directory on the Bitcoin Wiki here: https://en.bitcoin.it/wiki/Data_directory |
|
|
|
First off: suppose I have deleted EVERYTHING in the .bitcoin folder with the SOLE exception of the blocks/blk00xxx.dat files, of which I have the first 146.
Therein lies the problem. the blk files are just the raw data from the network dumped to the disk. What Bitcoin Core actually uses for everything are database files. These are found in blocks/index which contains data on where to find blocks, and the chainstate directory in the datadir. The chainstate directory is the most important regarding the blockchain. From the Bitcoin Wiki: chainstate subdirectory
[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of may 2013) for every output being spent. By deleting this directory, Bitcoin Core must rescan the entire blockchain from the blk files in order to rebuild these databases. It is not redownloading them either. The different timestamps that you see is because Bitcoin Core is reading through every single blk file and rescanning them to rebuild the database. |
|
|
|
|
How are you going to make something that lasts forever and is agreed on 100%? I can guarantee you that at some point in time, one of the systems supposed to last "forever" will fail. I can also guarantee you that you can't get everyone to agree. Someone will dissent, someone will try to change something to make it better and arguments will ensue. Furthermore you can't possibly address every single issue and find a solution that lasts forever. Another issue will show up that no one ever thought of and solutions thought to work will be broken.
|
|
|
|
|
Not that I know of. It isn't really a problem though.
|
|
|
|
|
So I think what is happening is the NAT (router) is getting in the way. It is port forwarding. The NAT receives the connection from the correct port. But, it forwards all of the data to the node behind it, and the data is coming from a different port. The node still records the IP address as the same since the data is being forwarded, but it does not know what port the data is from, so it uses the port that the NAT is giving the data from. This, I think, is why you are seeing different port numbers from getpeerinfo than what they actually are.
|
|
|
|
Keeping quiet about ownership of Bitcoins will almost guarantee that your neighbors or others will rob you of them
How? If people don't know that you have Bitcoin, how can they rob your Bitcoin? |
|
|
|
|
That's why you always do the trade in daylight in a public place where there are lots of witnesses. The more people around, the less likely this happens.
|
|
|
|
|
Find a bitcoin address that was posted a long time ago, at least 3 months, and use it to sign a message. In Bitcoin Core: go to File > sign message. Type a message into to big text box. Find and select the address you posted in your wallet by clicking the little book icon and selecting the address. It should show up in the text bar next to the button. Click sign message. Then post the Bitcoin address, the message, the signature and a link to the post here so that people can verify that you own the account.
|
|
|
|
In China, exchanges typically also own mining farms and wallet services, or at least have very close relationship with miners
True, so that means that both the mining and exchange operations will do the same thing. Voting is not a solution, bitcoin is invented just to avoid voting of monetary policy. To reach universal consensus is the only way, why could not Gavin take the 4MB approach and make the change gradually? I think everyone could make some compromise and reach a universal consensus. This is more like diplomatic negotiations between countries, no vote is possible
There actually is a vote, based on the number of a client run. If the super-majority (>90%) run a node that supports the new protocol, then that means a super-majority voted "yes" for increased block size. Those running older versions are voting "no" for the change. Gavin suggested the 20 MB because he thought it was a safe enough size for a long time. However, he is willing to compromise. Looking at the emails in the Bitcoin-dev mailing list, it looks like Gavin is willing to have the block size increase to 4 MB or 8 MB. More people would like this smaller jump than the big one to 20 MB. |
|
|
|
|
I'm not seeing this on my nodes. One is a my pc with windows 7, the other is an Ubuntu vps. Where exactly are you seeing the wrong output? Can you post what it says and what it should actually say? That might help us diagnose better.
|
|
|
|
The decision making is based entirely on how many people support the new protocol and how many blocks mined are of the new version. The fork only occurs when >90% (probably more like 98% though) of the full nodes and miners are a client which supports the new blocks. Only then does the fork occur. There would not be enough hash power remaining on the old chain to support and secure it.
Of course 90% is a major consensus, but it could also be a 40/60 or 30/70 situation which we are stuck in right now In fact you can fork the chain anytime, just run a different version of clients that is not compatible with the core (currently XT is still compatible, but it has the potential to be incompatible if the block size limit is raised). You can even support your version of bitcoin with your own hash power and your exchange, but that will most likely become some alt-coin If no one uses it, it is worthless. With the current situation, then nothing will happen at all.
1. People will start running Bitcoin XT if they wish.
2. If more than 50% runs on XT, Gavin will approach the Devs again to change bitcoin core itself.
3. If that happens, it is just another routine ugrade and hard fork does not happen.
4. If that does not happen, Gavin will wait for 90% of the netowrk to be run on XT.
5. Then he'll do the hard fork.
In the whole process described above, Chinese exchange/American exchange has no extra wightage or contribution. It is all about the nodes that is running the network. Whoever does not comply with the majority will just be left behind and that happens almost everyday on bitcoin netowrk when a block gets orphaned.
No need for so many steps, now step 1 will not happen for those chinese exchanges, together with their corresponding mining hashing power and wallet services Take an extreme example, if all Chinese miners connected towards several mining pools in Taiwan and HongKong, and those pools do not upgrade to XT, it means more than 50% of the hashing power will stay on the original chain. If Chinese exchanges won't change to XT, then it is very likely Chinese miners won't change too. They do hold lots of negotiation power in this case The miners hold the negotiation power, not the exchanges. It is the miners who decide whether to switch or not. They are an integral part of the current consensus voting system. If 50% of the miners don't agree, then they don't switch. If they do agree and the switch happens, then the exchanges must switch too because they would begin losing money from being on a stale and insecure chain. The miners can always find another place to exchange, or just keep the Bitcoin and use it. |
|
|
|
3. If that happens, it is just another routine ugrade and hard fork does not happen.
4. If that does not happen, Gavin will wait for 90% of the netowrk to be run on XT.
5. Then he'll do the hard fork.
It is not just a routine upgrade. Increasing the block size itself is inherently a hard fork. There is no way to increase the size without forking, no matter what client is used. |
|
|
|
|
The wallet is the node, unless it is SPV. For example, simply installing Bitcoin Core and running it and using it as your wallet means that you are running a full node. You can run the node as a server with bitcoind or as a wallet with a gui with bitcoin-qt.
|
|
|
|
|
The decision making is based entirely on how many people support the new protocol and how many blocks mined are of the new version. The fork only occurs when >90% (probably more like 98% though) of the full nodes and miners are a client which supports the new blocks. Only then does the fork occur. There would not be enough hash power remaining on the old chain to support and secure it.
|
|
|
|
It would loose microtransactions at the very first. And does it need them? I think not because they bloat it up ad infinitum!
A large portion of transactions now are micro transactions, and they haven't bloated the blocks. Fees will never be enough for miners if you keep raising blocklimit ahead of demand and only on basis of a guess about the future. What if the future predictions doesn't come true? Then you are stuck with a coin that doesn't produce fees at all and miners will be forced to form a cartel.
Miners have the choice to quit. As I said earlier, once mining becomes unprofitable, miners will quit. That of course may lead to greater centralization, but only because of bandwidth issues. Even with 20 MB blocks, most people have enough bandwidth to support that size, and by the time that the size is reached, bandwidth should increase enough everywhere so that almost everyone has enough bandwidth. It is not a guess either. The prediction is based off of historical data of block sizes and the growth rate. Eventually, within a few years, this scaling problem does become an issue. YOU JUST DON'T RAISE BLOCKLIMIT AHEAD OF DEMAND BECAUSE THAT'S EXTRAORDINARY STUPID THING TO DO. IF YOUR FUTURE PREDICTIONS TURN OUT FALSE IT'S RUINED!
Having a plan for a future condition never hurts. He is planning this way ahead of any possible maximum of the block size. This allows for a smooth transition. The code is written beforehand, bugs are worked out beforehand, and the change is not a rushed panicked thing that scares the crap out of everyone and causes a loss of confidence. By doing it now, it mitigates some of the negative consequences of doing it in a short time on short notice. Not even talking about that he can't even get a consensus anywhere (not with the devs, not with the miners, not with the exchanges, not with the investos, the community, the users) HE IS A WASTE OF TIME! IF HE WAS RIGHT IN THE HEAD HE WOULD LAY IT OFF NOW.
He definitely has a lot of the community and users on board. I have not been able to find if any miners or exchanges disagree. Most are in favor of the block size increase, but only by some amount, not all the way up to 20 MB immediately. |
|
|
|
|
Since it is a VPS, it is hard to know how to fix the issue. Perhaps try allowing connections through the node port. Go to the management console for your VPS from your provider and allow everyone to connect to whatever port you are using. That may fix the problem, it also may not.
|
|
|
|
|
It's hard to track and trace Bitcoin transactions to a single person. However, transactions to and from addresses can be traced, but it is hard to know who owns what addresses. It can be very anonymous when done correctly.
|
|
|
|
|
It's possible that if you are behind a router that the router would change the port and forward everything to the port on the node.
|
|
|
|
|
Show Posts
