From: Eric Lombrozo <elombrozo@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Wed, 21 Dec 2011 03:42:40 -0800 [thread overview]
Message-ID: <CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com> (raw)
In-Reply-To: <67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com>
Is it just me or does it seem inevitable that at some point supernodes
will emerge that other nodes trust to validate transactions for them?
Supernodes needn't even store the entire block chain and transaction
pool...it would be sufficient that they keep lists of IP addresses of
other trustworthy nodes and partition them into a hashspace.
Anonymous peers have no reputation to defend...but a trusted supernode
would, which could provide just enough incentive for the supernode to
do its best to ensure the nodes it vouches for are indeed legit. Of
course, unless the supernode is validating the entire block chain and
transaction pool itself, it could only assess the trustworthiness of
other nodes by performing random sampling.
Michael, I really like your ideas and the clarity you bring to the
issue. Regarding the potential attack vector you mention, would it be
possible to partition the hashspace to minimize the risk that an
attacker can manage to disproportionately gain control over a part of
the hashspace?
next prev parent reply other threads:[~2011-12-21 11:42 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
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 [this message]
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='CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com' \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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