From: Gregory Maxwell <greg@xiph.org>
To: Tomas <tomas@tomasvdw.nl>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index
Date: Fri, 7 Apr 2017 01:09:26 +0000 [thread overview]
Message-ID: <CAAS2fgR0t=QG6HfhF1MKW3k_4mjv7rjWE4T3-wdiL2fB6TVV4Q@mail.gmail.com> (raw)
In-Reply-To: <1491526132.723002.936945760.06A943C6@webmail.messagingengine.com>
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?
next prev parent reply other threads:[~2017-04-07 1:09 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 22:12 [bitcoin-dev] Using a storage engine without UTXO-index Tomas
2017-04-06 23:38 ` Eric Voskuil
2017-04-07 0:17 ` Tomas
2017-04-08 22:37 ` Eric Voskuil
2017-04-08 23:58 ` Tomas
2017-04-11 1:44 ` Eric Voskuil
2017-04-11 8:43 ` Tomas
2017-04-11 9:41 ` Eric Voskuil
2017-04-11 10:04 ` Tomas
[not found] ` <CAAS2fgTEMCkDWdhCWt1EsUrnt3+Z_8m+Y1PTsff5Rc0CBnCKWQ@mail.gmail.com>
2017-04-07 0:48 ` Tomas
2017-04-07 1:09 ` Gregory Maxwell [this message]
2017-04-07 1:29 ` Tomas
2017-04-07 18:52 ` Tom Harding
2017-04-07 19:42 ` Gregory Maxwell
2017-04-08 18:27 ` Tom Harding
2017-04-08 19:23 ` Tomas
2017-04-07 7:55 ` Marcos mayorga
2017-04-07 8:47 ` Tomas
2017-04-07 14:14 ` Greg Sanders
2017-04-07 16:02 ` Tomas
2017-04-07 18:18 ` Gregory Maxwell
2017-04-07 18:39 ` Bram Cohen
2017-04-07 19:55 ` Eric Voskuil
2017-04-07 21:44 ` Tomas
2017-04-07 23:51 ` Eric Voskuil
2017-04-07 21:14 ` Tomas
2017-04-08 0:44 ` Gregory Maxwell
2017-04-08 7:28 ` Tomas
2017-04-08 19:23 ` Johnson Lau
2017-04-08 19:56 ` Tomas
2017-04-08 20:21 ` Johnson Lau
2017-04-08 20:42 ` Tomas
2017-04-08 22:12 ` Gregory Maxwell
2017-04-08 22:34 ` Tomas
2017-04-08 21:22 ` Troy Benjegerdes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgR0t=QG6HfhF1MKW3k_4mjv7rjWE4T3-wdiL2fB6TVV4Q@mail.gmail.com' \
--to=greg@xiph.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tomas@tomasvdw.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox