summaryrefslogtreecommitdiff
path: root/c0/f5b970d7ea6895366953174be95a5a83e189d9
blob: d08c35b32c804f24585915f31fb30e8163199f9f (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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gronager@ceptacle.com>) id 1Rbu4i-0007gj-VZ
	for bitcoin-development@lists.sourceforge.net;
	Sat, 17 Dec 2011 13:13:16 +0000
X-ACL-Warn: 
Received: from backup-server.nordu.net ([193.10.252.66])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Rbu4g-0004K5-BC
	for bitcoin-development@lists.sourceforge.net;
	Sat, 17 Dec 2011 13:13:16 +0000
Received: from [192.168.0.20] (2508ds5-oebr.0.fullrate.dk [95.166.54.87])
	(authenticated bits=0)
	by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBHDD3ZK025333
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Sat, 17 Dec 2011 14:13:05 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
Date: Sat, 17 Dec 2011 14:13:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1Rbu4g-0004K5-BC
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [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 13:13:17 -0000

Hey Eric,

Two comments.

1.
The ability to query for transactions belonging to pubkeys or bitcoin =
addresses is supported today by several implementations:
* blockexplorer.com
* bitcoin-js
* my own libBTC (will more on this soon)

To query for transactions you need to use json-rpc and not the bitcoin =
protocol, however. But still the purpose is the same: to be able to =
build thin clients that can rely on a server for storing the blockchain =
and keeping connected on the p2p network.

The reason for not having these queries part of the standard protocol (I =
think) are as they breaks anonymity, and that you would actually =
encourage people to participate in the p2p.

2. The second part you mention, to some how move the storage of the =
blockchain into a DHT based storage would be quite nice. The benefit of =
this is that it could be a way to integrate the smaller clients into the =
network without breaking the anonymity. But it should be thought out =
quite carefully. Further, if each client only store a fraction of the =
blockchain we should work out what fraction that need to be in order to =
ensure a similar service level. I would be happy to work with you on =
this.

Cheers,

Michael

On 17/12/2011, at 08:41, Eric Lombrozo wrote:

> Hey, guys.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Furthermore, I propose a new network services type for nodes that
> serve as block chain/transaction pool storage.
>=20
> 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.
>=20
> There are other ideas I have for other types of services, too.
>=20
> 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.
>=20
> -Eric Lombrozo
>=20
> =
--------------------------------------------------------------------------=
----
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for=20=

> developers. It will provide a great way to learn Windows Azure and =
what it=20
> provides. You can attend the event by watching it streamed LIVE =
online. =20
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development