<p dir="ltr">What if two people create transactions from oupoints within the same MMR tree tip, at the same time?</p>
<p dir="ltr">For example, I create transaction A plus an MMR proof that MMR tip X will become Y.</p>
<p dir="ltr">On the other side of the planet, someone else creates transaction B, plus an MMR proof that tip X will become Z.</p>
<p dir="ltr">Can a miner who receives A and B put both into a block, without access to the outputs that were pruned? </p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"># Motivation<br>
<br>
UTXO growth is a serious concern for Bitcoin's long-term decentralization. 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, competitors<br>
will have the UTXO set in RAM. Mining is a zero-sum game, so the extra latency<br>
of not doing so if they do directly impacts your profit margin. Secondly,<br>
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<br>
number of factors, including the fact that there is little incentive to merge<br>
inputs, lost coins, dust outputs that can't be economically spent, and<br>
non-btc-value-transfer "blockchain" use-cases such as anti-replay oracles and<br>
timestamping.<br>
<br>
We don't have good tools to combat UTXO growth. Segregated Witness proposes to<br>
give witness space a 75% discount, in part of make reducing the UTXO set size<br>
by spending txouts cheaper. While this may change wallets to more often spend<br>
dust, it's hard to imagine an incentive sufficiently strong to discourage 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 that<br>
the data required to reconstruct the timestamp proof won't get lost - all<br>
Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay<br>
use-cases like using the UTXO set for key rotation piggyback on the uniquely<br>
strong security and decentralization guarantee that Bitcoin provides; it's very<br>
difficult - perhaps impossible - to provide these applications with<br>
alternatives that are equally secure. These non-btc-value-transfer use-cases<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 register<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 as<br>
"spam" 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, and<br>
make the issue of UTXO "spam" less important. However, making any coins<br>
unspendable, regardless of age or value, is a politically untenable economic<br>
change.<br>
<br>
<br>
# TXO Commitments<br>
<br>
A merkle tree committing to the state of all transaction outputs, both spent<br>
and unspent, we can provide a method of compactly proving the current state of<br>
an output. This lets us "archive" 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 the<br>
outputs are in fact unspent.<br>
<br>
Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a<br>
type of deterministic, indexable, insertion ordered merkle tree, which allows<br>
new items to be cheaply appended to the tree with minimal storage requirements,<br>
just log2(n) "mountain tips". 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 the<br>
state of a specific item in the MMR, as well the validity of changes to items<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 to<br>
spend were still unspent; nodes could update the state of the TXO MMR purely<br>
from TXO commitment proofs. However, the log2(n) bandwidth overhead per txin 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 (rare)<br>
event that an old txout needs to be spent.<br>
<br>
Proofs can be generated and added to transactions without the involvement of<br>
the signers, even after the fact; there's no need for the proof itself to<br>
signed and the proof is not part of the transaction hash. Anyone with access to<br>
TXO MMR data can (re)generate missing proofs, so minimal, if any, changes are<br>
required to wallet software to make use of TXO commitments.<br>
<br>
<br>
## Delayed Commitments<br>
<br>
TXO commitments aren't a new idea - the author proposed them years ago in<br>
response to UTXO commitments. However it's critical for small miners' 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, outputs.<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 for<br>
the n block delay. Since that commitment only depends on the contents of the<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>
Low-latency K:V map of txouts definitely known to be unspent. Similar to<br>
existing UTXO implementation, but with the key difference that old,<br>
unspent, outputs may be pruned from the UTXO set.<br>
<br>
<br>
2) STXO set<br>
<br>
Low-latency set of transaction outputs known to have been spent by<br>
transactions after the most recent TXO commitment, but created prior to the<br>
TXO commitment.<br>
<br>
<br>
3) TXO journal<br>
<br>
FIFO of outputs that need to be marked as spent in the TXO MMR. Appends<br>
must be low-latency; removals can be high-latency.<br>
<br>
<br>
4) TXO MMR list<br>
<br>
Prunable, ordered list of TXO MMR's, mainly the highest pending commitment,<br>
backed by a reference counted, cryptographically hashed object store<br>
indexed by digest (similar to how git repos work). High-latency ok. We'll<br>
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>
Output created after the most recent TXO commitment, so it should be in the<br>
UTXO set; the transaction spending it does not need a TXO commitment proof.<br>
Remove the output from the UTXO set and append it to the TXO journal.<br>
<br>
2) Archived output<br>
<br>
Output created prior to the most recent TXO commitment, so there's no<br>
guarantee it's in the UTXO set; transaction will have a TXO commitment<br>
proof for the most recent TXO commitment showing that it was unspent.<br>
Check that the output isn't already in the STXO set (double-spent), and if<br>
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:value<br>
updates, and one journal append. The existing UTXO set requires one key:value<br>
update per spend, so we can expect new block validation latency to be within 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<br>
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's that<br>
have been recorded in TXO commitments, and prunes TXO commitment data no longer<br>
needed.<br>
<br>
Throughput for the TXO commitment calculation will be worse than the existing<br>
UTXO only scheme. This impacts bulk verification, e.g. initial block download.<br>
That said, TXO commitments provides other possible tradeoffs that can mitigate<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 information<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 collection.<br>
Data no longer needed can be pruned by dropping it from the database, and<br>
unpruned by adding it again. Since everything is committed to via cryptographic<br>
hash, we're guaranteed that regardless of where we get the data, after<br>
unpruning we'll have the right data.<br>
<br>
Let's look at how the TXO MMR works in detail. Consider the following TXO MMR<br>
with two txouts, which we'll call state #0:<br>
<br>
0<br>
/ \<br>
a b<br>
<br>
If we add another entry we get state #1:<br>
<br>
1<br>
/ \<br>
0 \<br>
/ \ \<br>
a b c<br>
<br>
Note how it 100% of the state #0 data was reused in commitment #1. Let's<br>
add two more entries to get state #2:<br>
<br>
2<br>
/ \<br>
2 \<br>
/ \ \<br>
/ \ \<br>
/ \ \<br>
0 2 \<br>
/ \ / \ \<br>
a b c d e<br>
<br>
This time part of state #1 wasn't reused - it's wasn't a perfect binary<br>
tree - but we've still got a lot of re-use.<br>
<br>
Now suppose state #2 is committed into the blockchain by the most recent block.<br>
Future transactions attempting to spend outputs created as of state #2 are<br>
obliged to prove that they are unspent; essentially they're forced to provide<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 ("mountains") within the MMR:<br>
<br>
2<br>
/ \<br>
2 \<br>
\<br>
\<br>
\<br>
\<br>
\<br>
e<br>
<br>
Note that we'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 need<br>
for nodes "2" and "e" may be their hash digest.<br>
<br>
Adding another three more txouts results in state #3:<br>
<br>
3<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
2 3<br>
/ \<br>
/ \<br>
/ \<br>
3 3<br>
/ \ / \<br>
e f g h<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 leaf<br>
node:<br>
<br>
4<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
2 4<br>
/ \<br>
/ \<br>
/ \<br>
4 3<br>
/ \ / \<br>
e (f) g h<br>
<br>
If an archived txout is spent requires the transaction to provide the merkle<br>
path to the most recently committed TXO, in our case state #2. If txout b is<br>
spent that means the transaction must provide the following data from state #2:<br>
<br>
2<br>
/<br>
2<br>
/<br>
/<br>
/<br>
0<br>
\<br>
b<br>
<br>
We can add that data to our local knowledge of the TXO MMR, unpruning part of<br>
it:<br>
<br>
4<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
2 4<br>
/ / \<br>
/ / \<br>
/ / \<br>
0 4 3<br>
\ / \ / \<br>
b e (f) g h<br>
<br>
Remember, we haven't _modified_ state #4 yet; we just have more data about it.<br>
When we mark txout b as spent we get state #5:<br>
<br>
5<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
5 4<br>
/ / \<br>
/ / \<br>
/ / \<br>
5 4 3<br>
\ / \ / \<br>
(b) e (f) g h<br>
<br>
Secondly by now state #3 has been committed into the chain, and transactions<br>
that want to spend txouts created as of state #3 must provide a TXO proof<br>
consisting of state #3 data. The leaf nodes for outputs g and h, and the inner<br>
node above them, are part of state #3, so we prune them:<br>
<br>
5<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
5 4<br>
/ /<br>
/ /<br>
/ /<br>
5 4<br>
\ / \<br>
(b) e (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 committed<br>
state, so the transactions spending a and g are providing merkle paths up to<br>
it. This includes part of the state #2 data:<br>
<br>
3<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
2 3<br>
/ \ \<br>
/ \ \<br>
/ \ \<br>
0 2 3<br>
/ / /<br>
a c g<br>
<br>
After unpruning we have the following data for state #5:<br>
<br>
5<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
5 4<br>
/ \ / \<br>
/ \ / \<br>
/ \ / \<br>
5 2 4 3<br>
/ \ / / \ /<br>
a (b) c e (f) g<br>
<br>
That's sufficient to mark the three outputs as spent and add the three new<br>
txouts, resulting in state #6:<br>
<br>
6<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
/ \<br>
6 \<br>
/ \ \<br>
/ \ \<br>
/ \ \<br>
/ \ \<br>
/ \ \<br>
/ \ \<br>
/ \ \<br>
6 6 \<br>
/ \ / \ \<br>
/ \ / \ 6<br>
/ \ / \ / \<br>
6 6 4 6 6 \<br>
/ \ / / \ / / \ \<br>
(a) (b) (c) e (f) (g) i j k<br>
<br>
Again, state #4 related data can be pruned. In addition, depending on how the<br>
STXO set is implemented may also be able to prune data related to spent txouts<br>
after that state, including inner nodes where all txouts under them have been<br>
spent (more on pruning spent inner nodes later).<br>
<br>
<br>
### Consensus and Pruning<br>
<br>
It's important to note that pruning behavior is consensus critical: a full 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 consensus<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 wallets<br>
make transactions spending old coins; implementations should strongly consider<br>
separating the data that is, and isn't, strictly required for consensus.<br>
<br>
A reasonable approach for the low-level cryptography may be to actually treat<br>
the two cases differently, with the TXO commitments committing too what data<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 smaller<br>
than a UTXO entry - we can guarantee that the peak size of the UTXO and STXO<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) maximum<br>
overhead per entry: a unique merkle path to a TXO commitment (by "unique" 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 TXO<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 TXO<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 that<br>
non-archived txout can be immediately pruned - it's no longer in the UTXO set<br>
so any attempt to spend it will fail; the data is now immutable and we'll never<br>
need it again. Inner nodes in the TXO MMR can also be pruned if all leafs under<br>
them are fully spent; detecting this is easy the TXO MMR is a merkle-sum tree,<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 merkle<br>
path to the most recent TXO commitment. As shown above that path is sufficient<br>
information to unprune the necessary nodes in the TXO MMR and apply the spend<br>
immediately, reducing this case to the TXO journal size question (non-consensus<br>
critical overhead is a different question, which we'll address in the next<br>
section).<br>
<br>
Taking all this into account the only significant storage overhead of our TXO<br>
commitments scheme when compared to the status quo is the log2(n) merkle path<br>
overhead; as long as less than 1/log2(n) of the UTXO set is active,<br>
non-archived, UTXO's we've come out ahead, even in the unrealistic case where<br>
all storage available is equally fast. In the real world that isn't yet the<br>
case - even SSD'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 unlike<br>
how some nodes make transaction data available to wallets via bloom filters or<br>
the Electrum protocol. There's a whole variety of options available, and 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't need to be concerned about the initial<br>
commitment proof, updating that proof is another matter. If a node aggressively<br>
prunes old versions of the TXO MMR as it calculates pending TXO commitments, it<br>
won'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 tip<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<br>
they'll only be able to fully relay the transaction once, when it is initially<br>
broadcast, and won'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't need a mempool² at all.<br>
<br>
For a miner though not having the data necessary to update the proofs as blocks<br>
are found means potentially losing out on transactions fees. So how much extra<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 only<br>
invalidate the upper nodes in of the archived txout's TXO MMR proof (if this<br>
isn't clear, imagine a two-level scheme, with a per-block TXO MMRs, committed<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 any<br>
level - consider the case of two adjacent txouts being spent. To guarantee<br>
success requires storing full proofs. However, they're limited by the blocksize<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 commitment<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 slowest<br>
imaginable computer isn't going to need more than a few blocks of TXO<br>
commitment delay to keep up ~100% of the time, and there's no reason why we<br>
can'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 Bitcoin's<br>
security model by allowing relatively miners to profitably mine transactions<br>
without bothering to validate prior history. At the extreme, if there was no<br>
commitment delay at all at the cost of a bit of some extra network bandwidth<br>
"full" nodes could operate and even mine blocks completely statelessly by<br>
expecting all transactions to include "proof" that their inputs are unspent; a<br>
TXO commitment proof for a commitment you haven't verified isn't a proof that a<br>
transaction output is unspent, it's a proof that some miners claimed the txout<br>
was unspent.<br>
<br>
At one extreme, we could simply implement TXO commitments in a "virtual"<br>
fashion, without miners actually including the TXO commitment digest in their<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 total<br>
work. Of course a full node operator who doesn't want to verify old history can<br>
get a copy of the TXO state from a trusted source - no different from how you<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>
"sufficiently old"? First of all, if your full node implementation comes "from<br>
the factory" with a reasonably up-to-date minimum accepted total-work<br>
thresholdⁱ - in other words it won't accept a chain with less than 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 main<br>
chain as well.<br>
<br>
That leaves public attempts to falsify TXO commitments, done out in the open by<br>
the majority of hashing power. In this circumstance the "assumed valid"<br>
threshold determines how long the attack would have to go on before full nodes<br>
start accepting the invalid chain, or at least, newly installed/recently reset<br>
full nodes. The minimum age that we can "assume valid" is tradeoff 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ʲ<br>
may help ensure that full node software actually validates some minimum number<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's prev-block-proof<br>
proposal³, fraud proofs, or even a PoW with an inner loop dependent on<br>
blockchain data. Like UTXO commitments, TXO commitments are also potentially<br>
very useful in reducing the need for SPV wallet software to trust third parties<br>
providing them with transaction data.<br>
<br>
i) Checkpoints that reject any chain without a specific block are a more<br>
common, 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>
designed such that the delay could be reduced in a soft-fork.<br>
<br>
<br>
## Further Work<br>
<br>
While we've shown that TXO commitments certainly could be implemented without<br>
increasing peak IO bandwidth/block validation latency significantly with the<br>
delayed commitment approach, we're far from being certain that they should be<br>
implemented this way (or at all).<br>
<br>
1) Can a TXO commitment scheme be optimized sufficiently to be used directly<br>
without a commitment delay? Obviously it'd be preferable to avoid all the 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-transfer<br>
over other uses (though if "normal" 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 "fixing" 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, can<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 dependency on<br>
non-cryptographically-committed STXO/UTXO databases is incompatible with the<br>
modularized validation approach to implementing fraud proofs.<br>
<br>
<br>
# References<br>
<br>
1) "Merkle Mountain Ranges",<br>
Peter Todd, OpenTimestamps, Mar 18 2013,<br>
<a href="https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md" rel="noreferrer" target="_blank">https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md</a><br>
<br>
2) "Do we really need a mempool? (for relay nodes)",<br>
Peter Todd, bitcoin-dev mailing list, Jul 18th 2015,<br>
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009479.html" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009479.html</a><br>
<br>
3) "Segregated witnesses and validationless mining",<br>
Peter Todd, bitcoin-dev mailing list, Dec 23rd 2015,<br>
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.html" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.html</a><br>
<br>
--<br>
<a href="https://petertodd.org" rel="noreferrer" target="_blank">https://petertodd.org</a> 'peter'[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br></div>