summaryrefslogtreecommitdiff
path: root/fb/b9ac70b3934ad5ea5acfa96768d90beb9d8b04
blob: 5a0c3872fe557657ee05012a7837b6d00ed5050f (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
Return-Path: <tomas@tomasvdw.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9664C481
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 22:21:00 +0000 (UTC)
X-Greylist: delayed 00:08:31 by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
	[66.111.4.25])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 508C27C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 22:20:59 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
	by mailout.nyi.internal (Postfix) with ESMTP id 6B74220911
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 18:12:27 -0400 (EDT)
Received: from web3 ([10.202.2.213])
	by compute2.internal (MEProxy); Thu, 06 Apr 2017 18:12:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:message-id:mime-version:subject:to:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm1; bh=1YXMw0S6vspMW44oa4nNWlE9NSspC
	MSl0crx2KgiWD8=; b=KMtbf7vw2ik8oKiG4X4aaatRxzm6DEecSlk/xm5+rrO8a
	1kqwCfl1gqhukJHPtNjVGzd6WX6uuOPLlYBQyAPlF3ieIrMZOrabv4IH02iwbifL
	u+LkOJqX35uziPiepXVVK5hMfios9Jvlc6IN9wOYDulJUpYTqU/VyzRUUDDRN0d8
	yTFsBYctSG1jkVoOjTns492618Fmw3tOEo62gklV3uaGBJKHc3KGLzvOLFuvPjrU
	gMvSH7S09Z2DoQgLCdkIX+PZk7OE2JO4H94MAPv4WNW0IOBeT/LXhnu9DAY+UG3d
	Ev7Wxr5hx9iAZ04lWtFcXPu3BtWYZeUP4k5eoNLPg==
X-ME-Sender: <xms:S73mWCO_m2G1KOite5XyfyX-Y01eaYLJI79Np0irTGPT_RDV4a_UHQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
	id 463A69EC32; Thu,  6 Apr 2017 18:12:27 -0400 (EDT)
Message-Id: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-8e6aa83c
Date: Fri, 07 Apr 2017 00:12:27 +0200
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, RCVD_IN_DNSWL_LOW, URIBL_RHS_DOB autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 06 Apr 2017 22:24:56 +0000
Subject: [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: Thu, 06 Apr 2017 22:21:00 -0000

I have been working on a bitcoin implementation that uses a different
approach to indexing for verifying the order of transactions. Instead of
using an index of unspent outputs, double spends are verified by using a
spend-tree where spends are scanned against spent outputs instead of
unspent outputs.

This allows for much better concurrency, as not only blocks, but also
individual inputs can be verified fully in parallel.

I explain the approach at https://bitcrust.org, source code is available
at https://github.com/tomasvdw/bitcrust

I am sharing this not only to ask for your feedback, but also to call
for a clear separation of protocol and implementations: 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* and it might be best to address
these concerns as implementation details.

Kind regards,
Tomas van der Wansem
tomas@bitcrust.org
Bitcrust