summaryrefslogtreecommitdiff
path: root/d0/28cb50dd8d7d89fa386b346e78cd8222d36996
blob: 3ec4e921a627260dcf0413b7564dcb90e6d0e484 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 677B9BD3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Apr 2017 18:39:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
	[209.85.223.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C26571D8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Apr 2017 18:39:19 +0000 (UTC)
Received: by mail-io0-f182.google.com with SMTP id b140so55089127iof.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 07 Apr 2017 11:39:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=14OfQiRQLSHQcFKmrWc4GInVkf4brfY89B3+4jt6GCE=;
	b=reDQxjlyS4tncBvifDCWuk7I+e8j1tnqdahNjoyIwflc+nZn2e7M5C38j1thBP10lA
	6ol9SaKaDNcaZv8SYt/sABYYBTIALd7//IZ1z5VlYw0ffUqOrODKbRKW7zZcM13q1gbj
	4cuwfKfp3Ay+tdtpjHl+0VfeTtPk5RV1ATX5OaGi6M9OHCZ+UfMTOGSvNtuyNJBr5x3y
	yzCCCR+uC1I5lpz1GxFBLO22ylj8WMsjojd+xZxI2eTWJyhE98iwt55DO4cySDrzkEWy
	zdZk7uREOn+0j6ts5arRIrKu78cwKgUzH/0C1j0KoxA7iT0sLbGTxn5S9y7H+HYbGAw6
	ZLJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=14OfQiRQLSHQcFKmrWc4GInVkf4brfY89B3+4jt6GCE=;
	b=lppJh7n9mfyQGE5cIHrhdsYbFMs5IRn/xrgBl5jBLRchQ6PaZdoBKZqYxDz4npu9Is
	DcqTcEE18V6gaK7J06KSZl93TnpjwXnMN67ExfKyBjCn/TfBqMzFNNq91Yj7WEvnXDdk
	ZUZMM/QqW+Vum9NW+qSSsT5TnHcCGC5uEJiJKYh1+qWqy67YTE1fM3QOnob6rtSSL/p5
	zOEo99oDdcEvtoWQy/csfr6pRYsaPOGneSRhYeqKDxijdG6q7q29tlXt2gdWyxSqGz+k
	Y5nbOOfkdfBAmqBl3o7KgOKF0favAR+xS5dYvNp5G+G1Ceh1DbfUBGcEsQOT71JdSJdM
	2Wpw==
X-Gm-Message-State: AFeK/H2bWcQAAnZnt81ztVlOf5HCLrRnh46CH0Uip+AZQayGjT5w8dT03t2yBymAwerDyBgnKK2k28gR2etqmT2B
X-Received: by 10.107.50.206 with SMTP id y197mr41722232ioy.214.1491590359201; 
	Fri, 07 Apr 2017 11:39:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.184.70 with HTTP; Fri, 7 Apr 2017 11:39:18 -0700 (PDT)
In-Reply-To: <CAAS2fgTJ8xOj8zCmBq1LN9OdMV-tDfSjVUPhLpO98cR1w-QAoA@mail.gmail.com>
References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com>
	<CAAS2fgTJ8xOj8zCmBq1LN9OdMV-tDfSjVUPhLpO98cR1w-QAoA@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Fri, 7 Apr 2017 11:39:18 -0700
Message-ID: <CA+KqGko0cDY29bhznMxJJ7yAUTuB6GaDDNGBRwzssJUxM_53xQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1144795482f3dc054c97f149
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 18:39:20 -0000

--001a1144795482f3dc054c97f149
Content-Type: text/plain; charset=UTF-8

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
>

--001a1144795482f3dc054c97f149
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Expanding on this question a bit, it&#39;s optimized for p=
arallel access, but hard drive access isn&#39;t parallel and memory accesse=
s are very fast, so shouldn&#39;t the target of optimization be about cramm=
ing as much as possible in memory and minimizing disk accesses?</div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr 7, 2017 at =
11:18 AM, Gregory Maxwell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"">On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin=
-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;As this<br>
&gt; solution, reversing the costs of outputs and inputs, seems to have<br>
&gt; excellent performance characteristics (as shown in the test results),<=
br>
&gt; updates to the protocol addressing the UTXO growth, might not be worth=
<br>
&gt; considering *protocol improvements*<br>
<br>
</span>I&#39;m still lost on this-- AFAICT your proposals long term resourc=
e<br>
requirements are directly proportional to the amount of unspent output<br>
data, which grows over time at some fraction of the total transaction<br>
volume (plus the rate of spending which is more or less a constant).<br>
<br>
Can you help out my understanding here?<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--001a1144795482f3dc054c97f149--