17

The current blockchain size is around 50 GB as of October, 2018. On Windows platforms, you can check the size of the blockchain by checking the size of C:\ProgramData\bitmonero\lmdb\. On Linux/UNIX platforms, you can check the size of the blockchain in the terminal by executing du -sh ~/.bitmonero/lmdb/. The Wolfram Warptangent v0.10.0 release bundled in ...


16

The main factor is the number of signatures included in a transaction. With Bitcoin you only have 1 signature per input, whereas with Monero you have N number of signatures (depending on your choice for that transaction) per input. There should be little else that affects the blockchain size as directly as that.


15

You are probably looking at a database file with the blockchain in it. The main variation cause is that the database library Monero uses, LMDB, preallocates some space for writing. Every so often, when that space falls too low, LMDB will resize the file to get more breathing space. Some OSes do not support sparse files - that is, files with "holes without ...


12

To some extent, it is, but it is also a common canard that FUDsters like to cling to. Monero transactions are indeed larger than Bitcoin's, and RingCT transactions will be even larger. However, most of the data (signatures) can be dropped by a node after verification (there are drawbacks, though: this node can't serve a blockchain to another node later). ...


11

Privacy isn't free. From what I understand, any coin that provides privacy will deal with at least some degree of bloat, as a private transaction will always add more data to the blockchain than a transparent one. This can be seen with coinjoin transactions in Bitcoin and Dash's implementation of coinjoin, both of which add significant amounts of bloat.


9

The transaction structure is: Transaction version: 1 VarInt Unlock time: 1 VarInt Per Input: 1 byte (type: either coinbase or regular spend) + 1 VarInt (pre-ringct amount) + 1 VarInt (the ring size) + Ring_Size VarInts (input offsets) + 32 bytes (key image) Per Output: 1 VarInt (pre-ringct amount) + 1 byte (type: only regular spend type currently ...


8

I am wondering if there's a command to predict / calculate how much time does bitmonerod.exe still need for a blockchain fully synced. This is basically impossible to calculate. Syncing speed depends on a variety of factors, such as type of hard drive (SSD or HDD), computer specifications (old computer versus relatively new computer), and bandwidth. On a ...


7

The previous answers are correct, but there are plenty of other reasons for size variations. The timing and order in which records are written will also affect the way space is allocated in the database, and if the two nodes didn't run in lockstep then they'll get batches of blocks at different times as well as alternate blocks at different times.


7

Probably because Windows, by default, reports file sizes in KiB/MiB/GiB/TiB (1024 bytes in a kilobyte, 1024 kilobytes in a megabyte, etc.), while Ubuntu, by default reports file sizes using the "proper" SI definition of those prefixes (1000 bytes in a kilobyte, 1000 kilobytes in a megabyte, etc.). Here's some website I Googled, with pictures of the two OSes ...


7

Currently it's still an open question but I believe it's the inevitable path if Monero adoption increases. The optimal way for a sharded distributed DB to operate is to have encoded rules for mapping from a key to a shard node. E.g., to look up a key image, use the first byte of the key as a map to one of 256 possible branches of shared containing the record....


6

You can't simply discard all of the older parts of the blockchain, because you need to be able to verify that every new transaction you encounter references valid outputs created in the past. The vast majority of a Monero transaction is the ring signature and output range proofs. It may be possible to prune these from the blockchain after a certain period ...


6

Mine went from 13gb to 7.6gb for me so yes, the 0.10.0 version is definitely more compact. I run the 64 bit linux version and built the binaries on my machine. The old version was running 0.9.4


6

User /u/blasium reports on Reddit that: FYI: The blockchain went from 17 GB to 8 GB for me The exact decrease may vary depending on your setup (such as OS and filesystem).


5

The blockchain database size is currently 21 GB. Historical evolution is tracked at http://moneroblocks.info/stats/blockchain-growth. This site claims a smaller size, so it might be tracking the "raw" size, rather than the on disk database size (as the database duplicates some data in order to allow faster lookups).


5

The database file is something like 2.5 or 3 times larger than the actual blockchain data. There are a variety of reasons for it: preallocation of space in the file (if your filesystem supports sparse files, this doesn't actually take physical space, otherwise it does), denormalization for performance reasons, internal tables for the database engine's usage. ...


5

The largest size of the next block is limited to 2x the median size of last 100 blocks. Creating a block this large imposes a penalty equal to the block subsidy, so the miners entire revenue would have to come from transactions, thus the transaction fees would have to be at least as large as the block reward to entice the miner. Realistically, a miner ...


5

I understand the only thing limiting people from inserting, for example, a 180MB FLAC encoded recording of The Sign into the tx-extra field in a Monero transaction is the high fees they pay per kb. That's the 2nd limiting thing, really. First, we'd have to somehow get to a block size median of min. 90MB. The dynamic block size and reward penalty make it ...


5

If you were a bank, then I agree with you - clearing all transactions as fast as possible makes the most sense for your customers. After all, you would control all the account information, have plenty of computing power, and would enjoy all the transaction fees that go with them. We don't want centralization, we want as many people as possible to run a full ...


4

This is the blockchain growth (MB) per month since inception: +--------+---------+ | size | month | +--------+---------+ | 15.25 | 2014-04 | | 159.60 | 2014-05 | | 424.98 | 2014-06 | | 202.63 | 2014-07 | | 227.67 | 2014-08 | | 155.52 | 2014-09 | | 102.11 | 2014-10 | | 83.77 | 2014-11 | | 103.33 | 2014-12 | | 74.76 | 2015-01 | | 71.97 | 2015-02 | | ...


4

Two main reasons why this can't happen: The block size can't grow from 60KB to 180MB abruptly, it has to be progressive (a new block can't be larger than twice the median size of the last 100 blocks) The fee for that transaction needs to be more than the block size penalty incurred by miners, which wouldn't be the case for such a large block: miners would ...


4

I don't think so as the increase in transaction size is proportional to the amount of privacy the user desires, IOW, if you want better privacy, you still need to pay for it. Any increase in transaction size will naturally increase the fees one will pay, and that miners are willing to accept. There's no tragedy of the commons where people pay the same ...


4

You could try chainradar.com, which may or may not be a trustworthy source. But the real answer, and only thing relevant here, is that Monero does not put the entire blockchain into memory, and the rest of the question is therefore mostly beyond the scope of this SE. The question doesn't apply to Monero but might apply to other cryptonote-based coins that ...


4

Pruning the blockchain means removing some data from it, like old transaction signatures and range proofs. For example, your Monero daemon could store an incomplete version of all the blocks older than one week (no signatures, no range proofs) to save some space, and it would still have all the info (inputs, outputs) allowing a wallet to check its balance. ...


3

The blocksize can automatically adjust over the course of time by the miners including more or less transactions than what has recently been the norm however they have to pay a penalty fee if they increase it by more than a certain distance from the median of recent blocks. I guess the idea is to let the market decide what the blocksize should be rather than ...


3

The block weight is indeed the sum of the transactions it contains (including the coinbase transaction). For most transactions, the weight is the size in bytes. For transactions with more than 2 outputs and bulletproofs, weight is adjusted up, see details in get_transaction_weight in src/cryptonote_basic/cryptonote_format_utils.cpp. You do not normally need ...


2

Blockchain size: Blockchain size on hard drive? By default - yes. Although, you can use remote nodes to sync the wallet: What is a remote node? How much information is passed from the daemon to simplewallet when scanning for a wallet's transactions? There's a way without having to download the blockchain but it comes with a trade-off: you need to ...


2

Since the penalty function is inherited from CryptoNote, we must look at the whitepaper for the "original thought" on the subject. A miner still has the ability to stuff a block full of his own zero-fee transactions up to its maximum size 2 * M_b. Even though only the majority of miners can shift the median value, there is still a possibility to bloat the ...


2

We say Monero is scaleable because there nothing in the protocol level preventing Monero from accepting a very large number of transactions. There is no coded limit on the block size. The processing capacity for nodes is based on a few things: Frequency of transactions Size of the blockchain Regarding the first, transactions can not happen faster than ...


2

Running any program inside a VM comes with a slight-to-moderate hit in performance. It really depends on how you set things up both on the host computer and inside the client OS. You say you want to use VirtualBox so I am going to assume you're going to run and configure the VM via the GUI and not do anything special with it. If you're going to run Ubuntu (...


2

Looking at https://moneroblocks.info/stats, the current growth rate looks to be about 400 MB per month, average over the past last half year. This is about 5 GB per year. This means reaching 100 GB (+30 GB) in 6 years, and 200 GB (+130 GB) in 26 years. This is assuming no increase nor decrease in usage, nor in software improvements (transactions are likely ...


Only top voted, non community-wiki answers of a minimum length are eligible