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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1RbouA-0003c5-Tk
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 07:42:02 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=elombrozo@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rbou9-0006oQ-U4
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 07:42:02 +0000
Received: by vbbfc21 with SMTP id fc21so4279024vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 23:41:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.94.97 with SMTP id db1mr8373888vdb.16.1324107716362; Fri,
16 Dec 2011 23:41:56 -0800 (PST)
Received: by 10.52.162.6 with HTTP; Fri, 16 Dec 2011 23:41:56 -0800 (PST)
Date: Fri, 16 Dec 2011 23:41:56 -0800
Message-ID: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(elombrozo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Rbou9-0006oQ-U4
Subject: [Bitcoin-development] Protocol extensions
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2011 07:42:03 -0000
Hey, guys.
I haven't posted here before so I'll introduce myself. My name's Eric,
I've been developing cryptocurrency-related
software for several months now, I've implemented some libraries for
dealing with core bitcoin datastructures, made
some custom builds of bitcoind and interfaced it with a few apps I've written.
In doing so, I've come to appreciate just how little of the potential
for the bitcoin protocol is being exploited right now...
not only in terms of the script features but in terms of the potential
commands and node types that could exist.
For instance, the protocol spec at
https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands
listed and
only one service type...despite having a full 12 bytes for a command
code and a full eight bytes for a services
type.
The fact that only one node service type is specified is probably due
to the fact that the satoshi client was written
to be a standalone monolithic app that took care of all the essential
needs for a network of peers.
i.e. block chain storage/management, transaction signing/verification,
key generation/wallet management, block mining, etc...
However, I think there's an urgent need for breaking up all these
different tasks into separate components that can run as independent
services on different types of devices.
One of the big issues I'm dealing with now pertains to block chain
storage. As of right now, it is implemented as sequential
disk files using Berkeley DB in the satoshi client. Then you have
other projects that have been using SQL tables, etc...
But I believe the direction this really needs to move towards is some
sort of distributed hash table...and the database queries
should be performed using the bitcoin protocol itself. Perhaps adding
a few more commands. As things stand right now,
the only way to query for transactions or blocks is by their hash. And
once a transaction gets incorporated into a block and
removed from the transaction pool, one can no longer query it by the
transaction hash without stepping outside the bitcoin protocol.
We need access to the disk file that stores the blocks whether it be
via Berkeley DB or SQL or whatever.
I propose an extension to the bitcoin protocol to provide methods for
performing more sophisticated queries, such as "Give me
an inventory of transactions involving this particular public key" or
"Give me an inventory all transactions in the last n blocks with
unredeemed outputs." This could be done by adding a few more commands.
Furthermore, I propose a new network services type for nodes that
serve as block chain/transaction pool storage.
Of couse, any peer that wishes to verify the integrity of the block
chain would still have to download at the very least
all the block headers...and to be completely sure, also all the blocks
themselves...and verify everything. But it would be
very nice to be able to run thin services that can rely on other
network peers to do this work. It is still possible to attain
a high level of confidence in the integrity by querying multiple peers
for similar objects and comparing. It is also possible
to run your own dedicated block chain storage servers which you trust.
There are other ideas I have for other types of services, too.
Anyhow, I'm just throwing this out there...if anyone's interested I'd
love to develop these ideas further and help put together some
specs.
-Eric Lombrozo
|
