Yes, those trackers would be hard coded, just like the IRC servers and channels are hardcoded right now.<br><br>The advantages over IRC and DNS Seeds are:<br> - sporadic HTTP requests to a tracker, as opposed to keeping an IRC connection open at all times<br>


 - no virus/botnet like behaviour (automatically join IRC channel with cryptic name), ISPs tend to bother network admins (like myself) with alerts when they see this...<br> - adapts faster than DNS Seeds which require configuration changes on seed should the nodes become unreachable<br>

 - we already use HTTP to determine our external IP, so it would be a consolidation of transports<br> - more peers than DNS Seeds (better load balancing)<br><br>As for Vladimirs proposal, seems like an extreme measure, that is not really practical. Also it leads to network partitions since nodes will prefer their own /8 and /16 networks. IPv6 will also soon be a problem for this method.<br>

<br><div class="gmail_quote">On Mon, Jun 13, 2011 at 12:54 PM, Vladimir Marchenko <span dir="ltr">&lt;<a href="mailto:vladimir@marchenko.co.uk">vladimir@marchenko.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

one possible bootstrap method of last resort,<br>
<br>
1. create a convention of bitcoind listening on a specific last octest<br>
of IPv4 address, let&#39;s say, .14 when possible. Those of us who have<br>
access to IP space would use .14&#39;s.<br>
<br>
2. if no other bootstrap method works, client could start scanning<br>
x.x.x.14 addresses, perhaps in some semi-intelligent order (starting<br>
from more pobable /8&#39;s and /16&#39;s), if enough people place bitcoind on<br>
x.x.x.14 than after a 10-100 thousand checks it bound to find a<br>
bitcoind peer.<br>
<br>
It&#39;s messy, with all the excessive scanning etc... but it does not<br>
depend on anything except a bunch of bitcoind by convention preferring<br>
listening on x.x.x.14&#39;s.<br>
<br>
Given that this is a method of last resort in bootrap chain it whould<br>
hopefully not lead to DDOS on those unlucky to own *.14 and not<br>
running bitcoind there. Also the more people are running bitcoind on<br>
.14, the quicker it would find a peer, the less scanning to do. It is<br>
kind of self-regualting.<br>
<br>
For whatever it worth...<br>
<div><div></div><div class="h5"><br>
<br>
On 13 June 2011 10:56, Jeff Garzik &lt;<a href="mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a>&gt; wrote:<br>
&gt; On Mon, Jun 13, 2011 at 5:38 AM, Christian Decker<br>
&gt; &lt;<a href="mailto:decker.christian@gmail.com">decker.christian@gmail.com</a>&gt; wrote:<br>
&gt;&gt; BitTorrent trackers are used to handle several thousands of requests, so<br>
&gt;&gt; they would probably scale well enough. I&#39;m not even talking about using the<br>
&gt;&gt; DHT trackers, but using old fashioned HTTP based trackers. The fact that<br>
&gt;&gt; each bitcoin client would contact the tracker would make it very hard for an<br>
&gt;&gt; attacker to get bootstrapping clients to exclusively connect to his<br>
&gt;&gt; compromised clients. I would say that using a tracker such as OpenBittorrent<br>
&gt;&gt; provides the same advantages as using an IRC channel.<br>
&gt;<br>
&gt; And how does the client discover HTTP trackers?  You&#39;re either<br>
&gt; hardcoding -those- into the client, or adding an additional bootstrap<br>
&gt; step to discover them.  Either way, it has the same problems as other<br>
&gt; current methods.<br>
&gt;<br>
&gt; The history and experience of gnutella&#39;s web caches vs. UDP host<br>
&gt; caches seems highly relevant here.<br>
&gt;<br>
&gt; --<br>
&gt; Jeff Garzik<br>
&gt; exMULTI, Inc.<br>
&gt; <a href="mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
&gt;<br>
</div></div>&gt; ------------------------------------------------------------------------------<br>
&gt; EditLive Enterprise is the world&#39;s most technically advanced content<br>
&gt; authoring tool. Experience the power of Track Changes, Inline Image<br>
&gt; Editing and ensure content is compliant with Accessibility Checking.<br>
&gt; <a href="http://p.sf.net/sfu/ephox-dev2dev" target="_blank">http://p.sf.net/sfu/ephox-dev2dev</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
&gt; <a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
&gt;<br>
<br>
------------------------------------------------------------------------------<br>
EditLive Enterprise is the world&#39;s most technically advanced content<br>
authoring tool. Experience the power of Track Changes, Inline Image<br>
Editing and ensure content is compliant with Accessibility Checking.<br>
<a href="http://p.sf.net/sfu/ephox-dev2dev" target="_blank">http://p.sf.net/sfu/ephox-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div><br>