Block Pruning with UTXO Aggregation
Taegyu Song∗ , Kazuyuki Shudo∗†∗ Tokyo Institute of Technology, Tokyo, Japan† Kyoto University, Kyoto, Japan

Abstract—The ledger of a blockchain is designed to be an
append-only data structure, which means that its size only
increases. Therefore, to run a node, it is a burden to the nodeoperator to store the entire blockchain ledger. We propose a new
method, UTXO aggregation, to reduce the high occupancy ofstorage. In this method, UTXOs are periodically merged, and a
special block including all merged UTXOs is generated. Unlike
Bitcoin’s block ﬁle pruning, this method can allow other nodes
to bootstrap and does not require a separate database that stores
only UTXOs. This method also has the effect of reducing UTXOs
with low economic value. By applying this method to Bitcoin, thestorage occupancy of running a node can be immediately reduced
to approximately 1/100, and an economic effect of up to 14120
BTC can be expected.
Index Terms—blockchain, block pruning, Bitcoin, storage occupancy

I. I NTRODUCTION
Blockchain technology distributes, preserves, and manages
data of blocks connected like a chain by hash values bycopying them to multiple computers around the world in peerto-peer protocols. A block contains several online transaction
records. In other words, the blockchain is a management
technology for a vast distributed ledger that contains alltransactions. The blockchain has the following characteristics
and problems.
The blockchain assumes a large number of users, and its
ledger contains all valid transactions, so a large storage spaceis required to operate a node. The ledger’s size continues toincrease because it has an append-only data structure.
In addition, metadata of the ledger and data related to node
running also occupy storage. For example, Bitcoin Core is an
implementation of Bitcoin and its database system [1], and theinternal layout of UTXO set [2] was changed to query data
efﬁciently and bootstrap new nodes.
The node sizes of Bitcoin and Ethereum [3], which are
representative blockchains, exceed 383 GB and 1146 GB,
respectively. Fig. 1 shows how much size the Bitcoin andEthereum (Geth) nodes occupy on local storage, and thegrowth rate of their size is increasing.
In major blockchains, nodes basically store the entire ledger,
and the fact that the size of the ledger has grown too large isa burden for many node operators. As the storage occupancyof the running node increases, it becomes difﬁcult to increase
the number of node operators. This hinders decentralization of
the blockchain.
The blockchain community has suggested various methods
to solve this storage size problem. There are methods suchas the introduction of sharding, which groups blockchain

Fig. 1. Storage occupancy of Bitcoin and Ethereum (Geth) nodes.

participants and stores only the ledger of some participants,
the proposal of a node type that maintains only a minimal
structure for running nodes, and placing a trusted databaseoutside the blockchain network. As an example of a nodetype that maintains only a minimal structure, Bitcoin’s lightnode [4] does not store the ledger but outsources the validationof blocks and transactions to other nodes and uses SPV [5] tomanage the wallet locally.
Bitcoin introduced block ﬁle pruning [6], which removes theraw binary data of blocks in the past to alleviate the storage
size problem, but it contains other problems. A node withblock ﬁle pruning cannot help other nodes bootstrap. There isa concern that the node cannot inquire about the block data
referenced by some UTXOs and that the node is forced tomaintain a separate database storing UTXOs. In this paper,
we propose UTXO aggregation, a method that overcomes thelimitations of Bitcoin’s block ﬁle pruning.
This proposal was devised under the inﬂuence of the periodoriented settlement system that is frequently used in practice.
UTXOs are regularly merged on a user basis, and a special
block containing all merged UTXOs, called the aggregation
block, is generated and added to the blockchain. This method
not only reduces storage occupancy but also has the effect of
reducing the number of UTXOs with low economic value.
This paper is organized as follows: In Section 2, we explain the background of Bitcoin. In Section 3, we introduce
Bitcoin’s block ﬁle pruning and related works. In Section 4, theproposed method is discussed. In Section 5, we describe theProc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

requirements for introducing the proposed method to Bitcoin.
In Section 6, experiments in Bitcoin of the proposed method
and the results are described. In Section 7, we describe theconclusion of this paper.
II. P RELIMINARY
This section describes the data storage and transaction
validation of Bitcoin Core, which is the implementation of
Bitcoin.
A. Bitcoin’s data storage
Bitcoin Core stores the following four types of data or
databases in local storage:• blocks/blk*.dat• blocks/index/*• blocks/chainstate/*• blocks/rev*.dat
blocks/blk*.dat is block data contained in the Bitcoin
ledger and is dumped into storage as raw binary data. These
data are used to rescan to detect missing transactions fromthe wallet, to reorganize the chain when a fork occurs andto provide block data to other nodes. blocks/index/*
stores metadata for all blocks and the location of block
data on storage and is implemented as a key-value store,
LevelDB [7]. chainstate/* stores UTXOs and metadata
about transactions referenced by UTXO and is implemented
as a key-value store, LevelDB, such as blocks/index/*.
This database enables nodes to validate new blocks and transactions without scanning the blockchain ledger. If the node
does not maintain databases such as blocks/index/* andchainstate/*, high costs are incurred for data validationand inquiry. In addition, blocks/rev*.dat is undo datafor blocks/blk*.dat and is used when chain reorganization is needed.
B. Bitcoin’s script and validation
For a transaction to be generated in the Bitcoin networkand contained in the blockchain, it must be validated bynodes including miners. Validation is the process of checking
whether a transaction satisﬁes some rules deﬁned by the
Bitcoin network. The following shows some of the rules ofvalidation:• whether the syntax and data structure of the transaction
are correct• whether the reference output exists and is not consumed
for each input• whether the amount of inputs is greater than the amountof outputs• whether the scriptSig of each input corresponds
correctly to the scriptPubkey of the reference output
Here, scriptSig is a signature for scriptPubkey,
which is a script used to prove ownership of a UTXO andconsume it. The script uses the data structure of the stack andreturns a boolean value through PUSH and POP operations. If
TRUE is returned as a result of executing the script, ownershipof the UTXO is validated. For example, scriptPubkey of pay

to script hash (P2SH) [8], one of the Bitcoin scripts, is OP
HASH160 <redeemScriptHash> OP EQUAL, and scriptSig
is [<sig>...<sig>] <redeemScript>. OP CHECKMULTISIG
included in <redeemScript> checks whether the number ofsignatures required to consume the UTXO is included in thescript and signatures are valid and returns TRUE or FALSE
as a result. In other words, validation of a new transactionis the process of checking the inputs of the transaction andreference output of each input from chainstate/*, thedatabase UTXO set, and executing the script included in the
input and output.
C. Bitcoin’s block size
Most of the components of a Bitcoin block have a ﬁxed
size. A block consists of the block size (4 bytes), header (80bytes), number of transactions (1 - 9 bytes), and transactions.
The block header consists of the version of Bitcoin (4 bytes),hash value of the previous block (32 bytes), Merkle hash value(32 bytes), timestamp (4 bytes), PoW difﬁculty (4 bytes), andnonce (4 bytes). A transaction consists of overhead, input,
and output. Overhead is a transaction’s metadata and consistsof Bitcoin version (4 bytes), LockTime (4 bytes), SegWit
MarkerFlag (0.5 bytes), the number of inputs (1 - 9 bytes),
and the number of outputs (1 - 9 bytes). Input consists of thehash value of the reference transaction (32 bytes), the positionof the UTXO on the reference transaction (4 bytes), the lengthof scriptSig (0.5 bytes) and scriptSig of the UTXO, andnSequence (1 - 9 bytes). The output consists of the amount (8bytes), length of scriptPubkey (1 - 9 bytes) and scriptPubkey.
Then, the block’s size is determined by the transactions andscripts included in the block.
III. R ELATED WORKThe Bitcoin community has introduced block ﬁle pruning [6] in its implementation, Bitcoin Core. Block ﬁle pruning
is a method in which a node removes data that are not related
to the validation of a transaction from storage without maintaining it. This includes the past block data, which are the raw
binary data stored in the local storage, blocks/blk*.datand block/rev*.dat. These raw binary data are used only
to relay blocks to other nodes, reorganize the blockchain,inquire into past data, and rescan the Bitcoin wallet. Therefore,
a node with block ﬁle pruning can remove the rest of the block
data, leaving only 288 or more of the most recent block datafor blockchain reorganization.
Block ﬁle pruning, a method of removing raw binary datafrom local storage, contains several problems. One problem isthat a node with block ﬁle pruning cannot help other nodes
bootstrap. Since a node with block ﬁle pruning does not store
past block data in local storage, it cannot provide block data
to other nodes. If all nodes in the Bitcoin network execute
block ﬁle pruning, it becomes impossible for new nodes toparticipate in the Bitcoin network. Bitcoin’s assumed-valid
blocks [9] allow new nodes to bootstrap by starting validationfrom a relatively recent block rather than the genesis block but
still require nodes to store all block data. Another problem isProc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

that block pruning forces the node to store a separate databasecalled the UTXO set that stores only UTXOs for validationof new transactions because block data referenced by someUTXOs can be removed from local storage. The fact that block
data referenced by UTXOs are removed from local storage
may cause inconvenience depending on the user’s purpose,such as ﬁnding referenced block data for new transaction
creation or analyzing past data.
As described in prior studies, a snapshot that proves that the
database UTXO set stored by the node is valid is generated
periodically and included in the blockchain so that the nodethat has removed the old block data makes the new nodebuild the UTXO set. In other words, the snapshot enables
a new node to bootstrap with block ﬁle pruning. However,it still forces the node to maintain a separate database suchas the UTXO set, and there is a concern that the block data
referenced by the UTXO may not be provided.
Palm et al. [10] proposed block pruning in a permissioned
blockchain. In this proposal, only a selected group stores theentire blockchain ledger, and the other groups store only datasuch as transactions related to them. Since this proposal has
security and reliability issues, it is difﬁcult to apply to publicblockchains.
In some blockchains, new methods of pruning have been
proposed, such as efﬁciently tracking and storing the statusof accounts included in the blockchain network. Bruce etal. [11] and Poelstra et al. [12] adopted the method of replacing
Bitcoin’s UTXO set with an account tree and then adding thedata of this tree to the block. However, in these proposals,
the node does not check the availability of the data needed tocompute and build the account tree.
In coinPrune [13], miners periodically generate snapshots ofthe blockchain state, and the snapshots are veriﬁed multiple
times by miners throughout the network. In this proposal,
snapshots veriﬁed sufﬁciently are adopted from the blockchain
network, and each node is able to remove blocks prior to thesnapshot. This proposal can be introduced to Bitcoin without ahard fork, and a node that newly enters the network can build a
UTXO set from a snapshot received from a neighboring peer.
However, there is a possibility that a DOS attack may occur
while the miner veriﬁes the snapshot.
In addition, securePrune [14] is a proposal of pruning
based on the RSA accumulator [15] of the UTXO set and
the PoW-based consensus algorithm [5]. In this proposal, an
accumulator and NI-PoE [16] are added to the block to verify
the validity of the blockchain state. A node newly entering the
network can verify whether the UTXO set received from theneighboring node is valid through the accumulator includedin the block. However, this proposal has the problem that it is
difﬁcult to introduce to an existing blockchain.
In Ethereum, the state of the accounts of the blockchain is
maintained as a Merkle Patricia tree, and this tree is updated
for each block. Ethereum’s node stores all the history of the
updated Merkle tree in consideration of the reorganization of
the blockchain. The history of such a Merkle tree occupies
a large capacity in local storage. Snap sync [17], which wasintroduced in Geth, one of the implementations of Ethereum,
generates a snapshot composed of leaf nodes of the state tree,
making it possible to build a Merkle Patricia tree. By snap
sync, the node of Geth can remove the past history of thestate tree from local storage. Snap sync has greatly reduced
the size of the past history occupied in the local storage andthe synchronization time of the new node.
IV. A PPROACH
In this section, we propose UTXO aggregation and describe the necessary conditions for introducing this method
to blockchain.
A. Necessary conditions
This proposal can be incorporated into a UTXO-based
blockchain, and there are necessary conditions for its introduction. It allows a third party other than the owner of the UTXO
to consume the UTXO for a limited purpose. To consume
the UTXO in the UTXO-based blockchain, an appropriate
private key is required for the UTXO, and ownership of theUTXO must be proven by executing the blockchain script. For
the introduction of this proposal, there is a condition in theblockchain script, which is that when a user’s address owns
two or more UTXOs, it must be possible to merge UTXOs
into one new UTXO without the owner’s approval. This does
not mean that UTXOs can be consumed and remitted to otheraddresses without address approval but rather that UTXOs
owned by an address are merged to generate one new UTXO
owned by the same address. In other words, the necessary
script should operate as if the balances divided into several
accounts were collected in one account without the approvalof the depositor.
B. UTXO aggregation
In UTXO aggregation as proposed in this paper, all UTXOs
of each user are periodically merged into one. A UTXO
merging in the proposal means creating a transaction with
two or more UTXOs owned by the address as input for eachaddress participating in the blockchain network and one new
UTXO owned by the same address as the output. Transactions
generated through merging are periodically aggregated in a
special block called the aggregation block. The aggregation
block is added to the blockchain. In this proposal, there isa period for creating an aggregation block and a period for
UTXO merging, and the period for creating an aggregation
block is longer than the period for merging. We call the periodof creating an aggregation block the epoch. At least once at thetime when the epoch changes, UTXOs are merged on a user
basis, and an aggregation block containing all merged UTXOs
is generated. The aggregation block generated for each epoch
intensively shows all UTXOs that exist in the blockchain
network. Depending on the purpose of the blockchain, the unitof epoch is set as 1 week, 1 month, or 1 year.
Fig. 2 gives an overview of the proposal. The ledger ofthe blockchain is divided at regular intervals. Ledger divisionat regular intervals indicates a speciﬁc block, which is theProc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

Fig. 3. Bootstrap process of a newly participating node in the network.

Fig. 2. Architecture of the proposal method and UTXO aggregation outline.

point at which the node operator starts to store the ledger
in the local storage. This assists multiple node operators inconsistently storing the same section of the ledger. Even if thenode operator removes the block data before the aggregation
block from the local storage, there is no problem in the running
node, and the operator’s node can store the ledger for theperiod of interest only. For example, it is possible to simply
address the node operator’s request, such as requiring data for
only the last year or a speciﬁc period in the past.

received from the neighboring node. Since the Bitcoin network
does not provide a snapshot, a node with block ﬁle pruning
cannot allow bootstrapping in new nodes. However, because
the aggregation block in the proposal contains all UTXOs at
one point in time, this block can serve as a snapshot.
The bootstrapping process in the proposal can be divided
into three steps; Fig. 3 shows the outline. First, the bootstrap
node ﬁnds and obtains the aggregation block in which the nodewants to start storing blocks from the blockchain network.
Then, the node obtains the headerchain for the period before
the aggregation block. Finally, the node obtains the block andvalidates it for the period after the aggregation block.

C. Data integrity and UTXO set

E. Policy on merging

In the proposal, since all UTXOs contained in the previous
epoch are included in the input of the aggregation block andconsumed, all UTXOs must exist in the block of the last epoch.
This means that the data to be referenced when a user makesa new transaction must exist in the last epoch. This feature isdifferent from Bitcoin. In Bitcoin’s block ﬁle pruning, whether
the transaction referred to by a UTXO exists in local storage isdetermined by how many blocks the node stores. Dependingon the node, the transaction data referenced by the UTXO
may have already been removed from local storage. For thisreason, in Bitcoin’s block ﬁle pruning, if a node does not
maintain the UTXO set, which is a separate database that
stores only UTXOs, this node is not able to validate new
blocks or transactions. However, in the proposal, since all
UTXOs and data referenced by UTXOs exist in local storage,
blocks and data can be validated even if the node does not
maintain a separate database.

In the proposal of this paper, how to make an aggregation
block is different according to the timing of UTXO merging.
UTXO merging occurs on every block or once an epoch. If
it is assumed that merging occurs once in an epoch, merging
occurs when the epoch changes, and the result is reﬂected in
the aggregation block. At this time, the aggregation block mustbe generated by the miner, and this block must be propagatedthrough the blockchain network. If merging occurs on every
block, since all nodes store the same data in local storage,
each node can generate an aggregation block by itself.

D. Bootstrap
For a node that has removed old block data from local
storage to be able to validate new data, the node must be able
to know all UTXOs without old data. Therefore, in Bitcoin,
the node stores the UTXO set in local storage. For a node withblock ﬁle pruning to enable bootstrapping of other nodes, thenode must be able to prove that the UTXO set stored in thelocal storage is correct. Therefore, in related studies, a method
such as a node creating a snapshot, data that prove that UTXO
set at a speciﬁc point in time is correct, and putting it in a blockis used. The bootstrap node can check whether the UTXO
set is correct by comparing the snapshot with the UTXO set

V. I NTRODUCTION TO B ITCOIN
There are necessary conditions to introduce UTXO aggregation described in Section IV to Bitcoin. It shares the right toconsume the UTXO to the blockchain network. To introduce
this method to Bitcoin, a new script must be introduced, andall users must use the new script-based address. We introduce
pay to witness aggregation script hash (P2WASH), a scriptthat is based on Bitcoin script pay to witness script hash
(P2WSH) [18] and satisﬁes the requirements.
Fig. 4 shows an overview of Bitcoin’s scripts P2SH andP2WSH and the new script P2WASH. The scriptPubkey ofm-of-n P2WASH that contains n public key and requires
m signature out of n for UTXO consumption is OP
HASH160 <redemScriptHash> OP EQUAL. The scriptSig of
m-of-n P2WASH is [<sig>...<sig>] <redemScript>, where<redemScript> is OP 0 OR M [<pubkey>...<pubkey>]
OP AGG CHECKMULTISIG. P2SH and P2WSH return
TRUE or FALSE by OP CHECKMULTISIG, but P2WASH
returns SEND, AGG, FALSE according to the number of valid

Proc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

Fig. 4. Comparison of the structure of Bitcoin’s scripts and the new script P2WASH.

<sig>s contained in scriptSig by OP AGG CHECKMULTISIG. If scriptSig contains m valid <sig>, the script
returns SEND, and remittance to another address is possible,
similar to the existing script. When scriptSig does notcontain <sig> and the address of the UTXO owner andthe remittance address are the same, the script returns AGG,
and UTXO merging is possible. Otherwise, the script returns
FALSE, and nothing happens. That is, the requirement of the
proposal is satisﬁed by the AGG returned by P2WASH, andthe number of UTXOs owned by each address periodically
becomes one. If P2WASH is introduced, the proposed method
can be introduced to Bitcoin.
All Bitcoin scripts correspond to P2WASH according to thenumber of public keys and signatures contained in
the script. For example, scripts such as P2PK, P2PKH, andP2WPKH containing one public key and signaturecorrespond to x-of-n P2WASH, and scripts such as x-of-nP2MS, P2SH, and P2WSH containing n public keys andsignatures correspond to x-of-n P2WASH.
VI. E XPERIMENTIn this section, on the premise of the necessary conditions
described in Section V, we examine how effective the proposed method is when incorporated into Bitcoin. To determine
the effectiveness of the method, we use Bitcoin data and makesome assumptions to calculate and predict changes in items
related to storage size.
A. Data and assumptions
The three types of data collected for the experiment are as
follows. We use the data of blocks and transactions for one
year, and the numbers are 52635 and 99162585, respectively.
The script type that occurs during the period is analyzed.
We use the data “addresses with nonzero balance” from
Glassnode [19]. We use the UTXO data by analyzing UTXO
set as of November 2021 using STATUS [20], which Delgado
et al. [21] used as an analysis tool for the UTXO set.
We make some assumptions, as we cannot gather all thedata to accurately predict the effect on Bitcoin. We assume
that the ratio of script types contained in the transaction, therate of increase of addresses with nonzero balance, and theratio of input and output of the transaction does not change.
We consider only four script types, P2SH, P2PKH, P2WPKH,
and P2WSH, occupying approximately 99 % of scripts and

TABLE IC OMPARISON OF SCRIPT SIZE AND V S IZE BY SCRIPT TYPE .
size [byte]

P2PKH
P2WPKHP2SH (1-of-2)
P2SH (2-of-3)
P2WSH (1-of-2)
P2WSH (2-of-3)
P2WASH (1-of-1)
P2WASH (1-of-2)
P2WASH (2-of-3)

vSize [vbyte]

scriptSig

scriptPubkey

scriptSig

scriptPubkey

107
107
147
254
147
254
113
147
254

25
20
23
23
34
34
34
34
34

428
107
588
1016
147
254
113
147
254

100
80
92
92
136
136
136
136
136

ignoring other script types. We also assume that half of P2SH
and P2WSH are 1-of-2 and the rest are 2-of-3. We merge
UTXOs once in the epoch to simplify the experiment.
B. Comparison of blocks
The size of the script depends on each type, and Table I
shows the details. The average numbers of transactions, inputs,
and outputs included in a block are 1884, 5754, and 5976,
respectively. The ratios of P2SH, P2PKH, P2WPKH, andP2WSH are 36.2 %, 20.1 %, 40.9 %, and 1.8 %, respectively. Based on the given data and the contents described in
Subsection II-C, the size of the block can be calculated. The
block sizes before and after the introduction of the method
are 1287333 bytes and 1370050 bytes, respectively, which isan increase of approximately 6.4 %. This is because the sizeof the P2WASH script is larger than that of the P2PKH and
P2WPKH scripts.
Changes in the vSize of blocks and the number of transactions that can be included in a block are described inAppendix A.
C. Comparison of the UTXO set
Bitcoin’s UTXO set is based on LevelDB, a key-value store.
The key of the UTXO set (version 0.15.0 or later) contains
the data about the hash value and index of the transactionreferenced by each UTXO. The value contains the height ofthe block, whether the transaction is the coinbase, the amount,and the scriptPubkey of each UTXO. That is, the UTXO set
stores information and metadata of UTXOs, and the number

Proc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

Fig. 5. Changes in size on local storage when a node stores a blockchain
ledger of 1 epoch.

of records in the UTXO set is the same as the number of
UTXOs.
If the proposed method is introduced in Bitcoin, the node
is not forced to store the UTXO set, but if it does, the numberof records changes. Subsection IV-E describes the timing andfrequency of UTXO merging, but the change in the number ofrecords differs depending on whether UTXO merging occurs
once per epoch or per block. When merging occurs for eachblock, the number of UTXOs is the same as the number ofaddresses with nonzero balance, and the number of records of
the UTXO set decreases. If merging occurs once in the epoch,
the number of UTXOs is the sum of the number of addresses
with nonzero balance and the number of UTXOs generated inexcess over the epoch. As of December 5, 2021, the numberof addresses with nonzero balance was 39240264.
D. Size of the aggregation block
The structure of the aggregation block is the same asthat of a general block, and its size is determined by the
number of transactions included in the block and inputs andoutputs included in each transaction. The aggregation block’s
input contains existing UTXOs in the previous epoch, andthe number of UTXOs is equal to the difference between thenumber of inputs and outputs in the previous epoch. According
to the collected data, the number of outputs included in theblock is 222 more than the number of inputs on average.
When the epoch unit is 1 month, 6 months, and 1 year, thenumber of excess outputs is 973076, 5838456, and 11676912,
respectively. Only one UTXO of each address is containedin the output of the aggregation block, and the number ofaddresses with nonzero balance is 39240264.
We can calculate the size of the aggregation block basedon the data and assumptions in Subsection VI-A. The size ofthe aggregation block is approximately 2.27 GB (2270892801

Fig. 6. Rate of increase in the size of the blockchain ledger.

bytes) when the epoch unit is 1 month, 3.19 GB (3194555515
bytes) when the epoch unit is 6 months, and approximately
4.31 GB (4309245744 bytes) when the epoch unit is 1 year.
E. Size occupied by the blockchain ledger on local storage
The change in the ledger size of the blockchain on thelocal storage can be predicted by the block size calculated
in Subsection VI-B and the size of the aggregation block
calculated in Subsection VI-D. The size of the ledger increases
by the size of one aggregation block and the size of blocks
generated during the epoch for each epoch.
When the unit of epoch is 1 month, 6 months, and 1 year,
the average number of blocks generated is 4386, 26316, and52632, respectively. When the unit of epoch is 1 month, 6months, and 1 year, the size of the aggregation block is 2.43
GB, 3.19 GB, and 4.31 GB, respectively. When the unit ofepoch is 1 month, 6 months, and 1 year, the increments ofaddresses with nonzero balance are 444139, 2911061, and6314577, respectively. Based on this, we predict the size whenstoring 1 epoch of blockchain in local storage and obtained
the same result as shown in Fig. 5. The size of the blockchain
when the proposed method is not introduced is 380 GB, andthe sizes are approximately 0.6 - 2.0 %, 0.8 - 9.5 %, and 1.1- 18.9 % according to the epoch unit after the introduction of
the proposed method.
F. Rate of increase in the size of the blockchain ledger
In the proposal, unlike before, an aggregation block is
additionally generated on the blockchain ledger, so its size
increases faster. Fig. 6 shows the rate of increase before
and after the introduction of the proposed method. When the
proposed method is not introduced, the size increase rate of theledger is approximately 5.6 GB/month. The rate of increase in
the size of the ledger after introducing the proposed method
is 8.4 GB/month, 6.2 GB/month, 6.0 GB/month when theProc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

Fig. 7. Distribution of the number, total amount, and script sizes of UTXOs by the UTXO value rate.

epoch unit is 1 month, 6 months, and 1 year, respectively,
corresponding to an increase of approximately 50 %, 10 %,and 6 % from before the introduction.
G. Economic effects of UTXO merging
In the proposed method, since each user periodically possesses only one UTXO, the total number of UTXOs decreases,
and the average value of each UTXO increases. The value
rate of a UTXO can be expressed as a value obtained by
dividing the amount included in the UTXO by the script size
included in the UTXO. The transaction fee is proportional to
the transaction size and the congestion level of the transactionpool, and the transaction fee rate can be expressed as a value
obtained by dividing the transaction fee by the transaction
size. If the value rate of the UTXO is low or the fee rateof a transaction is high, it is difﬁcult to consume the UTXO.
In other words, it can be said that the economic value of a
UTXO with a low value rate is small. Delgado et al. [21]classiﬁed UTXOs with a small value rate into dust UTXOs
and nonproﬁtable UTXOs. They classiﬁed UTXOs where thetransaction fee rate exceeds 1/3 of the UTXO’s value rate
as dust UTXOs, and UTXOs where the transaction fee rate
exceeds the UTXO’s value rate were classiﬁed as nonproﬁtable
UTXOs.
Fig. 7 shows the distribution of the number, total amount,and script size of UTXOs based on the UTXO value rate.
According to the distribution, the total amount of UTXOs witha value rate less than 150 sat./byte occupies only 0.012 % of
the total Bitcoin amount, but their number occupies 49 %, andtheir script sizes occupy 50 % of the total.
According to statoshi [22], the maximum fee rates for thelast month, one year, and the previous period are approximately 20, 270, 1000 sat./byte, respectively. Fig. 8 shows the
cumulative amount of dust UTXO and nonproﬁtable UTXO
according to the fee rate. When the fee rate is 20 sat./byte, thetotal amount of dust UTXOs and nonproﬁtable UTXOs is 36
and 30 BTC, respectively. When the fee rate is 270 sat./byte,
the total amount of dust UTXOs and nonproﬁtable UTXOs is3620 and 2540 BTC, respectively. When the fee rate is 1000
sat./byte, the total amount of dust UTXOs and nonproﬁtable
UTXOs is 14120 and 8620 BTC, respectively.

Fig. 8. Cumulative distribution of dust/nonproﬁtable UTXOs by the fee rate.

VII. C ONCLUSION
In this proposal, we proposed UTXO aggregation, which
can be introduced into a UTXO-based blockchain. Blockpruning and related research proposed in some blockchains, including Bitcoin, have the problem that nodes cannot bootstrap.
There is a possibility that the block referenced by a UTXO or
the UTXO has been removed from the local storage, forcing
the node to maintain a separate database that stores only
UTXOs. An aggregation block that is periodically generated
in the proposed method serves as a snapshot of the UTXO
set by allowing the bootstrap node to identify all UTXOs.
After the aggregation block is generated, there is no UTXO
in the period before this block, so the node does not needto maintain a separate database that stores only UTXOs. The
proposed method not only solves the above problems but also
reduces the number of UTXOs with low economic value on
the blockchain network because UTXOs are regularly merged.
For the blockchain to become a sustainable system evenafter a long period of time, it is necessary to reduce theProc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

storage occupancy required to run a node. In the experimentof this paper, using Bitcoin data, the blockchain ledger size
was calculated and compared when the proposed method wasintroduced to Bitcoin. As a result of the experiment, it was
conﬁrmed that although the increase rate of the ledger size issomewhat faster, the size of the ledger stored in the storage
can be signiﬁcantly reduced. Therefore, it can be said that the
proposed method is effective in reducing the running cost of
the node.
To introduce the proposed method, a script that can sharea part of the right to consume UTXOs to the network isneeded, and all users must use this script-based address. We
conclude that the proposed method can be easily introducedin the situation of designing a new blockchain, but consensus
on the network is required to introduce it to the existing
blockchain. If the consensus conﬂicts with the existing rulesof the blockchain, the blockchain must be hard forked, as
occurred with Bitcoin Cash and Bitcoin Gold.
A PPENDIX
A. Changes in block vSize and transaction throughput
In Bitcoin, there is a limit on the size of a block. The
limit was initially 1000000 bytes, but after the introductionof segWit [18], it became 4000000 vbytes. segWit puts the
script’s signature in the witness space, not the scriptSig space.
In calculating the vSize of a block, the vSize is quadrupled
except for the signature part of the segWit-based script. In
other words, if a segWit-based script is used, more transactions
can be contained in a block, and the use rate of the segWitbased script has recently increased.
The virtual size of the block was 3787198 vbytes before
applying the proposed method, but it became 1973890 vbytes
after application, which is an approximately 47.9 % decrease.
Therefore, the actual size of the block increases somewhat,
but there is room for vSize. A larger number of transactions
can be contained in a block.

[10] E. Palm, O. Schelén, and U. Bodin, “Selective blockchain transaction
pruning and state derivability,” in 2018 Crypto Valley Conference on
Blockchain Technology (CVCBT). IEEE, 2018, pp. 31–40.
[11] J. Bruce, “The mini-blockchain scheme,” White paper, 2014.
[12] A. Poelstra, “Mimblewimble,” 2016.
[13] R. Matzutt, B. Kalde, J. Pennekamp, A. Drichel, M. Henze, and
K. Wehrle, “How to securely prune bitcoin s blockchain,” in 2020
IFIP Networking Conference (Networking). IEEE, 2020, pp. 298–306.
[14] B. S. Reddy, “secureprune: Secure block pruning in utxo based
blockchains using accumulators,” in 2021 International Conference on
COMmunication Systems & NETworkS (COMSNETS). IEEE, 2021, pp.
174–178.
[15] N. Barić and B. Pﬁtzmann, “Collision-free accumulators and fail-stop
signature schemes without trees,” in International conference on thetheory and applications of cryptographic techniques. Springer, 1997,
pp. 480–494.
[16] D. Boneh, B. Bünz, and B. Fisch, “Batching techniques for accumulators with applications to iops and stateless blockchains,” in Annual
International Cryptology Conference. Springer, 2019, pp. 561–586.
[17] “Ethereum
foundation,”geth
v1.11.0”,”
https://blog.ethereum.org/2021/03/03/geth-v1-10-0/, accessed: 2021-1216.
[18] “Bitcoin project, ”bitcoin core version 0.13.0 released”,”
https://bitcoin.org/en/release/v0.13.0, accessed: 2021-12-16.
[19] “Glassnode, ”bitcoin: Number of addresses with a non-zero balance”,”
https://studio.glassnode.com/, accessed: 2021-12-16.
[20] S. D. Segura, “Statistical analysis tool for utxo set,”https://github.com/sr-gi/bitcoin tools/tree/v0.2/bitcoin
tools/analysis/status, 2018.
[21] S. Delgado-Segura, C. Pérez-Sola, G. Navarro-Arribas, and J. HerreraJoancomartı́, “Analysis of the bitcoin utxo set,” in International Conference on Financial Cryptography and Data Security. Springer, 2018,
pp. 78–91.
[22] “statoshi.info, ”recommended transaction fee for target conﬁrmation inx blocks”,” https://statoshi.info/, accessed: 2021-12-16.

ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI Grant Number JP21H04872.
R EFERENCES[1] “Bitcoin
project,”bitcoin-qt
version
0.8.0
released”,”
https://bitcoin.org/en/release/v0.8.0, accessed: 2021-12-16.
[2] “Bitcoin project, ”bitcoin core version 0.15.0 released”,”
https://bitcoin.org/en/release/v0.15.0, accessed: 2021-12-16.
[3] G. Wood et al., “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum project yellow paper, vol. 151, no. 2014, pp.
1–32, 2014.
[4] “Bitcoin
project,”lightweightnode”,”
https://en.bitcoin.it/wiki/Lightweight node, accessed: 2021-12-16.
[5] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Decentralized Business Review, p. 21260, 2008.
[6] “Bitcoin project, ”bitcoin core version 0.11.0 released”,”
https://bitcoin.org/en/release/v0.11.0, accessed: 2021-12-16.
[7] Google, “Leveldb,” https://github.com/google/leveldb, 2012.
[8] “Bitcoin project, ”bitcoin core version 0.10.0 released”,”
https://bitcoin.org/en/release/v0.10.0, accessed: 2021-12-16.
[9] “Bitcoin project, ”bitcoin core version 0.14.0 released”,”
https://bitcoin.org/en/release/v0.14.0, accessed: 2021-12-16.

Proc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022