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>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

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