MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <1491599691.1245876.937920664.6EBA20DC@webmail.messagingengine.com>
References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com>
	<CAAS2fgTJ8xOj8zCmBq1LN9OdMV-tDfSjVUPhLpO98cR1w-QAoA@mail.gmail.com>
	<CA+KqGko0cDY29bhznMxJJ7yAUTuB6GaDDNGBRwzssJUxM_53xQ@mail.gmail.com>
	<1491599691.1245876.937920664.6EBA20DC@webmail.messagingengine.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Sat, 8 Apr 2017 00:44:50 +0000
Message-ID: <CAAS2fgTWyX5M-xcELC2vDvGfs01tbGYkpZJCSeNbvn_p4Ecjqg@mail.gmail.com>
To: Tomas <tomas@tomasvdw.nl>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index
Precedence: list

On Fri, Apr 7, 2017 at 9:14 PM, Tomas <tomas@tomasvdw.nl> wrote:
> The long term *minimal disk storage* requirement, can obviously not be less
> then all the unspent outputs.

Then I think you may want to retract the claim that "As this solution,
reversing the costs of outputs and inputs, [...] updates to the
protocol addressing the UTXO growth, might not be worth considering
*protocol improvements* "

As you note that the output costs still bound the resource
requirements. Short of radical protocol changes like TXO-proofs the
UTXO data remains a driving unavoidable long term resource cost, not
an implementation detail.  Implementation optimizations like improving
locality further or keeping spentness in memory do not change this
fact.

> The storage that is accessed during peak load (block validation with
> pre-synced transactions), is minimized as this only needs the transaction
> index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of

Latency related costs in Bitcoin Core also do not depend on the number
of outputs in transactions in a block. When a transaction is handled
it goes into an in-memory buffer and only gets flushed later if isn't
spent before the buffer fills.  A block will take more time to
validate with more inputs, same as you observer, but the aggregate
resource usage for users depends significantly on outputs (so, in fact
there is even further misaligned incentives than just the fact that
small outputs have a outsized long term cost).