public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Sat, 17 Dec 2011 14:28:55 -0500	[thread overview]
Message-ID: <CAAS2fgRqabDpXBZ7M8BAdzDAsRwFED4BPzoQJkLkwLOeURuXLA@mail.gmail.com> (raw)
In-Reply-To: <CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com>

On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker
<decker.christian@gmail.com> wrote:
> 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.

I strongly advise people who are not me to use this sort of scheme, so
that I may enjoy the benefits of robbing you blind.


.... But really, saying "some sort of DHT" without basically
presenting a working implementation that demonstrates the feasibility
of solving the very difficulty attack resistance problems these
schemes have basically triggers my time-wasting-idiot filter.  (Or
likewise, presenting a fixed network structure that would have a nice
small and easily identifiable min-cut...)

I don't doubt I'm completely alone in this,  though perhaps I'm more
of a jerk about it.   Even if your actual proposal might have some
merit you should be aware that every fool who has operated a
bittorrent client has heard of "DHT" and, although they may not even
understand what a hash table is, many have no reservation going around
suggesting them for _every_ distributed systems problem. Want to scale
matrix multiples? DHT! Want to validate bitcoin blocks? DHT! Network
syncup slow (because It's bound on validation related local IO)? DHT!
I suggest people solve the real problems first, then worry what name
to give the solutions. ;)

To address gavin's tragedy of the commons concern, one useful feature
would being able to mutually authenticate a peer... then full nodes
could pick and choose which lite nodes they're willing to do (a lot
of) hard work for. This would also be valuable because some modes of
lite operation require non-zero trust of the full node being queried.



  parent reply	other threads:[~2011-12-17 19:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-17  7:41 [Bitcoin-development] Protocol extensions Eric Lombrozo
2011-12-17 13:13 ` Michael Grønager
2011-12-17 13:37   ` Christian Decker
     [not found]     ` <CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
2011-12-17 19:06       ` Gavin Andresen
2011-12-17 21:49         ` theymos
2011-12-18  0:44           ` Jordan Mack
2011-12-18  1:07             ` Jeff Garzik
2011-12-18  1:27           ` Jordan Mack
2011-12-18 14:16             ` Andy Parkins
2011-12-18 17:09             ` theymos
2011-12-18 18:06               ` Alan Reiner
2011-12-18 18:47                 ` Amir Taaki
2011-12-18 19:37               ` Jorge Timón
2011-12-17 19:28     ` Gregory Maxwell [this message]
2011-12-17 20:34       ` Christian Decker
2011-12-18 21:19     ` Stefan Thomas
2011-12-19 21:43       ` Jordan Mack
2011-12-20  9:10         ` Wladimir
2011-12-20 10:44           ` Nicolas Fischer
2011-12-21  0:47         ` Kyle Henderson
2011-12-21  8:50       ` Michael Grønager
2011-12-21 11:42         ` Eric Lombrozo
2011-12-21 12:41           ` Michael Grønager
2011-12-21 16:10             ` Christian Decker
2011-12-22  9:18               ` Michael Grønager
2011-12-22 10:12               ` Andy Parkins
2011-12-22 10:27                 ` Michael Grønager
2011-12-22 11:52                   ` Andy Parkins
2011-12-22 12:14                     ` Joel Joonatan Kaartinen
2011-12-22 12:26                       ` Christian Decker
2011-12-22 12:42                       ` Michael Grønager
2011-12-22 14:46                       ` Andy Parkins
2011-12-25  2:55                         ` Zell Faze
2011-12-21 17:17         ` Jordan Mack
2011-12-22  9:19           ` Michael Grønager
2011-12-21  6:19 Eric Lombrozo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAS2fgRqabDpXBZ7M8BAdzDAsRwFED4BPzoQJkLkwLOeURuXLA@mail.gmail.com \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=decker.christian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox