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 --]
next prev parent 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 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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