Since Bitcoin-Core 0.11.0 you can prune (trim) the blockchain in Bitcoin-Qt.
But not from the UI.
You need to add prune=550 to your bitcoin.conf file and restart Bitcoin-Qt.
-prune=<target in MiB> will tell bitcoin-core to remove blocks which are older than oldest block that can be kept with a chainsize (sum of block-sizes) of <target&...
Bitcoin has to maintain some balance to be able to maintain the ability to be decentralized. As you've correctly established, this is partly down to making sure that the resource requirements of fully validating the block chain are not unreasonable. There's a push form the consumer side of things to constantly increase the resource usage of Bitcoin for ...
I run a full node, and as of today, the blockchain is 10.1 GB. Since the bitcoin network is active, the answer to your question about how big the blockchain is something that is quite time dependent. If you were to come back in a month and ask the question, the answer would likely be 11 GB.
I was wondering a while back about the size of the blockchain and ...
This is explained in Satoshi's original paper:
Basically, the block hash does not contain the hashes of the individual transactions, rather it contains the root of the Merkle tree of the hashes. Once all the bitcoin outputs of a transaction have been fully spent, then there is no need for the original transaction, and hence its branch is chopped off from ...
The total extra size is around 7GB as of November 2016. You can check by looking at the size of the $DATADIR/blocks/index directory.
If you copy that directory, you'll copy the index with it.
Updated values from comments:
11GB as of 2017-05-08 – via
21GB as of
2019-07-16 – via Vasil
27GB as of 2020-06-14. – via
Full nodes keep all blocks by default, but this is not necessary to achieve full node security. Full nodes validate the complete blockchain and enforce all consensus rules regardless of whether a full history is kept.
Keeping all blocks is a service to the network, as you'll be able to provide all blocks for synchronizing nodes or requests of thin clients.
The constant is called MAX_BLOCKFILE_SIZE and is set in src/validation.h. It is currently set to 0x8000000 which is 128 MiB (134,217,728 bytes).
You can see where it is checked in FindBlockPos() in src/validation.cpp.
There isn't any indication of why this specific size was chosen and it may be arbitrary. It is desirable to have some limit because some ...
To join the network, a Bitcoin full node will work its way through the network history, independently verifying the state of the network through time. So yes, each node will have downloaded and validated the entire transaction history, but a node can choose to use 'pruning mode', where it will discard unneeded transaction history after validation is complete....
Bitcoin core does not provide this functionality (as far as I know).
The mempool is where transactions are stored until they get put into a block. It would be hard to determine you had the correct mempool if you didn't keep track of the whole block chain, though. For example, someone could broadcast an older transaction, and you would have no way to ...
Depends what you want to do. Remember, to use bitcoin you don't necessarily need a full-node. You can use many of the lightweight clients that exist out there which rely on Simplified Payment Verification (SPV). But if you want to be a full node (perhaps you're mining or you want to verify transactions yourself), then you need to download the entire ...
This is called pruning.
Since Bitcoin-Core 0.11.0 you can prune (trim) the blockchain in
Bitcoin-Qt. But not from the UI. You need to add -prune=550 to your
bitcoin.conf file and restart Bitcoin-Qt.
Explanation: -prune=<target in MiB> will tell bitcoin-core to remove blocks which are older than oldest block that can be kept with
Up until 2017, both BTC and LTC had 1 MB block limit. When SegWit was soft-forked into both protocols, the capacity increased to a hypothetical 4 MB blockweight limit.
But the limit doesn't mean every block that's produced is 1 MB. All it means is that it can not exceed 1 MB. What determines the size of the block is the size of the transactions in the ...
No, you'll need to make space for a full copy of the blockchain somewhere. AFAIK, Armory rescans the blockchain in order to build its own database only after Bitcoin Core has fully synchronized. Therefore, Armory needs access to a full copy of the blockchain which is currently about 118GiB. Armory's database itself then will take more than 20GiB additionally....
If you're looking for unconfirmed transactions without loading the blockchain, you're going to have to trust someone since you can't verify the transactions yourself. Probably the easiest way to get these transactions is by using a third-party API service.
Blockchain.info provides a very good one here:
Yes, it is possible to load the blockchain binary data off to a bulk storage (HDD), while keeping the Index DB on performant storage (SSD).
The Bitcoin Blocks are stored in the blocks subdirectory in your datadir. The location of your datadir is either %AppData%\BitCoin, or set manually by you during the installation of bitcoin-qt.
I ASSUME you're using ...
I recommend reading about the Bitcoin Data Directory. You should also take a look at this answer: How do I specify in which directory Bitcoin blocks and other data should be stored?
Basically, all your Bitcoin data is stored in ~/.bitcoin on Linux. Not only can you specify a different location for this directory using -datadir=/some/other/directory, but ...
Bandwidth - You need to receive an 80-byte header about every 10 minutes. In addition, if you want to spend, you will get SPV proofs that range about 500-1000 bytes per utxo. In other words, the bandwidth requirements are really tiny.
Storage - Each block header is 80 bytes, as of this writing, there are less than 430,000 blocks, so 80 * 430,000 = 35.4 MB. ...
The blockchain size growth is kind of approximately linear at this time (although I wouldn't expect it to continue linearly). See the nice graph at https://blockchain.info/charts/blocks-size and particularly check the "All Time" scale option.
Over the past year, the blockchain size has grown by approximately 10 GB. On average, that would be around 27 MB per ...
The others didn't notice, that the maximum block size is 1 MB now, so teoretically the bitcoin blockchain can grow by 6 MB per hour which makes 144 MB per day, which makes 52.5 GB per year!
This is, hovewer, highly unlikely. There are two reasons:
People do not use full block. This is just not needed at the time being.
Some miners prefer smaller blocks (...
Because the data is already serialized in a pretty compact way and large parts of that data are hashes which are effectively random numbers as far as compressability is concerned. (Random data is not compressable.)
Also when you search for for example a transaction id in an index, it will point you to the exact location in the blockchain. Having to read a ...
Ok, I think I got it.
Here is a short guide based on this bitcoin wiki article.
This does not concern backing up your keys. If you lost your wallet, or your keys, and you made the backup discussed here beforehand, this backup will not help you recover your lost coins. This will only save you some bandwidth/time/storage.
Don't load a database to your ...
There are two types of wallets:
A full node client uses the peer-to-peer network to validate transactions and blocks and to relay information to other peers. To verify all transactions, the entire blockchain (~145G) acts as a dependency to enable the tracing of transactions on the network.
SPV, Simplified Payment Verification, is ...
The sizes you give don't match the paper. I can't even find mention of the sizes you give in the paper itself. Those sizes are incredibly wrong and way too large. They seem to be for input sizes, not output sizes. Input sizes are irrelevant to the UTXO set.
P2PKH are 21 bytes, P2SH are 21 bytes, P2PK are 33 bytes, everything else is their actual script size....
Maybe not exactly what you are asking for but CoinLab have a mining pool that intends to use the computing power of their members for jobs other than hashing.
From the Bitcoin talk forum topic:
We’ve identified a number of opportunities to monetize our growing GPU cluster at a higher rate than Bitcoin mining, particularly for NVIDIA cards: Protein ...
I already did working prototype for one bitcoind (with one copy of blockchain) managing multiple wallets: https://bitcointalk.org/index.php?topic=71542.msg96212 It is IMHO easiest thing to to with current codebase and it would fulfill the goal to provide for multiple users' wallets independently while using resources for only one running bitcoind.
But the ...
Use the -datadir option to specify a new location for the bitcoin data directory. Copy the existing bitcoin data directory to the new location and then restart bitcoin-qt. Check here for information on locating the default data directory.
This answer is now outdated please see Answer below
At this time, no, you can not strip the block chain (as far as I
know). There is one programmer (Mark Freidenbach AKA maaku) who is
working on further compressing the blockchain for the Satoshi bitcoin
The entire block chain is currently needed to verify all coins are
du rounds up file sizes to the next multiple of your filesystem's block size. It also includes the sizes of directories. So this will give you a (slight) overestimate.
You really just want to add up the total sizes of all the blk*.dat files. You can get that with
du -c --apparent-size /home/me/.bitcoin/blocks/blk*.dat
You can divide this number by ...