Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2011-06-13 🗒️ Summary of this message: The author ...
📅 Original date posted:2011-06-13
🗒️ Summary of this message: The author suggests using BitTorrent trackers for bootstrapping instead of IRC and hardcoded nodes, as they would scale well and be harder to compromise.
📝 Original message:Don't get me wrong, DNS Seeding is an excellent way to bootstrap via trusted
nodes, I'm not trying to replace it.
What I'm trying to get rid of is the IRC bootstrapping and the hardcoded
nodes in the client, they're easy targets.
BitTorrent trackers are used to handle several thousands of requests, so
they would probably scale well enough. I'm not even talking about using the
DHT trackers, but using old fashioned HTTP based trackers. The fact that
each bitcoin client would contact the tracker would make it very hard for an
attacker to get bootstrapping clients to exclusively connect to his
compromised clients. I would say that using a tracker such as OpenBittorrent
provides the same advantages as using an IRC channel.
On Mon, Jun 13, 2011 at 11:09 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker
> <decker.christian at gmail.com> wrote:
> > We have quite a few bootstrapping mechanisms, starting with the overly
> > complex (IMHO) IRC bootstrapping, which is often suspected as
> bot-activity.
> > Then we have a few hardcoded nodes and some fallback nodes. I was
> wondering
> > why we didn't adopt BitTorrent tracker bootstrapping until now? It's
> > basically all it does. Given a hash (SHA1 hash of the genesis bloc would
> be
> > nice ^^) it gives you a list of other nodes with the same hash.
>
> It seems to offer few benefits over DNS seeding, while potentially
> potentially creating a vulnerable hot spot in the DHT. Sybil attacks
> on DHTs are well documented.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110613/2d8c427a/attachment.html>;
🗒️ Summary of this message: The author suggests using BitTorrent trackers for bootstrapping instead of IRC and hardcoded nodes, as they would scale well and be harder to compromise.
📝 Original message:Don't get me wrong, DNS Seeding is an excellent way to bootstrap via trusted
nodes, I'm not trying to replace it.
What I'm trying to get rid of is the IRC bootstrapping and the hardcoded
nodes in the client, they're easy targets.
BitTorrent trackers are used to handle several thousands of requests, so
they would probably scale well enough. I'm not even talking about using the
DHT trackers, but using old fashioned HTTP based trackers. The fact that
each bitcoin client would contact the tracker would make it very hard for an
attacker to get bootstrapping clients to exclusively connect to his
compromised clients. I would say that using a tracker such as OpenBittorrent
provides the same advantages as using an IRC channel.
On Mon, Jun 13, 2011 at 11:09 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker
> <decker.christian at gmail.com> wrote:
> > We have quite a few bootstrapping mechanisms, starting with the overly
> > complex (IMHO) IRC bootstrapping, which is often suspected as
> bot-activity.
> > Then we have a few hardcoded nodes and some fallback nodes. I was
> wondering
> > why we didn't adopt BitTorrent tracker bootstrapping until now? It's
> > basically all it does. Given a hash (SHA1 hash of the genesis bloc would
> be
> > nice ^^) it gives you a list of other nodes with the same hash.
>
> It seems to offer few benefits over DNS seeding, while potentially
> potentially creating a vulnerable hot spot in the DHT. Sybil attacks
> on DHTs are well documented.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110613/2d8c427a/attachment.html>;