path: root/dd/fd9f8d4c8460bf7463104d66d05d21fbac58c2

Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 068C482B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 17 May 2016 14:03:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
	[209.85.217.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB1BC1AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 17 May 2016 14:03:24 +0000 (UTC)
Received: by mail-lb0-f172.google.com with SMTP id jj5so6364038lbc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 17 May 2016 07:03:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to; 
	bh=s383w1Hw6XEwcUmdapZe6BkJqFYSoEX8LmQZWXOg9Dw=;
	b=xHPqQumlPacnYaggsDD3OXZoZMFIxQdoAd2pt8KuEWrjb7YjzYkoDvtCPxA28qQriq
	WUCtZTr+btBGeZOzTgnDjGqSkf9hwFnlSZAPih1hrIgD191x5489QGm5aMBfwnWlqrer
	F3ILryxguYCG2QIQ87gApJiYuonQ5/2SHAESSF/p6iY6DxhGeVjXkM3NumXIz46RqgTX
	pVJnlnt9Hb5kgHXWFxSAzTRqy7ZDptsJ4ABPUB1LXcEltimSh+wESNQvQHklwTkdJgh6
	SGZlmqvmJ3IvKfMkPVW896iBAVBdwlEWE+ofenY0mxI/zcX8V96HJp7s5uBSVXhPRcvb
	MakQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to;
	bh=s383w1Hw6XEwcUmdapZe6BkJqFYSoEX8LmQZWXOg9Dw=;
	b=nBYpMxxg9RObuzOjCWqeSrtms8D5ecmE2qguk8nOOVVCqP1k36UnPDHNFrAYvFpcNf
	H8i+giyoX0UTA+aIjqcQxQOHXslzBRr19ZHRr8UwwcKvcLLWvlUsbpR5SN+IIzKEsd1W
	8k80yti4HXP0axtasFDQH9KibcDpaw7CFJ9A9gdrNFGl0HKiCOu67pAgiWJNpepysEKp
	tjVDn9Kwu1GeziP1y0Z5Z6Y6UICINOsu6r96bW4avBwa16oOb/Q13rLVx5QqIipuF3q0
	xiaLathMV38BYM2Hl+FK2U8sis6p7qjgmWWGOIHEXrjoBkNKNJq38KkvQlm+lTWf8HrZ
	/y7Q==
X-Gm-Message-State: AOPr4FXKtZJhjRSRc1c1v7H2bpZyYcpx/WQEpjcZhunoCoK/rZHns0HRg22aH8PB9tLbQ0MCBBOZ5uW0QTu/oA==
MIME-Version: 1.0
X-Received: by 10.112.63.169 with SMTP id h9mr632479lbs.8.1463493802892; Tue,
	17 May 2016 07:03:22 -0700 (PDT)
Received: by 10.25.141.13 with HTTP; Tue, 17 May 2016 07:03:22 -0700 (PDT)
In-Reply-To: <20160517132311.GA21656@fedora-21-dvm>
References: <20160517132311.GA21656@fedora-21-dvm>
Date: Tue, 17 May 2016 10:03:22 -0400
Message-ID: <CADL_X_cjdhoztLsf7LLZrpdTYiJGk=Fb39Cn+vQV8kpgGAaEbg@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c3fd1240a58205330a34ee
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 17 May 2016 14:27:31 +0000
Subject: Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With
 Low-Latency Delayed TXO Commitments
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2016 14:03:29 -0000

--001a11c3fd1240a58205330a34ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Great post, Peter.

4) By fixing the problem (or possibly just "fixing" the problem) are
we encouraging/legitimising blockchain use-cases other than BTC value
transfer? Should we?

I don't think it would encourage non-value-transfer usage more
because, as you noted, many such use cases are valuable enough that
people are willing to pay much higher transaction fees in order to
have their data timestamped. I think it's more an issue of the block
space / transaction fee market since the cost of making a transaction
is directly borne by users, as opposed to the cost of the UTXO set
which may not be borne by them if they don't run a full node.

I'm of the opinion that if the world decides that Bitcoin is more
valuable as a trustworthy generalized timestamping mechanism than as a
value transfer system, protocol developers shouldn't try to steer the
ship against the wind. As more people and use cases enter the
ecosystem, the most valuable ones ought to survive - I hope that this
market will be fostered by the developers.

- Jameson


On Tue, May 17, 2016 at 9:23 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> # Motivation
>
> UTXO growth is a serious concern for Bitcoin's long-term decentralization=
.
> To
> run a competitive mining operation potentially the entire UTXO set must b=
e
> in
> RAM to achieve competitive latency; your larger, more centralized,
> competitors
> will have the UTXO set in RAM. Mining is a zero-sum game, so the extra
> latency
> of not doing so if they do directly impacts your profit margin. Secondly,
> having possession of the UTXO set is one of the minimum requirements to
> run a
> full node; the larger the set the harder it is to run a full node.
>
> Currently the maximum size of the UTXO set is unbounded as there is no
> consensus rule that limits growth, other than the block-size limit itself=
;
> as
> of writing the UTXO set is 1.3GB in the on-disk, compressed serialization=
,
> which expands to significantly more in memory. UTXO growth is driven by a
> number of factors, including the fact that there is little incentive to
> merge
> inputs, lost coins, dust outputs that can't be economically spent, and
> non-btc-value-transfer "blockchain" use-cases such as anti-replay oracles
> and
> timestamping.
>
> We don't have good tools to combat UTXO growth. Segregated Witness
> proposes to
> give witness space a 75% discount, in part of make reducing the UTXO set
> size
> by spending txouts cheaper. While this may change wallets to more often
> spend
> dust, it's hard to imagine an incentive sufficiently strong to discourage
> most,
> let alone all, UTXO growing behavior.
>
> For example, timestamping applications often create unspendable outputs
> due to
> ease of implementation, and because doing so is an easy way to make sure
> that
> the data required to reconstruct the timestamp proof won't get lost - all
> Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay
> use-cases like using the UTXO set for key rotation piggyback on the
> uniquely
> strong security and decentralization guarantee that Bitcoin provides; it'=
s
> very
> difficult - perhaps impossible - to provide these applications with
> alternatives that are equally secure. These non-btc-value-transfer
> use-cases
> can often afford to pay far higher fees per UTXO created than competing
> btc-value-transfer use-cases; many users could afford to spend $50 to
> register
> a new PGP key, yet would rather not spend $50 in fees to create a standar=
d
> two
> output transaction. Effective techniques to resist miner censorship exist=
,
> so
> without resorting to whitelists blocking non-btc-value-transfer use-cases
> as
> "spam" is not a long-term, incentive compatible, solution.
>
> A hard upper limit on UTXO set size could create a more level playing
> field in
> the form of fixed minimum requirements to run a performant Bitcoin node,
> and
> make the issue of UTXO "spam" less important. However, making any coins
> unspendable, regardless of age or value, is a politically untenable
> economic
> change.
>
>
> # TXO Commitments
>
> A merkle tree committing to the state of all transaction outputs, both
> spent
> and unspent, we can provide a method of compactly proving the current
> state of
> an output. This lets us "archive" less frequently accessed parts of the
> UTXO
> set, allowing full nodes to discard the associated data, still providing =
a
> mechanism to spend those archived outputs by proving to those nodes that
> the
> outputs are in fact unspent.
>
> Specifically TXO commitments proposes a Merkle Mountain Range=C2=B9 (MMR)=
, a
> type of deterministic, indexable, insertion ordered merkle tree, which
> allows
> new items to be cheaply appended to the tree with minimal storage
> requirements,
> just log2(n) "mountain tips". Once an output is added to the TXO MMR it i=
s
> never removed; if an output is spent its status is updated in place. Both
> the
> state of a specific item in the MMR, as well the validity of changes to
> items
> in the MMR, can be proven with log2(n) sized proofs consisting of a merkl=
e
> path
> to the tip of the tree.
>
> At an extreme, with TXO commitments we could even have no UTXO set at all=
,
> entirely eliminating the UTXO growth problem. Transactions would simply b=
e
> accompanied by TXO commitment proofs showing that the outputs they wanted
> to
> spend were still unspent; nodes could update the state of the TXO MMR
> purely
> from TXO commitment proofs. However, the log2(n) bandwidth overhead per
> txin is
> substantial, so a more realistic implementation is be to have a UTXO cach=
e
> for
> recent transactions, with TXO commitments acting as a alternate for the
> (rare)
> event that an old txout needs to be spent.
>
> Proofs can be generated and added to transactions without the involvement
> of
> the signers, even after the fact; there's no need for the proof itself to
> signed and the proof is not part of the transaction hash. Anyone with
> access to
> TXO MMR data can (re)generate missing proofs, so minimal, if any, changes
> are
> required to wallet software to make use of TXO commitments.
>
>
> ## Delayed Commitments
>
> TXO commitments aren't a new idea - the author proposed them years ago in
> response to UTXO commitments. However it's critical for small miners'
> orphan
> rates that block validation be fast, and so far it has proven difficult t=
o
> create (U)TXO implementations with acceptable performance; updating and
> recalculating cryptographicly hashed merkelized datasets is inherently mo=
re
> work than not doing so. Fortunately if we maintain a UTXO set for recent
> outputs, TXO commitments are only needed when spending old, archived,
> outputs.
> We can take advantage of this by delaying the commitment, allowing it to =
be
> calculated well in advance of it actually being used, thus changing a
> latency-critical task into a much easier average throughput problem.
>
> Concretely each block B_i commits to the TXO set state as of block
> B_{i-n}, in
> other words what the TXO commitment would have been n blocks ago, if not
> for
> the n block delay. Since that commitment only depends on the contents of
> the
> blockchain up until block B_{i-n}, the contents of any block after are
> irrelevant to the calculation.
>
>
> ## Implementation
>
> Our proposed high-performance/low-latency delayed commitment full-node
> implementation needs to store the following data:
>
> 1) UTXO set
>
>     Low-latency K:V map of txouts definitely known to be unspent. Similar
> to
>     existing UTXO implementation, but with the key difference that old,
>     unspent, outputs may be pruned from the UTXO set.
>
>
> 2) STXO set
>
>     Low-latency set of transaction outputs known to have been spent by
>     transactions after the most recent TXO commitment, but created prior
> to the
>     TXO commitment.
>
>
> 3) TXO journal
>
>     FIFO of outputs that need to be marked as spent in the TXO MMR. Appen=
ds
>     must be low-latency; removals can be high-latency.
>
>
> 4) TXO MMR list
>
>     Prunable, ordered list of TXO MMR's, mainly the highest pending
> commitment,
>     backed by a reference counted, cryptographically hashed object store
>     indexed by digest (similar to how git repos work). High-latency ok.
> We'll
>     cover this in more in detail later.
>
>
> ### Fast-Path: Verifying a Txout Spend In a Block
>
> When a transaction output is spent by a transaction in a block we have tw=
o
> cases:
>
> 1) Recently created output
>
>     Output created after the most recent TXO commitment, so it should be
> in the
>     UTXO set; the transaction spending it does not need a TXO commitment
> proof.
>     Remove the output from the UTXO set and append it to the TXO journal.
>
> 2) Archived output
>
>     Output created prior to the most recent TXO commitment, so there's no
>     guarantee it's in the UTXO set; transaction will have a TXO commitmen=
t
>     proof for the most recent TXO commitment showing that it was unspent.
>     Check that the output isn't already in the STXO set (double-spent),
> and if
>     not add it. Append the output and TXO commitment proof to the TXO
> journal.
>
> In both cases recording an output as spent requires no more than two
> key:value
> updates, and one journal append. The existing UTXO set requires one
> key:value
> update per spend, so we can expect new block validation latency to be
> within 2x
> of the status quo even in the worst case of 100% archived output spends.
>
>
> ### Slow-Path: Calculating Pending TXO Commitments
>
> In a low-priority background task we flush the TXO journal, recording the
> outputs spent by each block in the TXO MMR, and hashing MMR data to obtai=
n
> the
> TXO commitment digest. Additionally this background task removes STXO's
> that
> have been recorded in TXO commitments, and prunes TXO commitment data no
> longer
> needed.
>
> Throughput for the TXO commitment calculation will be worse than the
> existing
> UTXO only scheme. This impacts bulk verification, e.g. initial block
> download.
> That said, TXO commitments provides other possible tradeoffs that can
> mitigate
> impact of slower validation throughput, such as skipping validation of ol=
d
> history, as well as fraud proof approaches.
>
>
> ### TXO MMR Implementation Details
>
> Each TXO MMR state is a modification of the previous one with most
> information
> shared, so we an space-efficiently store a large number of TXO commitment=
s
> states, where each state is a small delta of the previous state, by shari=
ng
> unchanged data between each state; cycles are impossible in merkelized da=
ta
> structures, so simple reference counting is sufficient for garbage
> collection.
> Data no longer needed can be pruned by dropping it from the database, and
> unpruned by adding it again. Since everything is committed to via
> cryptographic
> hash, we're guaranteed that regardless of where we get the data, after
> unpruning we'll have the right data.
>
> Let's look at how the TXO MMR works in detail. Consider the following TXO
> MMR
> with two txouts, which we'll call state #0:
>
>       0
>      / \
>     a   b
>
> If we add another entry we get state #1:
>
>         1
>        / \
>       0   \
>      / \   \
>     a   b   c
>
> Note how it 100% of the state #0 data was reused in commitment #1. Let's
> add two more entries to get state #2:
>
>             2
>            / \
>           2   \
>          / \   \
>         /   \   \
>        /     \   \
>       0       2   \
>      / \     / \   \
>     a   b   c   d   e
>
> This time part of state #1 wasn't reused - it's wasn't a perfect binary
> tree - but we've still got a lot of re-use.
>
> Now suppose state #2 is committed into the blockchain by the most recent
> block.
> Future transactions attempting to spend outputs created as of state #2 ar=
e
> obliged to prove that they are unspent; essentially they're forced to
> provide
> part of the state #2 MMR data. This lets us prune that data, discarding i=
t,
> leaving us with only the bare minimum data we need to append new txouts t=
o
> the
> TXO MMR, the tips of the perfect binary trees ("mountains") within the MM=
R:
>
>             2
>            / \
>           2   \
>                \
>                 \
>                  \
>                   \
>                    \
>                     e
>
> Note that we're glossing over some nuance here about exactly what data
> needs to
> be kept; depending on the details of the implementation the only data we
> need
> for nodes "2" and "e" may be their hash digest.
>
> Adding another three more txouts results in state #3:
>
>                   3
>                  / \
>                 /   \
>                /     \
>               /       \
>              /         \
>             /           \
>            /             \
>           2               3
>                          / \
>                         /   \
>                        /     \
>                       3       3
>                      / \     / \
>                     e   f   g   h
>
> Suppose recently created txout f is spent. We have all the data required =
to
> update the MMR, giving us state #4. It modifies two inner nodes and one
> leaf
> node:
>
>                   4
>                  / \
>                 /   \
>                /     \
>               /       \
>              /         \
>             /           \
>            /             \
>           2               4
>                          / \
>                         /   \
>                        /     \
>                       4       3
>                      / \     / \
>                     e  (f)  g   h
>
> If an archived txout is spent requires the transaction to provide the
> merkle
> path to the most recently committed TXO, in our case state #2. If txout b
> is
> spent that means the transaction must provide the following data from
> state #2:
>
>             2
>            /
>           2
>          /
>         /
>        /
>       0
>        \
>         b
>
> We can add that data to our local knowledge of the TXO MMR, unpruning par=
t
> of
> it:
>
>                   4
>                  / \
>                 /   \
>                /     \
>               /       \
>              /         \
>             /           \
>            /             \
>           2               4
>          /               / \
>         /               /   \
>        /               /     \
>       0               4       3
>        \             / \     / \
>         b           e  (f)  g   h
>
> Remember, we haven't _modified_ state #4 yet; we just have more data abou=
t
> it.
> When we mark txout b as spent we get state #5:
>
>                   5
>                  / \
>                 /   \
>                /     \
>               /       \
>              /         \
>             /           \
>            /             \
>           5               4
>          /               / \
>         /               /   \
>        /               /     \
>       5               4       3
>        \             / \     / \
>        (b)          e  (f)  g   h
>
> Secondly by now state #3 has been committed into the chain, and
> transactions
> that want to spend txouts created as of state #3 must provide a TXO proof
> consisting of state #3 data. The leaf nodes for outputs g and h, and the
> inner
> node above them, are part of state #3, so we prune them:
>
>                   5
>                  / \
>                 /   \
>                /     \
>               /       \
>              /         \
>             /           \
>            /             \
>           5               4
>          /               /
>         /               /
>        /               /
>       5               4
>        \             / \
>        (b)          e  (f)
>
> Finally, lets put this all together, by spending txouts a, c, and g, and
> creating three new txouts i, j, and k. State #3 was the most recently
> committed
> state, so the transactions spending a and g are providing merkle paths up
> to
> it. This includes part of the state #2 data:
>
>                   3
>                  / \
>                 /   \
>                /     \
>               /       \
>              /         \
>             /           \
>            /             \
>           2               3
>          / \               \
>         /   \               \
>        /     \               \
>       0       2               3
>      /       /               /
>     a       c               g
>
> After unpruning we have the following data for state #5:
>
>                   5
>                  / \
>                 /   \
>                /     \
>               /       \
>              /         \
>             /           \
>            /             \
>           5               4
>          / \             / \
>         /   \           /   \
>        /     \         /     \
>       5       2       4       3
>      / \     /       / \     /
>     a  (b)  c       e  (f)  g
>
> That's sufficient to mark the three outputs as spent and add the three ne=
w
> txouts, resulting in state #6:
>
>                         6
>                        / \
>                       /   \
>                      /     \
>                     /       \
>                    /         \
>                   6           \
>                  / \           \
>                 /   \           \
>                /     \           \
>               /       \           \
>              /         \           \
>             /           \           \
>            /             \           \
>           6               6           \
>          / \             / \           \
>         /   \           /   \           6
>        /     \         /     \         / \
>       6       6       4       6       6   \
>      / \     /       / \     /       / \   \
>    (a) (b) (c)      e  (f) (g)      i   j   k
>
> Again, state #4 related data can be pruned. In addition, depending on how
> the
> STXO set is implemented may also be able to prune data related to spent
> txouts
> after that state, including inner nodes where all txouts under them have
> been
> spent (more on pruning spent inner nodes later).
>
>
> ### Consensus and Pruning
>
> It's important to note that pruning behavior is consensus critical: a ful=
l
> node
> that is missing data due to pruning it too soon will fall out of
> consensus, and
> a miner that fails to include a merkle proof that is required by the
> consensus
> is creating an invalid block. At the same time many full nodes will have
> significantly more data on hand than the bare minimum so they can help
> wallets
> make transactions spending old coins; implementations should strongly
> consider
> separating the data that is, and isn't, strictly required for consensus.
>
> A reasonable approach for the low-level cryptography may be to actually
> treat
> the two cases differently, with the TXO commitments committing too what
> data
> does and does not need to be kept on hand by the UTXO expiration rules. O=
n
> the
> other hand, leaving that uncommitted allows for certain types of soft-for=
ks
> where the protocol is changed to require more data than it previously did=
.
>
>
> ### Consensus Critical Storage Overheads
>
> Only the UTXO and STXO sets need to be kept on fast random access storage=
.
> Since STXO set entries can only be created by spending a UTXO - and are
> smaller
> than a UTXO entry - we can guarantee that the peak size of the UTXO and
> STXO
> sets combined will always be less than the peak size of the UTXO set alon=
e
> in
> the existing UTXO-only scheme (though the combined size can be temporaril=
y
> higher than what the UTXO set size alone would be when large numbers of
> archived txouts are spent).
>
> TXO journal entries and unpruned entries in the TXO MMR have log2(n)
> maximum
> overhead per entry: a unique merkle path to a TXO commitment (by "unique"
> we
> mean that no other entry shares data with it). On a reasonably fast syste=
m
> the
> TXO journal will be flushed quickly, converting it into TXO MMR data; the
> TXO
> journal will never be more than a few blocks in size.
>
> Transactions spending non-archived txouts are not required to provide any
> TXO
> commitment data; we must have that data on hand in the form of one TXO MM=
R
> entry per UTXO. Once spent however the TXO MMR leaf node associated with
> that
> non-archived txout can be immediately pruned - it's no longer in the UTXO
> set
> so any attempt to spend it will fail; the data is now immutable and we'll
> never
> need it again. Inner nodes in the TXO MMR can also be pruned if all leafs
> under
> them are fully spent; detecting this is easy the TXO MMR is a merkle-sum
> tree,
> with each inner node committing to the sum of the unspent txouts under it=
.
>
> When a archived txout is spent the transaction is required to provide a
> merkle
> path to the most recent TXO commitment. As shown above that path is
> sufficient
> information to unprune the necessary nodes in the TXO MMR and apply the
> spend
> immediately, reducing this case to the TXO journal size question
> (non-consensus
> critical overhead is a different question, which we'll address in the nex=
t
> section).
>
> Taking all this into account the only significant storage overhead of our
> TXO
> commitments scheme when compared to the status quo is the log2(n) merkle
> path
> overhead; as long as less than 1/log2(n) of the UTXO set is active,
> non-archived, UTXO's we've come out ahead, even in the unrealistic case
> where
> all storage available is equally fast. In the real world that isn't yet t=
he
> case - even SSD's significantly slower than RAM.
>
>
> ### Non-Consensus Critical Storage Overheads
>
> Transactions spending archived txouts pose two challenges:
>
> 1) Obtaining up-to-date TXO commitment proofs
>
> 2) Updating those proofs as blocks are mined
>
> The first challenge can be handled by specialized archival nodes, not
> unlike
> how some nodes make transaction data available to wallets via bloom
> filters or
> the Electrum protocol. There's a whole variety of options available, and
> the
> the data can be easily sharded to scale horizontally; the data is
> self-validating allowing horizontal scaling without trust.
>
> While miners and relay nodes don't need to be concerned about the initial
> commitment proof, updating that proof is another matter. If a node
> aggressively
> prunes old versions of the TXO MMR as it calculates pending TXO
> commitments, it
> won't have the data available to update the TXO commitment proof to be
> against
> the next block, when that block is found; the child nodes of the TXO MMR
> tip
> are guaranteed to have changed, yet aggressive pruning would have
> discarded that
> data.
>
> Relay nodes could ignore this problem if they simply accept the fact that
> they'll only be able to fully relay the transaction once, when it is
> initially
> broadcast, and won't be able to provide mempool functionality after the
> initial
> relay. Modulo high-latency mixnets, this is probably acceptable; the
> author has
> previously argued that relay nodes don't need a mempool=C2=B2 at all.
>
> For a miner though not having the data necessary to update the proofs as
> blocks
> are found means potentially losing out on transactions fees. So how much
> extra
> data is necessary to make this a non-issue?
>
> Since the TXO MMR is insertion ordered, spending a non-archived txout can
> only
> invalidate the upper nodes in of the archived txout's TXO MMR proof (if
> this
> isn't clear, imagine a two-level scheme, with a per-block TXO MMRs,
> committed
> by a master MMR for all blocks). The maximum number of relevant inner nod=
es
> changed is log2(n) per block, so if there are n non-archival blocks
> between the
> most recent TXO commitment and the pending TXO MMR tip, we have to store
> log2(n)*n inner nodes - on the order of a few dozen MB even when n is a
> (seemingly ridiculously high) year worth of blocks.
>
> Archived txout spends on the other hand can invalidate TXO MMR proofs at
> any
> level - consider the case of two adjacent txouts being spent. To guarante=
e
> success requires storing full proofs. However, they're limited by the
> blocksize
> limit, and additionally are expected to be relatively uncommon. For
> example, if
> 1% of 1MB blocks was archival spends, our hypothetical year long TXO
> commitment
> delay is only a few hundred MB of data with low-IO-performance
> requirements.
>
>
> ## Security Model
>
> Of course, a TXO commitment delay of a year sounds ridiculous. Even the
> slowest
> imaginable computer isn't going to need more than a few blocks of TXO
> commitment delay to keep up ~100% of the time, and there's no reason why =
we
> can't have the UTXO archive delay be significantly longer than the TXO
> commitment delay.
>
> However, as with UTXO commitments, TXO commitments raise issues with
> Bitcoin's
> security model by allowing relatively miners to profitably mine
> transactions
> without bothering to validate prior history. At the extreme, if there was
> no
> commitment delay at all at the cost of a bit of some extra network
> bandwidth
> "full" nodes could operate and even mine blocks completely statelessly by
> expecting all transactions to include "proof" that their inputs are
> unspent; a
> TXO commitment proof for a commitment you haven't verified isn't a proof
> that a
> transaction output is unspent, it's a proof that some miners claimed the
> txout
> was unspent.
>
> At one extreme, we could simply implement TXO commitments in a "virtual"
> fashion, without miners actually including the TXO commitment digest in
> their
> blocks at all. Full nodes would be forced to compute the commitment from
> scratch, in the same way they are forced to compute the UTXO state, or
> total
> work. Of course a full node operator who doesn't want to verify old
> history can
> get a copy of the TXO state from a trusted source - no different from how
> you
> could get a copy of the UTXO set from a trusted source.
>
> A more pragmatic approach is to accept that people will do that anyway, a=
nd
> instead assume that sufficiently old blocks are valid. But how old is
> "sufficiently old"? First of all, if your full node implementation comes
> "from
> the factory" with a reasonably up-to-date minimum accepted total-work
> threshold=E2=81=B1 - in other words it won't accept a chain with less tha=
n that
> amount
> of total work - it may be reasonable to assume any Sybil attacker with
> sufficient hashing power to make a forked chain meeting that threshold
> with,
> say, six months worth of blocks has enough hashing power to threaten the
> main
> chain as well.
>
> That leaves public attempts to falsify TXO commitments, done out in the
> open by
> the majority of hashing power. In this circumstance the "assumed valid"
> threshold determines how long the attack would have to go on before full
> nodes
> start accepting the invalid chain, or at least, newly installed/recently
> reset
> full nodes. The minimum age that we can "assume valid" is tradeoff betwee=
n
> political/social/technical concerns; we probably want at least a few week=
s
> to
> guarantee the defenders a chance to organise themselves.
>
> With this in mind, a longer-than-technically-necessary TXO commitment
> delay=CA=B2
> may help ensure that full node software actually validates some minimum
> number
> of blocks out-of-the-box, without taking shortcuts. However this can be
> achieved in a wide variety of ways, such as the author's prev-block-proof
> proposal=C2=B3, fraud proofs, or even a PoW with an inner loop dependent =
on
> blockchain data. Like UTXO commitments, TXO commitments are also
> potentially
> very useful in reducing the need for SPV wallet software to trust third
> parties
> providing them with transaction data.
>
> i) Checkpoints that reject any chain without a specific block are a more
>    common, if uglier, way of achieving this protection.
>
> j) A good homework problem is to figure out how the TXO commitment could =
be
>    designed such that the delay could be reduced in a soft-fork.
>
>
> ## Further Work
>
> While we've shown that TXO commitments certainly could be implemented
> without
> increasing peak IO bandwidth/block validation latency significantly with
> the
> delayed commitment approach, we're far from being certain that they shoul=
d
> be
> implemented this way (or at all).
>
> 1) Can a TXO commitment scheme be optimized sufficiently to be used
> directly
> without a commitment delay? Obviously it'd be preferable to avoid all the
> above
> complexity entirely.
>
> 2) Is it possible to use a metric other than age, e.g. priority? While th=
is
> complicates the pruning logic, it could use the UTXO set space more
> efficiently, especially if your goal is to prioritise bitcoin
> value-transfer
> over other uses (though if "normal" wallets nearly never need to use TXO
> commitments proofs to spend outputs, the infrastructure to actually do
> this may
> rot).
>
> 3) Should UTXO archiving be based on a fixed size UTXO set, rather than a=
n
> age/priority/etc. threshold?
>
> 4) By fixing the problem (or possibly just "fixing" the problem) are we
> encouraging/legitimising blockchain use-cases other than BTC value
> transfer?
> Should we?
>
> 5) Instead of TXO commitment proofs counting towards the blocksize limit,
> can
> we use a different miner fairness/decentralization metric/incentive? For
> instance it might be reasonable for the TXO commitment proof size to be
> discounted, or ignored entirely, if a proof-of-propagation scheme (e.g.
> thinblocks) is used to ensure all miners have received the proof in
> advance.
>
> 6) How does this interact with fraud proofs? Obviously furthering
> dependency on
> non-cryptographically-committed STXO/UTXO databases is incompatible with
> the
> modularized validation approach to implementing fraud proofs.
>
>
> # References
>
> 1) "Merkle Mountain Ranges",
>    Peter Todd, OpenTimestamps, Mar 18 2013,
>
> https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/m=
erkle-mountain-range.md
>
> 2) "Do we really need a mempool? (for relay nodes)",
>    Peter Todd, bitcoin-dev mailing list, Jul 18th 2015,
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009479.=
html
>
> 3) "Segregated witnesses and validationless mining",
>    Peter Todd, bitcoin-dev mailing list, Dec 23rd 2015,
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012=
103.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a11c3fd1240a58205330a34ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Great post, Peter.<div><br></div><div><pre style=3D"white-=
space:pre-wrap;color:rgb(0,0,0)">4) By fixing the problem (or possibly just=
 &quot;fixing&quot; the problem) are we encouraging/legitimising blockchain=
 use-cases other than BTC value transfer? Should we?

<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;white-space:=
normal">I don&#39;t think it would encourage non-value-transfer usage more =
because, as you noted, many such use cases are valuable enough that people =
are willing to pay much higher transaction fees in order to have their data=
 timestamped. I think it&#39;s more an issue of the block space / transacti=
on fee market since the cost of making a transaction is directly borne by u=
sers, as opposed to the cost of the UTXO set which may not be borne by them=
 if they don&#39;t run a full node.</div><div style=3D"color:rgb(34,34,34);=
font-family:arial,sans-serif;white-space:normal"><br>I&#39;m of the opinion=
 that if the world decides that Bitcoin is more valuable as a trustworthy g=
eneralized timestamping mechanism than as a value transfer system, protocol=
 developers shouldn&#39;t try to steer the ship against the wind. As more p=
eople and use cases enter the ecosystem, the most valuable ones ought to su=
rvive - I hope that this market will be fostered by the developers.</div><d=
iv style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;white-space:no=
rmal"><br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-se=
rif;white-space:normal">- Jameson</div><div><br></div>
</pre></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Tue, May 17, 2016 at 9:23 AM, Peter Todd via bitcoin-dev <span dir=3D"l=
tr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"># Motivation<br>
<br>
UTXO growth is a serious concern for Bitcoin&#39;s long-term decentralizati=
on. To<br>
run a competitive mining operation potentially the entire UTXO set must be =
in<br>
RAM to achieve competitive latency; your larger, more centralized, competit=
ors<br>
will have the UTXO set in RAM. Mining is a zero-sum game, so the extra late=
ncy<br>
of not doing so if they do directly impacts your profit margin. Secondly,<b=
r>
having possession of the UTXO set is one of the minimum requirements to run=
 a<br>
full node; the larger the set the harder it is to run a full node.<br>
<br>
Currently the maximum size of the UTXO set is unbounded as there is no<br>
consensus rule that limits growth, other than the block-size limit itself; =
as<br>
of writing the UTXO set is 1.3GB in the on-disk, compressed serialization,<=
br>
which expands to significantly more in memory. UTXO growth is driven by a<b=
r>
number of factors, including the fact that there is little incentive to mer=
ge<br>
inputs, lost coins, dust outputs that can&#39;t be economically spent, and<=
br>
non-btc-value-transfer &quot;blockchain&quot; use-cases such as anti-replay=
 oracles and<br>
timestamping.<br>
<br>
We don&#39;t have good tools to combat UTXO growth. Segregated Witness prop=
oses to<br>
give witness space a 75% discount, in part of make reducing the UTXO set si=
ze<br>
by spending txouts cheaper. While this may change wallets to more often spe=
nd<br>
dust, it&#39;s hard to imagine an incentive sufficiently strong to discoura=
ge most,<br>
let alone all, UTXO growing behavior.<br>
<br>
For example, timestamping applications often create unspendable outputs due=
 to<br>
ease of implementation, and because doing so is an easy way to make sure th=
at<br>
the data required to reconstruct the timestamp proof won&#39;t get lost - a=
ll<br>
Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay<b=
r>
use-cases like using the UTXO set for key rotation piggyback on the uniquel=
y<br>
strong security and decentralization guarantee that Bitcoin provides; it&#3=
9;s very<br>
difficult - perhaps impossible - to provide these applications with<br>
alternatives that are equally secure. These non-btc-value-transfer use-case=
s<br>
can often afford to pay far higher fees per UTXO created than competing<br>
btc-value-transfer use-cases; many users could afford to spend $50 to regis=
ter<br>
a new PGP key, yet would rather not spend $50 in fees to create a standard =
two<br>
output transaction. Effective techniques to resist miner censorship exist, =
so<br>
without resorting to whitelists blocking non-btc-value-transfer use-cases a=
s<br>
&quot;spam&quot; is not a long-term, incentive compatible, solution.<br>
<br>
A hard upper limit on UTXO set size could create a more level playing field=
 in<br>
the form of fixed minimum requirements to run a performant Bitcoin node, an=
d<br>
make the issue of UTXO &quot;spam&quot; less important. However, making any=
 coins<br>
unspendable, regardless of age or value, is a politically untenable economi=
c<br>
change.<br>
<br>
<br>
# TXO Commitments<br>
<br>
A merkle tree committing to the state of all transaction outputs, both spen=
t<br>
and unspent, we can provide a method of compactly proving the current state=
 of<br>
an output. This lets us &quot;archive&quot; less frequently accessed parts =
of the UTXO<br>
set, allowing full nodes to discard the associated data, still providing a<=
br>
mechanism to spend those archived outputs by proving to those nodes that th=
e<br>
outputs are in fact unspent.<br>
<br>
Specifically TXO commitments proposes a Merkle Mountain Range=C2=B9 (MMR), =
a<br>
type of deterministic, indexable, insertion ordered merkle tree, which allo=
ws<br>
new items to be cheaply appended to the tree with minimal storage requireme=
nts,<br>
just log2(n) &quot;mountain tips&quot;. Once an output is added to the TXO =
MMR it is<br>
never removed; if an output is spent its status is updated in place. Both t=
he<br>
state of a specific item in the MMR, as well the validity of changes to ite=
ms<br>
in the MMR, can be proven with log2(n) sized proofs consisting of a merkle =
path<br>
to the tip of the tree.<br>
<br>
At an extreme, with TXO commitments we could even have no UTXO set at all,<=
br>
entirely eliminating the UTXO growth problem. Transactions would simply be<=
br>
accompanied by TXO commitment proofs showing that the outputs they wanted t=
o<br>
spend were still unspent; nodes could update the state of the TXO MMR purel=
y<br>
from TXO commitment proofs. However, the log2(n) bandwidth overhead per txi=
n is<br>
substantial, so a more realistic implementation is be to have a UTXO cache =
for<br>
recent transactions, with TXO commitments acting as a alternate for the (ra=
re)<br>
event that an old txout needs to be spent.<br>
<br>
Proofs can be generated and added to transactions without the involvement o=
f<br>
the signers, even after the fact; there&#39;s no need for the proof itself =
to<br>
signed and the proof is not part of the transaction hash. Anyone with acces=
s to<br>
TXO MMR data can (re)generate missing proofs, so minimal, if any, changes a=
re<br>
required to wallet software to make use of TXO commitments.<br>
<br>
<br>
## Delayed Commitments<br>
<br>
TXO commitments aren&#39;t a new idea - the author proposed them years ago =
in<br>
response to UTXO commitments. However it&#39;s critical for small miners&#3=
9; orphan<br>
rates that block validation be fast, and so far it has proven difficult to<=
br>
create (U)TXO implementations with acceptable performance; updating and<br>
recalculating cryptographicly hashed merkelized datasets is inherently more=
<br>
work than not doing so. Fortunately if we maintain a UTXO set for recent<br=
>
outputs, TXO commitments are only needed when spending old, archived, outpu=
ts.<br>
We can take advantage of this by delaying the commitment, allowing it to be=
<br>
calculated well in advance of it actually being used, thus changing a<br>
latency-critical task into a much easier average throughput problem.<br>
<br>
Concretely each block B_i commits to the TXO set state as of block B_{i-n},=
 in<br>
other words what the TXO commitment would have been n blocks ago, if not fo=
r<br>
the n block delay. Since that commitment only depends on the contents of th=
e<br>
blockchain up until block B_{i-n}, the contents of any block after are<br>
irrelevant to the calculation.<br>
<br>
<br>
## Implementation<br>
<br>
Our proposed high-performance/low-latency delayed commitment full-node<br>
implementation needs to store the following data:<br>
<br>
1) UTXO set<br>
<br>
=C2=A0 =C2=A0 Low-latency K:V map of txouts definitely known to be unspent.=
 Similar to<br>
=C2=A0 =C2=A0 existing UTXO implementation, but with the key difference tha=
t old,<br>
=C2=A0 =C2=A0 unspent, outputs may be pruned from the UTXO set.<br>
<br>
<br>
2) STXO set<br>
<br>
=C2=A0 =C2=A0 Low-latency set of transaction outputs known to have been spe=
nt by<br>
=C2=A0 =C2=A0 transactions after the most recent TXO commitment, but create=
d prior to the<br>
=C2=A0 =C2=A0 TXO commitment.<br>
<br>
<br>
3) TXO journal<br>
<br>
=C2=A0 =C2=A0 FIFO of outputs that need to be marked as spent in the TXO MM=
R. Appends<br>
=C2=A0 =C2=A0 must be low-latency; removals can be high-latency.<br>
<br>
<br>
4) TXO MMR list<br>
<br>
=C2=A0 =C2=A0 Prunable, ordered list of TXO MMR&#39;s, mainly the highest p=
ending commitment,<br>
=C2=A0 =C2=A0 backed by a reference counted, cryptographically hashed objec=
t store<br>
=C2=A0 =C2=A0 indexed by digest (similar to how git repos work). High-laten=
cy ok. We&#39;ll<br>
=C2=A0 =C2=A0 cover this in more in detail later.<br>
<br>
<br>
### Fast-Path: Verifying a Txout Spend In a Block<br>
<br>
When a transaction output is spent by a transaction in a block we have two<=
br>
cases:<br>
<br>
1) Recently created output<br>
<br>
=C2=A0 =C2=A0 Output created after the most recent TXO commitment, so it sh=
ould be in the<br>
=C2=A0 =C2=A0 UTXO set; the transaction spending it does not need a TXO com=
mitment proof.<br>
=C2=A0 =C2=A0 Remove the output from the UTXO set and append it to the TXO =
journal.<br>
<br>
2) Archived output<br>
<br>
=C2=A0 =C2=A0 Output created prior to the most recent TXO commitment, so th=
ere&#39;s no<br>
=C2=A0 =C2=A0 guarantee it&#39;s in the UTXO set; transaction will have a T=
XO commitment<br>
=C2=A0 =C2=A0 proof for the most recent TXO commitment showing that it was =
unspent.<br>
=C2=A0 =C2=A0 Check that the output isn&#39;t already in the STXO set (doub=
le-spent), and if<br>
=C2=A0 =C2=A0 not add it. Append the output and TXO commitment proof to the=
 TXO journal.<br>
<br>
In both cases recording an output as spent requires no more than two key:va=
lue<br>
updates, and one journal append. The existing UTXO set requires one key:val=
ue<br>
update per spend, so we can expect new block validation latency to be withi=
n 2x<br>
of the status quo even in the worst case of 100% archived output spends.<br=
>
<br>
<br>
### Slow-Path: Calculating Pending TXO Commitments<br>
<br>
In a low-priority background task we flush the TXO journal, recording the<b=
r>
outputs spent by each block in the TXO MMR, and hashing MMR data to obtain =
the<br>
TXO commitment digest. Additionally this background task removes STXO&#39;s=
 that<br>
have been recorded in TXO commitments, and prunes TXO commitment data no lo=
nger<br>
needed.<br>
<br>
Throughput for the TXO commitment calculation will be worse than the existi=
ng<br>
UTXO only scheme. This impacts bulk verification, e.g. initial block downlo=
ad.<br>
That said, TXO commitments provides other possible tradeoffs that can mitig=
ate<br>
impact of slower validation throughput, such as skipping validation of old<=
br>
history, as well as fraud proof approaches.<br>
<br>
<br>
### TXO MMR Implementation Details<br>
<br>
Each TXO MMR state is a modification of the previous one with most informat=
ion<br>
shared, so we an space-efficiently store a large number of TXO commitments<=
br>
states, where each state is a small delta of the previous state, by sharing=
<br>
unchanged data between each state; cycles are impossible in merkelized data=
<br>
structures, so simple reference counting is sufficient for garbage collecti=
on.<br>
Data no longer needed can be pruned by dropping it from the database, and<b=
r>
unpruned by adding it again. Since everything is committed to via cryptogra=
phic<br>
hash, we&#39;re guaranteed that regardless of where we get the data, after<=
br>
unpruning we&#39;ll have the right data.<br>
<br>
Let&#39;s look at how the TXO MMR works in detail. Consider the following T=
XO MMR<br>
with two txouts, which we&#39;ll call state #0:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 0<br>
=C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 a=C2=A0 =C2=A0b<br>
<br>
If we add another entry we get state #1:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 a=C2=A0 =C2=A0b=C2=A0 =C2=A0c<br>
<br>
Note how it 100% of the state #0 data was reused in commitment #1. Let&#39;=
s<br>
add two more entries to get state #2:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 a=C2=A0 =C2=A0b=C2=A0 =C2=A0c=C2=A0 =C2=A0d=C2=A0 =C2=A0e<br>
<br>
This time part of state #1 wasn&#39;t reused - it&#39;s wasn&#39;t a perfec=
t binary<br>
tree - but we&#39;ve still got a lot of re-use.<br>
<br>
Now suppose state #2 is committed into the blockchain by the most recent bl=
ock.<br>
Future transactions attempting to spend outputs created as of state #2 are<=
br>
obliged to prove that they are unspent; essentially they&#39;re forced to p=
rovide<br>
part of the state #2 MMR data. This lets us prune that data, discarding it,=
<br>
leaving us with only the bare minimum data we need to append new txouts to =
the<br>
TXO MMR, the tips of the perfect binary trees (&quot;mountains&quot;) withi=
n the MMR:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e<br>
<br>
Note that we&#39;re glossing over some nuance here about exactly what data =
needs to<br>
be kept; depending on the details of the implementation the only data we ne=
ed<br>
for nodes &quot;2&quot; and &quot;e&quot; may be their hash digest.<br>
<br>
Adding another three more txouts results in state #3:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 3=C2=A0 =C2=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0/ \=C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e=C2=
=A0 =C2=A0f=C2=A0 =C2=A0g=C2=A0 =C2=A0h<br>
<br>
Suppose recently created txout f is spent. We have all the data required to=
<br>
update the MMR, giving us state #4. It modifies two inner nodes and one lea=
f<br>
node:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A04<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 4=C2=A0 =C2=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0/ \=C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e=C2=
=A0 (f)=C2=A0 g=C2=A0 =C2=A0h<br>
<br>
If an archived txout is spent requires the transaction to provide the merkl=
e<br>
path to the most recently committed TXO, in our case state #2. If txout b i=
s<br>
spent that means the transaction must provide the following data from state=
 #2:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 0<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b<br>
<br>
We can add that data to our local knowledge of the TXO MMR, unpruning part =
of<br>
it:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A04<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A04=C2=A0 =C2=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0/ \=C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e=C2=
=A0 (f)=C2=A0 g=C2=A0 =C2=A0h<br>
<br>
Remember, we haven&#39;t _modified_ state #4 yet; we just have more data ab=
out it.<br>
When we mark txout b as spent we get state #5:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A04<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A04=C2=A0 =C2=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0/ \=C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(b)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e=C2=A0 (f=
)=C2=A0 g=C2=A0 =C2=A0h<br>
<br>
Secondly by now state #3 has been committed into the chain, and transaction=
s<br>
that want to spend txouts created as of state #3 must provide a TXO proof<b=
r>
consisting of state #3 data. The leaf nodes for outputs g and h, and the in=
ner<br>
node above them, are part of state #3, so we prune them:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A04<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A04<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(b)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e=C2=A0 (f=
)<br>
<br>
Finally, lets put this all together, by spending txouts a, c, and g, and<br=
>
creating three new txouts i, j, and k. State #3 was the most recently commi=
tted<br>
state, so the transactions spending a and g are providing merkle paths up t=
o<br>
it. This includes part of the state #2 data:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 a=C2=A0 =C2=A0 =C2=A0 =C2=A0c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0g<br>
<br>
After unpruning we have the following data for state #5:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A04<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=
=A04=C2=A0 =C2=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=
=C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 a=C2=A0 (b)=C2=A0 c=C2=A0 =C2=A0 =C2=A0 =C2=A0e=C2=A0 (f)=C2=
=A0 g<br>
<br>
That&#39;s sufficient to mark the three outputs as spent and add the three =
new<br>
txouts, resulting in state #6:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 6<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0/=C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=
=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=
=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A06=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/ \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \<br>
=C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A0 =C2=A0 =C2=A06=C2=A0 =C2=A0 =C2=A0 =C2=
=A04=C2=A0 =C2=A0 =C2=A0 =C2=A06=C2=A0 =C2=A0 =C2=A0 =C2=A06=C2=A0 =C2=A0\<=
br>
=C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=
=C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0(a) (b) (c)=C2=A0 =C2=A0 =C2=A0 e=C2=A0 (f) (g)=C2=A0 =C2=A0 =
=C2=A0 i=C2=A0 =C2=A0j=C2=A0 =C2=A0k<br>
<br>
Again, state #4 related data can be pruned. In addition, depending on how t=
he<br>
STXO set is implemented may also be able to prune data related to spent txo=
uts<br>
after that state, including inner nodes where all txouts under them have be=
en<br>
spent (more on pruning spent inner nodes later).<br>
<br>
<br>
### Consensus and Pruning<br>
<br>
It&#39;s important to note that pruning behavior is consensus critical: a f=
ull node<br>
that is missing data due to pruning it too soon will fall out of consensus,=
 and<br>
a miner that fails to include a merkle proof that is required by the consen=
sus<br>
is creating an invalid block. At the same time many full nodes will have<br=
>
significantly more data on hand than the bare minimum so they can help wall=
ets<br>
make transactions spending old coins; implementations should strongly consi=
der<br>
separating the data that is, and isn&#39;t, strictly required for consensus=
.<br>
<br>
A reasonable approach for the low-level cryptography may be to actually tre=
at<br>
the two cases differently, with the TXO commitments committing too what dat=
a<br>
does and does not need to be kept on hand by the UTXO expiration rules. On =
the<br>
other hand, leaving that uncommitted allows for certain types of soft-forks=
<br>
where the protocol is changed to require more data than it previously did.<=
br>
<br>
<br>
### Consensus Critical Storage Overheads<br>
<br>
Only the UTXO and STXO sets need to be kept on fast random access storage.<=
br>
Since STXO set entries can only be created by spending a UTXO - and are sma=
ller<br>
than a UTXO entry - we can guarantee that the peak size of the UTXO and STX=
O<br>
sets combined will always be less than the peak size of the UTXO set alone =
in<br>
the existing UTXO-only scheme (though the combined size can be temporarily<=
br>
higher than what the UTXO set size alone would be when large numbers of<br>
archived txouts are spent).<br>
<br>
TXO journal entries and unpruned entries in the TXO MMR have log2(n) maximu=
m<br>
overhead per entry: a unique merkle path to a TXO commitment (by &quot;uniq=
ue&quot; we<br>
mean that no other entry shares data with it). On a reasonably fast system =
the<br>
TXO journal will be flushed quickly, converting it into TXO MMR data; the T=
XO<br>
journal will never be more than a few blocks in size.<br>
<br>
Transactions spending non-archived txouts are not required to provide any T=
XO<br>
commitment data; we must have that data on hand in the form of one TXO MMR<=
br>
entry per UTXO. Once spent however the TXO MMR leaf node associated with th=
at<br>
non-archived txout can be immediately pruned - it&#39;s no longer in the UT=
XO set<br>
so any attempt to spend it will fail; the data is now immutable and we&#39;=
ll never<br>
need it again. Inner nodes in the TXO MMR can also be pruned if all leafs u=
nder<br>
them are fully spent; detecting this is easy the TXO MMR is a merkle-sum tr=
ee,<br>
with each inner node committing to the sum of the unspent txouts under it.<=
br>
<br>
When a archived txout is spent the transaction is required to provide a mer=
kle<br>
path to the most recent TXO commitment. As shown above that path is suffici=
ent<br>
information to unprune the necessary nodes in the TXO MMR and apply the spe=
nd<br>
immediately, reducing this case to the TXO journal size question (non-conse=
nsus<br>
critical overhead is a different question, which we&#39;ll address in the n=
ext<br>
section).<br>
<br>
Taking all this into account the only significant storage overhead of our T=
XO<br>
commitments scheme when compared to the status quo is the log2(n) merkle pa=
th<br>
overhead; as long as less than 1/log2(n) of the UTXO set is active,<br>
non-archived, UTXO&#39;s we&#39;ve come out ahead, even in the unrealistic =
case where<br>
all storage available is equally fast. In the real world that isn&#39;t yet=
 the<br>
case - even SSD&#39;s significantly slower than RAM.<br>
<br>
<br>
### Non-Consensus Critical Storage Overheads<br>
<br>
Transactions spending archived txouts pose two challenges:<br>
<br>
1) Obtaining up-to-date TXO commitment proofs<br>
<br>
2) Updating those proofs as blocks are mined<br>
<br>
The first challenge can be handled by specialized archival nodes, not unlik=
e<br>
how some nodes make transaction data available to wallets via bloom filters=
 or<br>
the Electrum protocol. There&#39;s a whole variety of options available, an=
d the<br>
the data can be easily sharded to scale horizontally; the data is<br>
self-validating allowing horizontal scaling without trust.<br>
<br>
While miners and relay nodes don&#39;t need to be concerned about the initi=
al<br>
commitment proof, updating that proof is another matter. If a node aggressi=
vely<br>
prunes old versions of the TXO MMR as it calculates pending TXO commitments=
, it<br>
won&#39;t have the data available to update the TXO commitment proof to be =
against<br>
the next block, when that block is found; the child nodes of the TXO MMR ti=
p<br>
are guaranteed to have changed, yet aggressive pruning would have discarded=
 that<br>
data.<br>
<br>
Relay nodes could ignore this problem if they simply accept the fact that<b=
r>
they&#39;ll only be able to fully relay the transaction once, when it is in=
itially<br>
broadcast, and won&#39;t be able to provide mempool functionality after the=
 initial<br>
relay. Modulo high-latency mixnets, this is probably acceptable; the author=
 has<br>
previously argued that relay nodes don&#39;t need a mempool=C2=B2 at all.<b=
r>
<br>
For a miner though not having the data necessary to update the proofs as bl=
ocks<br>
are found means potentially losing out on transactions fees. So how much ex=
tra<br>
data is necessary to make this a non-issue?<br>
<br>
Since the TXO MMR is insertion ordered, spending a non-archived txout can o=
nly<br>
invalidate the upper nodes in of the archived txout&#39;s TXO MMR proof (if=
 this<br>
isn&#39;t clear, imagine a two-level scheme, with a per-block TXO MMRs, com=
mitted<br>
by a master MMR for all blocks). The maximum number of relevant inner nodes=
<br>
changed is log2(n) per block, so if there are n non-archival blocks between=
 the<br>
most recent TXO commitment and the pending TXO MMR tip, we have to store<br=
>
log2(n)*n inner nodes - on the order of a few dozen MB even when n is a<br>
(seemingly ridiculously high) year worth of blocks.<br>
<br>
Archived txout spends on the other hand can invalidate TXO MMR proofs at an=
y<br>
level - consider the case of two adjacent txouts being spent. To guarantee<=
br>
success requires storing full proofs. However, they&#39;re limited by the b=
locksize<br>
limit, and additionally are expected to be relatively uncommon. For example=
, if<br>
1% of 1MB blocks was archival spends, our hypothetical year long TXO commit=
ment<br>
delay is only a few hundred MB of data with low-IO-performance requirements=
.<br>
<br>
<br>
## Security Model<br>
<br>
Of course, a TXO commitment delay of a year sounds ridiculous. Even the slo=
west<br>
imaginable computer isn&#39;t going to need more than a few blocks of TXO<b=
r>
commitment delay to keep up ~100% of the time, and there&#39;s no reason wh=
y we<br>
can&#39;t have the UTXO archive delay be significantly longer than the TXO<=
br>
commitment delay.<br>
<br>
However, as with UTXO commitments, TXO commitments raise issues with Bitcoi=
n&#39;s<br>
security model by allowing relatively miners to profitably mine transaction=
s<br>
without bothering to validate prior history. At the extreme, if there was n=
o<br>
commitment delay at all at the cost of a bit of some extra network bandwidt=
h<br>
&quot;full&quot; nodes could operate and even mine blocks completely statel=
essly by<br>
expecting all transactions to include &quot;proof&quot; that their inputs a=
re unspent; a<br>
TXO commitment proof for a commitment you haven&#39;t verified isn&#39;t a =
proof that a<br>
transaction output is unspent, it&#39;s a proof that some miners claimed th=
e txout<br>
was unspent.<br>
<br>
At one extreme, we could simply implement TXO commitments in a &quot;virtua=
l&quot;<br>
fashion, without miners actually including the TXO commitment digest in the=
ir<br>
blocks at all. Full nodes would be forced to compute the commitment from<br=
>
scratch, in the same way they are forced to compute the UTXO state, or tota=
l<br>
work. Of course a full node operator who doesn&#39;t want to verify old his=
tory can<br>
get a copy of the TXO state from a trusted source - no different from how y=
ou<br>
could get a copy of the UTXO set from a trusted source.<br>
<br>
A more pragmatic approach is to accept that people will do that anyway, and=
<br>
instead assume that sufficiently old blocks are valid. But how old is<br>
&quot;sufficiently old&quot;? First of all, if your full node implementatio=
n comes &quot;from<br>
the factory&quot; with a reasonably up-to-date minimum accepted total-work<=
br>
threshold=E2=81=B1 - in other words it won&#39;t accept a chain with less t=
han that amount<br>
of total work - it may be reasonable to assume any Sybil attacker with<br>
sufficient hashing power to make a forked chain meeting that threshold with=
,<br>
say, six months worth of blocks has enough hashing power to threaten the ma=
in<br>
chain as well.<br>
<br>
That leaves public attempts to falsify TXO commitments, done out in the ope=
n by<br>
the majority of hashing power. In this circumstance the &quot;assumed valid=
&quot;<br>
threshold determines how long the attack would have to go on before full no=
des<br>
start accepting the invalid chain, or at least, newly installed/recently re=
set<br>
full nodes. The minimum age that we can &quot;assume valid&quot; is tradeof=
f between<br>
political/social/technical concerns; we probably want at least a few weeks =
to<br>
guarantee the defenders a chance to organise themselves.<br>
<br>
With this in mind, a longer-than-technically-necessary TXO commitment delay=
=CA=B2<br>
may help ensure that full node software actually validates some minimum num=
ber<br>
of blocks out-of-the-box, without taking shortcuts. However this can be<br>
achieved in a wide variety of ways, such as the author&#39;s prev-block-pro=
of<br>
proposal=C2=B3, fraud proofs, or even a PoW with an inner loop dependent on=
<br>
blockchain data. Like UTXO commitments, TXO commitments are also potentiall=
y<br>
very useful in reducing the need for SPV wallet software to trust third par=
ties<br>
providing them with transaction data.<br>
<br>
i) Checkpoints that reject any chain without a specific block are a more<br=
>
=C2=A0 =C2=A0common, if uglier, way of achieving this protection.<br>
<br>
j) A good homework problem is to figure out how the TXO commitment could be=
<br>
=C2=A0 =C2=A0designed such that the delay could be reduced in a soft-fork.<=
br>
<br>
<br>
## Further Work<br>
<br>
While we&#39;ve shown that TXO commitments certainly could be implemented w=
ithout<br>
increasing peak IO bandwidth/block validation latency significantly with th=
e<br>
delayed commitment approach, we&#39;re far from being certain that they sho=
uld be<br>
implemented this way (or at all).<br>
<br>
1) Can a TXO commitment scheme be optimized sufficiently to be used directl=
y<br>
without a commitment delay? Obviously it&#39;d be preferable to avoid all t=
he above<br>
complexity entirely.<br>
<br>
2) Is it possible to use a metric other than age, e.g. priority? While this=
<br>
complicates the pruning logic, it could use the UTXO set space more<br>
efficiently, especially if your goal is to prioritise bitcoin value-transfe=
r<br>
over other uses (though if &quot;normal&quot; wallets nearly never need to =
use TXO<br>
commitments proofs to spend outputs, the infrastructure to actually do this=
 may<br>
rot).<br>
<br>
3) Should UTXO archiving be based on a fixed size UTXO set, rather than an<=
br>
age/priority/etc. threshold?<br>
<br>
4) By fixing the problem (or possibly just &quot;fixing&quot; the problem) =
are we<br>
encouraging/legitimising blockchain use-cases other than BTC value transfer=
?<br>
Should we?<br>
<br>
5) Instead of TXO commitment proofs counting towards the blocksize limit, c=
an<br>
we use a different miner fairness/decentralization metric/incentive? For<br=
>
instance it might be reasonable for the TXO commitment proof size to be<br>
discounted, or ignored entirely, if a proof-of-propagation scheme (e.g.<br>
thinblocks) is used to ensure all miners have received the proof in advance=
.<br>
<br>
6) How does this interact with fraud proofs? Obviously furthering dependenc=
y on<br>
non-cryptographically-committed STXO/UTXO databases is incompatible with th=
e<br>
modularized validation approach to implementing fraud proofs.<br>
<br>
<br>
# References<br>
<br>
1) &quot;Merkle Mountain Ranges&quot;,<br>
=C2=A0 =C2=A0Peter Todd, OpenTimestamps, Mar 18 2013,<br>
=C2=A0 =C2=A0<a href=3D"https://github.com/opentimestamps/opentimestamps-se=
rver/blob/master/doc/merkle-mountain-range.md" rel=3D"noreferrer" target=3D=
"_blank">https://github.com/opentimestamps/opentimestamps-server/blob/maste=
r/doc/merkle-mountain-range.md</a><br>
<br>
2) &quot;Do we really need a mempool? (for relay nodes)&quot;,<br>
=C2=A0 =C2=A0Peter Todd, bitcoin-dev mailing list, Jul 18th 2015,<br>
=C2=A0 =C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2015-July/009479.html" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009479.html</a><br>
<br>
3) &quot;Segregated witnesses and validationless mining&quot;,<br>
=C2=A0 =C2=A0Peter Todd, bitcoin-dev mailing list, Dec 23rd 2015,<br>
=C2=A0 =C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2015-December/012103.html" rel=3D"noreferrer" target=3D"_blank">https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.html=
</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a11c3fd1240a58205330a34ee--