From: Bram Cohen <bram@bittorrent•com>
To: Gregory Maxwell <greg@xiph•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index
Date: Fri, 7 Apr 2017 11:39:18 -0700 [thread overview]
Message-ID: <CA+KqGko0cDY29bhznMxJJ7yAUTuB6GaDDNGBRwzssJUxM_53xQ@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTJ8xOj8zCmBq1LN9OdMV-tDfSjVUPhLpO98cR1w-QAoA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
Expanding on this question a bit, it's optimized for parallel access, but
hard drive access isn't parallel and memory accesses are very fast, so
shouldn't the target of optimization be about cramming as much as possible
in memory and minimizing disk accesses?
On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >As this
> > solution, reversing the costs of outputs and inputs, seems to have
> > excellent performance characteristics (as shown in the test results),
> > updates to the protocol addressing the UTXO growth, might not be worth
> > considering *protocol improvements*
>
> I'm still lost on this-- AFAICT your proposals long term resource
> requirements are directly proportional to the amount of unspent output
> data, which grows over time at some fraction of the total transaction
> volume (plus the rate of spending which is more or less a constant).
>
> Can you help out my understanding here?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1991 bytes --]
next prev parent reply other threads:[~2017-04-07 18:39 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 [this message]
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=CA+KqGko0cDY29bhznMxJJ7yAUTuB6GaDDNGBRwzssJUxM_53xQ@mail.gmail.com \
--to=bram@bittorrent$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
/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