MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <1491526132.723002.936945760.06A943C6@webmail.messagingengine.com>
References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com>
	<CAAS2fgTEMCkDWdhCWt1EsUrnt3+Z_8m+Y1PTsff5Rc0CBnCKWQ@mail.gmail.com>
	<1491526132.723002.936945760.06A943C6@webmail.messagingengine.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 7 Apr 2017 01:09:26 +0000
Message-ID: <CAAS2fgR0t=QG6HfhF1MKW3k_4mjv7rjWE4T3-wdiL2fB6TVV4Q@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 12:48 AM, Tomas <tomas@tomasvdw.nl> wrote:
> Bitcrust separates script validation (base load, when transaction come
> in) from order validation (peak load, when blocks come in).

How do you deal with validity rules changing based on block height?

> For script validation it would obviously need the ~2GB (or I think
> ~1.5GB) of outputs needed to validate these.

So it sounds like to work the software still needs an analog of a
(U)TXO database? I am confused by the earlier comments about thinking
the the resource consumption of the (U)TXO database is not a
consideration in your design.

> For order validation it
> needs ~200mb or the spent-index (for bit-lookups) and I would guess
> roughly ~500mb of the spent-tree (for scanning), though I don't think
> the 5.7GB full spend tree isn't worth pruning anytime soon.

If you get a transaction claiming to spend 0xDEADBEEFDEADBEEF, an
output that never existed how does your spent index reject this spend?