Most non coinbase Monero transactions are currently around 2,000 bytes (but with significant variation) which is somewhere in the neighborhood of 8 times larger than most Bitcoin non coinbase transactions.
The reason why RingCT should help eliminate the need for extremely large Monero transactions is that RIngCT no longer will require the use of outputs of ...
Non coinbase transactions can start at a couple hundred bytes, and can go up in size a lot if they have a large number of inputs.
The main factors driving up size is the number of inputs and mixin. When sending a large amount, if the sending wallet only has small inputs, it will have to include a lot of them in the transaction (and possibly even send ...
Full nodes cannot prune the range proofs entirely in a trustless manner. SPV nodes and those relying on checkpoints could benefit in the manner described by
Monero Research Labs below:
While the range proofs are large, using a transaction hashing scheme that signs
the transaction "prefix" (both input indices and outputs) and stores the range
Theoretically, there is nothing preventing this. Practically, there is no code to do this yet, however.
There are a few things that can be pruned. Ring signatures, for instance. Once RingCT is in, range signatures can also be pruned. These take a large portion of the transaction data. Note that Aeon, a fork of Monero, does implement some kind of pruning ...
Pruning from scratch or enable pruning going forward
Pruning from scratch or enabling pruning going forward is fairly straight forward. It is done as follows:
Go to the Settings page and switch to the Node tab.
Make sure Local node is selected.
Add the --prune-blockchain flag to the Daemon startup flags box.
Restart (by clicking on the x (right top) and ...
The paper is interesting and Monero was mentioned at one point:
OWAS had the good idea to combine the transactions in blocks. Imagine that we
can combine across blocks (perhaps with some glue data) so that when the outputs
are created and destroyed, it is the same as if they never existed. Then, to
validate the entire chain, users only need to know ...
The signatures, whether pre or post RingCT, are not needed for a node's own use after they are verified. However, pruning them means the node is unable to supply the full chain to peers, since those peers would need the signature so they can check them too. Allowing pruning in that way means the set of full "archival" nodes would be smaller than it otherwise ...
Quoting relevant part of the commit message:
There are three ways to prune a blockchain:
run monerod with --prune-blockchain
run "prune_blockchain" in the monerod console
run the monero-blockchain-prune utility
The first two will prune in place. Due to how LMDB works, this will
not reduce the blockchain size on disk. Instead, it will ...
These questions are answered by the pruning FAQ, which was posted by core-developer smooth, who is also a core-team member of Monero.
Q: What is pruning?
A: Pruning refers to removing unnecessary information from the blockchain once it is no longer needed.
Q: What are the advantages?
A: Pruning reduces the amount of storage needed for the ...
The current Monero median block size (last 1,000 blocks) is 286 bytes. The median transaction size is slightly less because some block include multiple transactions. The current median BTC transaction size is 260 bytes.
Monero median (not mean) block sizes are important since they influence the ...
By definition pruning branches cannot be considered full nodes because they are missing the data that has been pruned. Pruning branches are not full nodes according to the definition of CONOP.
This explanation explains why full nodes (in addition to pruning branches) are necessary.
Pruning data makes a node unable to supply the pruned data to other ...
It helps to better understand first how pruning works.
When pruning, your blockchain gets split into stripes. These start from a random point chosen when you first decide to prune. If you are pruning, only your pruning stripes get pruned (non-essential data gets removed after validation). The non-pruning stripes will have full data. So every node that ...
This would be possible only after every single one is spent. Given the extremely high likelihood that at least one output is lost (private key lost), it seems that it's unlikely to yield any benefit, though it seems it could be done per denominations, and there could plausibly be some denominations where all could be spent. Unfortunately, those are likely ...
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.
Why only 2/3 of the blockchain data can be pruned?
Think about it like this: If you pruned 100% you would have nothing, your node, and wallet connected to your node, wouldn't be able to do anything. So how much do we actually need to keep to still be usable? Well, once we've verified every transaction, we no longer need the signatures, so they can be ...
Do I have to backup the entire lmdb/ directory or just lmdb/data.mdb?
You may as well backup your whole ~/.bitmonero folder, to keep your config, logs and blockchain.
What is in ~/.bitmonero/lock.mdb?
It's just a lock file used to control concurrent access. You're presumably going to shut down Monero before backing up so whether you copy this file or not ...
In Monero, it is impossible to distinguish between spent and unspent outputs. Therefore no one could create a new blockchain with just the unspent outputs from the current blockchain, because the unspent outputs are unknowable.
As the post indicated the pruning branch is still considered experimental. Therefore it resides in another GitHub repository found here. I have included a summary of the instructions smooth provided upon releasing the pruning branch which should still be accurate today
Clone from GitHub:
git clone https://github.com/iamsmooth/aeon light-node
After pruning the monero blockchain, can I copy this pruned blockchain from the .bitmonero folder to another computer and just start syncing from there?
What are some disadvantages of pruning the blockchain...
This is a good question. Let's first take a step back and understand what happens with pruning. When your domain is fetching and validating ...
monero-blockchain-prune-known-spent-data (an older tool) prunes specific pre-RCT known spent outputs and monero-blockchain-prune prunes the whole blockchain (a newer tool). You only need run the newer tool.
Technically, it is possible to decrease the size further.
However, there are diminishing returns, pros and cons of futher pruning (currently, a pruned node can still serve some of the blockchain, by design), pros and cons of ease and speed of accessing data (some data is kept duplicated in the database for lookup purposes), etc.
You bring a comparison with ...
From moneromoo on Github:
That's from nodes that don't understand pruning are asking you for data that you pruned. It's OK.
For the lockable memory issue, you can increase the amount of lockable memory using the command the message is giving you.
Ended up deleting the whole blockchain (94GB) and resynching with the --prune-blockchain start up flag for Daemon set in the miners wallet gui. This took over 5 days but I now have a 29GB blockchain a saving of 65GB!
Simply explained from jtgrassie's answer, you download the blockchain first, then prune it.
This is now done automatically. When you run a node, it will be pruned and you don't have to do anything else.
In theory, yes. In practice, this might be a bit harder, depending on how the data is laid out in the on-disk blockchain database. Typically, for access speed, data is laid out in a fixed size vector, like this:
A B C D
Now if you want to prune C, you end up with
A B _ D
The space used by C is now unused, but you may not necessarily be able to reclaim ...