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

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

Criticism accepted, although I'd appreciate it if you supply some reasons
about why it's such a bad idea :-)
The idea was never really popular and before starting work on a real
implementation I wanted to test the water, and should it turn out it's
complete non-sense I'm happy to accept that.

I don't want to have a DHT for the DHTs sake, I was more interested in
reducing the number of messages that need to be sent around the network,
since network load is going to be a major problem if we ever grow beyond a
certain point.

Just wanting to brainstorm.

Regards,
Chris
On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> 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.
>

[-- Attachment #2: Type: text/html, Size: 3115 bytes --]

  reply	other threads:[~2011-12-17 20:35 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
2011-12-17 20:34       ` Christian Decker [this message]
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=CALxbBHWvJwOvnpGjN+A3MpzxrvzFGuJ0JBv6z_zz99Hvs0T+yg@mail.gmail.com \
    --to=decker.christian@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gmaxwell@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