From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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?= In-Reply-To: Date: Sat, 17 Dec 2011 14:13:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com> References: To: Eric Lombrozo 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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