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: Sat, 8 Apr 2017 00:44:50 +0000 [thread overview]
Message-ID: <CAAS2fgTWyX5M-xcELC2vDvGfs01tbGYkpZJCSeNbvn_p4Ecjqg@mail.gmail.com> (raw)
In-Reply-To: <1491599691.1245876.937920664.6EBA20DC@webmail.messagingengine.com>
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).
next prev parent reply other threads:[~2017-04-08 0:44 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 22:12 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
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 [this message]
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=CAAS2fgTWyX5M-xcELC2vDvGfs01tbGYkpZJCSeNbvn_p4Ecjqg@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomas@tomasvdw$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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