<p>This is not possible with current blocks and transactions, although future improvements may allow us to prune some space from future blocks and transactions.</p>

<p>Let's think through the idea of deleting a transaction for a moment.  Let's say we have two particular transaction in the blockchain:</p>

<blockquote>
  <ol>
  <li>Alice mines 50 bitcoins</li>
  <li>Alice pays Bob 50 bitcoins</li>
  </ol>
</blockquote>

<p>Now we delete Alice's coinbase (mining) transaction:</p>

<blockquote>
  <ol>
  <li>[PURGED]</li>
  <li>Alice pays Bob 50 bitcoins</li>
  </ol>
</blockquote>

<p>Wow!  That looks like 50 bitcoins appeared out of nowhere!</p>

<h2>What if that transaction has lots of proof of work?</h2>

<p>Could you trust the Alice-pays-Bob transaction if it had 50,000 confirmations even though you can't see where those bitcoins came from?  Sure, that like that might be a reasonable trade off of reduced security for increased convenience.</p>

<p>But in order to validate future transactions, nodes don't just need to know who has bitcoins—they also need to know who <em>doesn't have</em> bitcoins.  For example, imagine Bob hasn't spent his 50 bitcoins, so that transaction should be part of the blockchain; yet, when you download the blockchain from Mallory's node, this is what you get:</p>

<blockquote>
  <ol>
  <li>[PURGED]</li>
  <li>[PURGED]</li>
  </ol>
</blockquote>

<p>At some point in the future, Bob goes to spend his 50 bitcoins.  Other nodes who didn't sync from Mallory know Bob has 50 bitcoins, so they accept blocks with that transaction. Your node rejects blocks with that transaction because it doesn't think Bob has 50 bitcoins, permanently forking you off of the consensus blockchain.  This is called <em>consensus failure</em> and it's one of the things we try really hard to avoid in Bitcoin.</p>

<h2>Why not just keep track of amounts and purge the rest?</h2>

<p>One way around this dilemma would be if we could split transactions into different parts:</p>

<ol>
<li>The parts we needed to build the <a href="https://bitcoin.org/en/glossary/unspent-transaction-output" rel="nofollow noreferrer">Unspent Transaction Output (UTXO)</a> set that full nodes use to prove whether or not Bob has 50 bitcoins.</li>
<li>Everything else, such as the large public keys and signatures we use to prove Alice was authorized to spend those 50 bitcoins.</li>
</ol>

<p>Here we encounter an additional problem with transaction pruning, a limitation of the way Nakamoto designed Transaction Identifiers (txids).  Nakamoto's design simply hashes the entire transaction and uses that to form the leaf nodes of the merkle tree whose root node gets included in the block header and secured with proof of work.</p>

<p><a href="https://i.sstatic.net/sYhZf.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/sYhZf.png" alt="txids to merkle tree"></a></p>

<p><em>(Image from <a href="https://21.co/learn/bitcoin-mining" rel="nofollow noreferrer">21.co</a>, CC-By-SA license)</em></p>

<p>Because of this design, in order to verify the UTXO-required data, you also need to download the <em>entire</em> transaction, including its public keys and signatures which constitute about 1/3 to 2/3 of a transaction.</p>

<p>This makes Nakamoto's <a href="https://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">whitepaper</a>-style pruning in Bitcoin right now pretty much impossible.  Happily, some smart people have been working on improving the situation.</p>

<h2>Segregated Witness</h2>

<p><em>...which sounds like some weird law-enforcement term...</em></p>

<p>Blockstream's testnet sidechain, <a href="https://github.com/ElementsProject/elementsproject.github.io" rel="nofollow noreferrer">Elements Alpha</a>, includes a nifty feature called <a href="https://github.com/ElementsProject/elementsproject.github.io#segregated-witness" rel="nofollow noreferrer">segregated witness</a>.  First, some background on witnesses in cryptography:</p>

<p>A witness is the data needed to prove some other data's validity.  This probably derives from contract law, where you often get other people to witness your signature on important documents.  In the case of Bitcoin, the witness to a particular spend being valid is the scriptPubKey of the output being spent and scriptSig of the input that references it in the spending transaction.</p>

<p>In Elements Alpha and the new <a href="https://blockstream.com/2015/10/12/introducing-liquid/" rel="nofollow noreferrer">Liquid mainnet Sidechain</a>, the witness is "segregated" into a different part of the block and is not covered by the txid hash.  That means that nodes who want to reduce their download requirements can skip downloading witnesses for transactions with more than (say) 50,000 confirmations. However, now they can still use the block header merkle root to verify that all of the non-witness data (including the amounts transferred) are correct, and use that to build a correct UTXO set.</p>

<p>I can't find a source right now, but I think I've heard Wuille and Maxwell say that for typical Bitcoin mainnet transactions, this would mean about 1/3 of the transaction data doesn't have to be downloaded by nodes that don't want to validate old signatures.  On Elements Alpha where the witness is larger for transactions that use <a href="https://github.com/ElementsProject/elementsproject.github.io#confidential-transactions" rel="nofollow noreferrer">value blinding</a>, this would mean 2/3 of the data doesn't have to be downloaded.</p>

<p>As a bonus, segregated witness also "completely eliminates all known forms of transaction malleability" (<a href="https://github.com/ElementsProject/elementsproject.github.io#segregated-witness" rel="nofollow noreferrer">Wuille's description</a>).</p>

<h2>When will this appear in Bitcoin?</h2>

<p>You're in luck: just a few days ago, Luke Dashjr <a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011579.html" rel="nofollow noreferrer">presented an idea</a> for how segregated witness can be soft forked onto Bitcoin mainnet.  (Previously, it had been thought that a hard fork would be necessary.)</p>

<p>The payer pays to a scriptPubKey that always returns true but which contains the hash of a redeem script like P2SH does:</p>

<pre><code>&lt;hash_of_redeem_script&gt; OP_TRUE
</code></pre>

<p><em>(I just made that up; I don't know what the real construction will look like.)</em></p>

<p>When the person paid later goes to spend, they provide an empty scriptSig in the transaction itself.  This is valid to old nodes, but upgraded nodes know to look somewhere else in the block for the actual scriptSig.  The witness has been segregated.</p>

<p>For both old nodes and new nodes, they calculate the txid using the empty scriptSig, so the data covered by the merkle root still covers the important value amounts and references.</p>

<p>I don't know exactly how well this compares to the segregated witness in Elements Alpha (does that cover the scriptPubKey as well?), but it does most of the work in a convenient soft forkable construction.</p>

<p>Since this is week-old engineering, it may change a lot or even be found to be unworkable in the coming months, so don't expect to see it in the immediate future—but, long term, do expect to start seeing some new pre-download pruning options appear.</p>

CC BY-SA 3.0
2015-11-04T14:40:56.607Z
2015-11-04T14:40:56.607Z
David A. Harding
<p>Yes, this should be possible. But there is no support for this in bitcoind yet. </p>

<p>Basically, you can run bitcoind with -prune option. In that case it will delete the older blocks and keep only the unspent outputs(which are required for newer tx validation). So theoretically, you can just copy utxo database from an existing node and start downloading from the current block. </p>

<p>Right now there is no decentralized way to build the utxo database, you just have to start downloading from block 0 and build it yourselves. You could for example torrent the whole UTXO DB. I was thinking of a way to relay the UTXO set (like blocks) , but it would be very big (around 1.2GB right now). I am not knowledgeable enough to know how exactly could such a thing be implemented but it looks theoretically plausible to me.</p>

CC BY-SA 3.0
2015-11-04T12:25:19.150Z
Relaying the UTXO would be very foolish, if you trust it anybody can steal from you and fake payments to you. Bitcoin only works when nodes create their own UTXO, which requires all of the transaction history.
Claris
CC BY-SA 3.0
2015-11-04T14:46:36.287Z
I dont think its that foolish . You can checkpoint utxo at a given block and record the hash of utxo to make sure its not changed.  You can proceed downloading blocks from that hash onwards. Starting again from block zero is unnecessary and wastes lots of time and resources
dark knight
CC BY-SA 3.0
2015-11-04T14:50:37.833Z
As a block validity rule UTXO commitments is what you're talking about, and that turns out to be intensive to verify. Some portion of blocks today get no validation before they are mined on top of, indicating the load for that is already too high without adding additional requirements like decompacting and hashing a multi gigabyte UTXO. As something just hard coded into the client well, you're changing the security model somewhat.
Claris
CC BY-SA 3.0
2015-11-04T14:51:33.867Z
You have change to fork the codebase in put the hash in it.  We already have  checkpoints in bitcoin code of known hashes https://bitcointalk.org/index.php?topic=194078.0. Also please note that this question is about creating a new blockchain based currency, so this can be implemented. I am not at all suggesting changing bitcoin code base here.
dark knight
CC BY-SA 3.0
2015-11-04T15:39:38.187Z
Bitcoins checkpoints are not a consensus mechanism, this is commonly confused.
Claris
CC BY-SA 3.0
2015-11-04T12:19:06.850Z
2015-11-04T12:19:06.850Z
dark knight
<p>Is it possible for a blockchain based currency to say, after all outputs have been spent from a transaction to "delete" it from the blockchain, or at least require the nodes not to download it, what methods are there for achieving such a goal ?</p>

<p>The problem I see with pruning is that you still have to first download the entire blockchain from a node and then prune it. I am looking for a method which doesn't require the whole chain ever to be downloaded.</p>

CC BY-SA 3.0
2015-11-03T23:31:58.550Z
related: [Mini-Blockchain proposal: How is the proof-chain secured against injections?](http://bitcoin.stackexchange.com/q/25184/5406), [If more than one coin did the “mini-blockchain” proposal, would that make the weaker coin vulnerable?](http://bitcoin.stackexchange.com/q/24082/5406)
Murch
CC BY-SA 3.0
2015-11-03T23:51:55.073Z
I think the problem you mention with pruning is a problem with the current implementation only, not with the concept of pruning as described in Satoshi's whitepaper. Pruned transactions should be forgotten.
Meni Rosenfeld
CC BY-SA 3.0
2015-11-04T01:39:43.193Z
Worth noting that the descriptions of "pruning" and "spv" in the Satoshi whitepaper are not what is implemented today, and is completely broken respectively. I don't believe it's a good source to be reading about either topic.
Claris
<blockchain><altcoin-development><pruning>
Can a blockchain be created that forgets transactions whose outputs have been spent?
Rich
# Can a blockchain be created that forgets transactions whose outputs have been spent?

(Asked by: username_0 on 2015-11-03)

Is it possible for a blockchain based currency to say, after all outputs have been spent from a transaction to "delete" it from the blockchain, or at least require the nodes not to download it, what methods are there for achieving such a goal ?

The problem I see with pruning is that you still have to first download the entire blockchain from a node and then prune it. I am looking for a method which doesn't require the whole chain ever to be downloaded.

**Tags:** blockchain, altcoin-development, pruning

> **Comments:**
> **username_1**: related: [Mini-Blockchain proposal: How is the proof-chain secured against injections?](http://bitcoin.stackexchange.com/q/25184/5406), [If more than one coin did the “mini-blockchain” proposal, would that make the weaker coin vulnerable?](http://bitcoin.stackexchange.com/q/24082/5406)  
> **username_2**: I think the problem you mention with pruning is a problem with the current implementation only, not with the concept of pruning as described in Satoshi's whitepaper. Pruned transactions should be forgotten.  
> **username_3**: Worth noting that the descriptions of "pruning" and "spv" in the Satoshi whitepaper are not what is implemented today, and is completely broken respectively. I don't believe it's a good source to be reading about either topic.  

---

## 2 answers

### Answer by username_4 on 2015-11-04. Score: 2

This is not possible with current blocks and transactions, although future improvements may allow us to prune some space from future blocks and transactions.

Let's think through the idea of deleting a transaction for a moment. Let's say we have two particular transaction in the blockchain:

> 1. Alice mines 50 bitcoins
> 2. Alice pays Bob 50 bitcoins

Now we delete Alice's coinbase (mining) transaction:

> 1. [PURGED]
> 2. Alice pays Bob 50 bitcoins

Wow! That looks like 50 bitcoins appeared out of nowhere!

## What if that transaction has lots of proof of work?

Could you trust the Alice-pays-Bob transaction if it had 50,000 confirmations even though you can't see where those bitcoins came from? Sure, that like that might be a reasonable trade off of reduced security for increased convenience.

But in order to validate future transactions, nodes don't just need to know who has bitcoins—they also need to know who *doesn't have* bitcoins. For example, imagine Bob hasn't spent his 50 bitcoins, so that transaction should be part of the blockchain; yet, when you download the blockchain from Mallory's node, this is what you get:

> 1. [PURGED]
> 2. [PURGED]

At some point in the future, Bob goes to spend his 50 bitcoins. Other nodes who didn't sync from Mallory know Bob has 50 bitcoins, so they accept blocks with that transaction. Your node rejects blocks with that transaction because it doesn't think Bob has 50 bitcoins, permanently forking you off of the consensus blockchain. This is called *consensus failure* and it's one of the things we try really hard to avoid in Bitcoin.

## Why not just keep track of amounts and purge the rest?

One way around this dilemma would be if we could split transactions into different parts:

1. The parts we needed to build the [Unspent Transaction Output (UTXO)](https://bitcoin.org/en/glossary/unspent-transaction-output) set that full nodes use to prove whether or not Bob has 50 bitcoins.
2. Everything else, such as the large public keys and signatures we use to prove Alice was authorized to spend those 50 bitcoins.

Here we encounter an additional problem with transaction pruning, a limitation of the way Nakamoto designed Transaction Identifiers (txids). Nakamoto's design simply hashes the entire transaction and uses that to form the leaf nodes of the merkle tree whose root node gets included in the block header and secured with proof of work.

[![txids to merkle tree](https://i.sstatic.net/sYhZf.png)](https://i.sstatic.net/sYhZf.png)

*(Image from [21.co](https://21.co/learn/bitcoin-mining), CC-By-SA license)*

Because of this design, in order to verify the UTXO-required data, you also need to download the *entire* transaction, including its public keys and signatures which constitute about 1/3 to 2/3 of a transaction.

This makes Nakamoto's [whitepaper](https://bitcoin.org/bitcoin.pdf)-style pruning in Bitcoin right now pretty much impossible. Happily, some smart people have been working on improving the situation.

## Segregated Witness

*...which sounds like some weird law-enforcement term...*

Blockstream's testnet sidechain, [Elements Alpha](https://github.com/ElementsProject/elementsproject.github.io), includes a nifty feature called [segregated witness](https://github.com/ElementsProject/elementsproject.github.io#segregated-witness). First, some background on witnesses in cryptography:

A witness is the data needed to prove some other data's validity. This probably derives from contract law, where you often get other people to witness your signature on important documents. In the case of Bitcoin, the witness to a particular spend being valid is the scriptPubKey of the output being spent and scriptSig of the input that references it in the spending transaction.

In Elements Alpha and the new [Liquid mainnet Sidechain](https://blockstream.com/2015/10/12/introducing-liquid/), the witness is "segregated" into a different part of the block and is not covered by the txid hash. That means that nodes who want to reduce their download requirements can skip downloading witnesses for transactions with more than (say) 50,000 confirmations. However, now they can still use the block header merkle root to verify that all of the non-witness data (including the amounts transferred) are correct, and use that to build a correct UTXO set.

I can't find a source right now, but I think I've heard Wuille and Maxwell say that for typical Bitcoin mainnet transactions, this would mean about 1/3 of the transaction data doesn't have to be downloaded by nodes that don't want to validate old signatures. On Elements Alpha where the witness is larger for transactions that use [value blinding](https://github.com/ElementsProject/elementsproject.github.io#confidential-transactions), this would mean 2/3 of the data doesn't have to be downloaded.

As a bonus, segregated witness also "completely eliminates all known forms of transaction malleability" ([Wuille's description](https://github.com/ElementsProject/elementsproject.github.io#segregated-witness)).

## When will this appear in Bitcoin?

You're in luck: just a few days ago, Luke Dashjr [presented an idea](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011579.html) for how segregated witness can be soft forked onto Bitcoin mainnet. (Previously, it had been thought that a hard fork would be necessary.)

The payer pays to a scriptPubKey that always returns true but which contains the hash of a redeem script like P2SH does:

```
<hash_of_redeem_script> OP_TRUE

```

*(I just made that up; I don't know what the real construction will look like.)*

When the person paid later goes to spend, they provide an empty scriptSig in the transaction itself. This is valid to old nodes, but upgraded nodes know to look somewhere else in the block for the actual scriptSig. The witness has been segregated.

For both old nodes and new nodes, they calculate the txid using the empty scriptSig, so the data covered by the merkle root still covers the important value amounts and references.

I don't know exactly how well this compares to the segregated witness in Elements Alpha (does that cover the scriptPubKey as well?), but it does most of the work in a convenient soft forkable construction.

Since this is week-old engineering, it may change a lot or even be found to be unworkable in the coming months, so don't expect to see it in the immediate future—but, long term, do expect to start seeing some new pre-download pruning options appear.


---

### Answer by username_5 on 2015-11-04. Score: -1

Yes, this should be possible. But there is no support for this in bitcoind yet.

Basically, you can run bitcoind with -prune option. In that case it will delete the older blocks and keep only the unspent outputs(which are required for newer tx validation). So theoretically, you can just copy utxo database from an existing node and start downloading from the current block.

Right now there is no decentralized way to build the utxo database, you just have to start downloading from block 0 and build it yourselves. You could for example torrent the whole UTXO DB. I was thinking of a way to relay the UTXO set (like blocks) , but it would be very big (around 1.2GB right now). I am not knowledgeable enough to know how exactly could such a thing be implemented but it looks theoretically plausible to me.

> **Comments:**
> **username_3**: Relaying the UTXO would be very foolish, if you trust it anybody can steal from you and fake payments to you. Bitcoin only works when nodes create their own UTXO, which requires all of the transaction history.  
> **username_5**: I dont think its that foolish . You can checkpoint utxo at a given block and record the hash of utxo to make sure its not changed.  You can proceed downloading blocks from that hash onwards. Starting again from block zero is unnecessary and wastes lots of time and resources  
> **username_3**: As a block validity rule UTXO commitments is what you're talking about, and that turns out to be intensive to verify. Some portion of blocks today get no validation before they are mined on top of, indicating the load for that is already too high without adding additional requirements like decompacting and hashing a multi gigabyte UTXO. As something just hard coded into the client well, you're changing the security model somewhat.  
> **username_5**: You have change to fork the codebase in put the hash in it.  We already have  checkpoints in bitcoin code of known hashes https://bitcointalk.org/index.php?topic=194078.0. Also please note that this question is about creating a new blockchain based currency, so this can be implemented. I am not at all suggesting changing bitcoin code base here.  
> **username_3**: Bitcoins checkpoints are not a consensus mechanism, this is commonly confused.  

---

