<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey Chris,<br>
<br>
<blockquote type="cite">The storage would be distributed, messages
are routed on behalf of others, which makes finding the origin of
the query hard to find (think Tor)</blockquote>
<br>
This type of intermediate routing makes Tor <a
href="https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf">slow</a>.
Bitcoin does not and imho should not make anonymity guarantees. Many
users do not need them.<br>
<br>
Let those who want anonymity connect through Tor, Freenet, etc. It's
easy to add anonymity via an extra layer, but it is impossible to
add performance on top of a slow system.<br>
<br>
That's really the only thing I wanted to point out - if you do DHTs,
focus on performance, not anonymity. :)<br>
<br>
Cheers,<br>
<br>
Stefan<br>
<br>
On 12/17/2011 2:37 PM, Christian Decker wrote:
<blockquote
cite="mid:CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com"
type="cite">A while back I had proposed a similar idea to the DHT,
although my main goal was to reduce the need for broadcasts.<br>
<br>
My idea was to structure the network in a hypercube and use
prefixes to address different parts of the network, and use those
prefixes also to find the location where an item (transaction,
block, ...) should be stored. Each vertex in the hypercube is a
small, highly connected, cluster of nodes. The storage would be
distributed, messages are routed on behalf of others, which makes
finding the origin of the query hard to find (think Tor), each
node would have to store only O(log(p)) items, with p being the
prefix length, maximum number of hops is equal to the dimension of
the hypercube O(log(n)).<br>
<br>
Newly created transaction will be sent directly to the location
they'll be stored and miners retrieve new transactions at regular
intervals. It might increase delays to the confirmations, but it
reduces the number of broadcasts and storage requirements on nodes
greatly.<br>
<br>
Regards,<br>
Chris<br clear="all">
<br>
<br>
<div class="gmail_quote">On Sat, Dec 17, 2011 at 2:13 PM, Michael
Grønager <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gronager@ceptacle.com">gronager@ceptacle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Eric,<br>
<br>
Two comments.<br>
<br>
1.<br>
The ability to query for transactions belonging to pubkeys or
bitcoin addresses is supported today by several
implementations:<br>
* <a moz-do-not-send="true" href="http://blockexplorer.com"
target="_blank">blockexplorer.com</a><br>
* bitcoin-js<br>
* my own libBTC (will more on this soon)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Michael<br>
<div class="HOEnZb">
<div class="h5"><br>
On 17/12/2011, at 08:41, Eric Lombrozo wrote:<br>
<br>
> Hey, guys.<br>
><br>
> I haven't posted here before so I'll introduce
myself. My name's Eric,<br>
> I've been developing cryptocurrency-related<br>
> software for several months now, I've implemented
some libraries for<br>
> dealing with core bitcoin datastructures, made<br>
> some custom builds of bitcoind and interfaced it with
a few apps I've written.<br>
><br>
> In doing so, I've come to appreciate just how little
of the potential<br>
> for the bitcoin protocol is being exploited right
now...<br>
> not only in terms of the script features but in terms
of the potential<br>
> commands and node types that could exist.<br>
><br>
> For instance, the protocol spec at<br>
> <a moz-do-not-send="true"
href="https://en.bitcoin.it/wiki/Protocol_specification"
target="_blank">https://en.bitcoin.it/wiki/Protocol_specification</a>
only has 16 commands<br>
> listed and<br>
> only one service type...despite having a full 12
bytes for a command<br>
> code and a full eight bytes for a services<br>
> type.<br>
><br>
> The fact that only one node service type is specified
is probably due<br>
> to the fact that the satoshi client was written<br>
> to be a standalone monolithic app that took care of
all the essential<br>
> needs for a network of peers.<br>
> i.e. block chain storage/management, transaction
signing/verification,<br>
> key generation/wallet management, block mining,
etc...<br>
> However, I think there's an urgent need for breaking
up all these<br>
> different tasks into separate components that can run
as independent<br>
> services on different types of devices.<br>
><br>
> One of the big issues I'm dealing with now pertains
to block chain<br>
> storage. As of right now, it is implemented as
sequential<br>
> disk files using Berkeley DB in the satoshi client.
Then you have<br>
> other projects that have been using SQL tables,
etc...<br>
> But I believe the direction this really needs to move
towards is some<br>
> sort of distributed hash table...and the database
queries<br>
> should be performed using the bitcoin protocol
itself. Perhaps adding<br>
> a few more commands. As things stand right now,<br>
> the only way to query for transactions or blocks is
by their hash. And<br>
> once a transaction gets incorporated into a block and<br>
> removed from the transaction pool, one can no longer
query it by the<br>
> transaction hash without stepping outside the bitcoin
protocol.<br>
> We need access to the disk file that stores the
blocks whether it be<br>
> via Berkeley DB or SQL or whatever.<br>
><br>
> I propose an extension to the bitcoin protocol to
provide methods for<br>
> performing more sophisticated queries, such as "Give
me<br>
> an inventory of transactions involving this
particular public key" or<br>
> "Give me an inventory all transactions in the last n
blocks with<br>
> unredeemed outputs." This could be done by adding a
few more commands.<br>
><br>
> Furthermore, I propose a new network services type
for nodes that<br>
> serve as block chain/transaction pool storage.<br>
><br>
> Of couse, any peer that wishes to verify the
integrity of the block<br>
> chain would still have to download at the very least<br>
> all the block headers...and to be completely sure,
also all the blocks<br>
> themselves...and verify everything. But it would be<br>
> very nice to be able to run thin services that can
rely on other<br>
> network peers to do this work. It is still possible
to attain<br>
> a high level of confidence in the integrity by
querying multiple peers<br>
> for similar objects and comparing. It is also
possible<br>
> to run your own dedicated block chain storage servers
which you trust.<br>
><br>
> There are other ideas I have for other types of
services, too.<br>
><br>
> Anyhow, I'm just throwing this out there...if
anyone's interested I'd<br>
> love to develop these ideas further and help put
together some<br>
> specs.<br>
><br>
> -Eric Lombrozo<br>
><br>
>
------------------------------------------------------------------------------<br>
> Learn Windows Azure Live! Tuesday, Dec 13, 2011<br>
> Microsoft is holding a special Learn Windows Azure
training event for<br>
> developers. It will provide a great way to learn
Windows Azure and what it<br>
> provides. You can attend the event by watching it
streamed LIVE online.<br>
> Learn more at <a moz-do-not-send="true"
href="http://p.sf.net/sfu/ms-windowsazure"
target="_blank">http://p.sf.net/sfu/ms-windowsazure</a><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
> <a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br>
<br>
<br>
------------------------------------------------------------------------------<br>
Learn Windows Azure Live! Tuesday, Dec 13, 2011<br>
Microsoft is holding a special Learn Windows Azure
training event for<br>
developers. It will provide a great way to learn Windows
Azure and what it<br>
provides. You can attend the event by watching it streamed
LIVE online.<br>
Learn more at <a moz-do-not-send="true"
href="http://p.sf.net/sfu/ms-windowsazure"
target="_blank">http://p.sf.net/sfu/ms-windowsazure</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/ms-windowsazure">http://p.sf.net/sfu/ms-windowsazure</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>