📅 Original date posted:2011-06-13
🗒️ Summary of this message: Using HTTP trackers for bootstrapping Bitcoin clients has advantages over IRC and DNS Seeds, including better load balancing and no virus/botnet behavior. Hardcoding trackers would be necessary. Vladimir's proposal of using a specific last octet of IPv4 addresses is not practical and could lead to network partitions.
📝 Original message:Yes, those trackers would be hard coded, just like the IRC servers and
channels are hardcoded right now.
The advantages over IRC and DNS Seeds are:
- sporadic HTTP requests to a tracker, as opposed to keeping an IRC
connection open at all times
- 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...
- adapts faster than DNS Seeds which require configuration changes on seed
should the nodes become unreachable
- we already use HTTP to determine our external IP, so it would be a
consolidation of transports
- more peers than DNS Seeds (better load balancing)
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.
On Mon, Jun 13, 2011 at 12:54 PM, Vladimir Marchenko <
vladimir at marchenko.co.uk> wrote:
> one possible bootstrap method of last resort,
>
> 1. create a convention of bitcoind listening on a specific last octest
> of IPv4 address, let's say, .14 when possible. Those of us who have
> access to IP space would use .14's.
>
> 2. if no other bootstrap method works, client could start scanning
> x.x.x.14 addresses, perhaps in some semi-intelligent order (starting
> from more pobable /8's and /16's), if enough people place bitcoind on
> x.x.x.14 than after a 10-100 thousand checks it bound to find a
> bitcoind peer.
>
> It's messy, with all the excessive scanning etc... but it does not
> depend on anything except a bunch of bitcoind by convention preferring
> listening on x.x.x.14's.
>
> Given that this is a method of last resort in bootrap chain it whould
> hopefully not lead to DDOS on those unlucky to own *.14 and not
> running bitcoind there. Also the more people are running bitcoind on
> .14, the quicker it would find a peer, the less scanning to do. It is
> kind of self-regualting.
>
> For whatever it worth...
>
>
> On 13 June 2011 10:56, Jeff Garzik <jgarzik at exmulti.com> wrote:
> > On Mon, Jun 13, 2011 at 5:38 AM, Christian Decker
> > <decker.christian at gmail.com> wrote:
> >> 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.
> >
> > And how does the client discover HTTP trackers? You're either
> > hardcoding -those- into the client, or adding an additional bootstrap
> > step to discover them. Either way, it has the same problems as other
> > current methods.
> >
> > The history and experience of gnutella's web caches vs. UDP host
> > caches seems highly relevant here.
> >
> > --
> > Jeff Garzik
> > exMULTI, Inc.
> > jgarzik at exmulti.com
> >
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110613/d921638d/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 01:19:15
in reply to nevent1q…ux6s
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 01:19:15Event JSON
{
"id": "9a8b6d321375e7e7cd20b92acea2c4ee591e18d2e515c257b04f22bf52be3f0e",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686100755,
"kind": 1,
"tags": [
[
"e",
"c8d1623c1aca2fc5820fe9c137e8b55a6b4d219d8734bf4e2ba3756e681a52cc",
"",
"root"
],
[
"e",
"32a9facf2cd9b68d4c31b5e8da6286db3272ca6986d926dd705d5a2d3812f88b",
"",
"reply"
],
[
"p",
"275ba4ec3e15ca3c3fe11671ca356822884cd53edb131736671f3e69af067e05"
]
],
"content": "📅 Original date posted:2011-06-13\n🗒️ Summary of this message: Using HTTP trackers for bootstrapping Bitcoin clients has advantages over IRC and DNS Seeds, including better load balancing and no virus/botnet behavior. Hardcoding trackers would be necessary. Vladimir's proposal of using a specific last octet of IPv4 addresses is not practical and could lead to network partitions.\n📝 Original message:Yes, those trackers would be hard coded, just like the IRC servers and\nchannels are hardcoded right now.\n\nThe advantages over IRC and DNS Seeds are:\n - sporadic HTTP requests to a tracker, as opposed to keeping an IRC\nconnection open at all times\n - no virus/botnet like behaviour (automatically join IRC channel with\ncryptic name), ISPs tend to bother network admins (like myself) with alerts\nwhen they see this...\n - adapts faster than DNS Seeds which require configuration changes on seed\nshould the nodes become unreachable\n - we already use HTTP to determine our external IP, so it would be a\nconsolidation of transports\n - more peers than DNS Seeds (better load balancing)\n\nAs for Vladimirs proposal, seems like an extreme measure, that is not really\npractical. Also it leads to network partitions since nodes will prefer their\nown /8 and /16 networks. IPv6 will also soon be a problem for this method.\n\nOn Mon, Jun 13, 2011 at 12:54 PM, Vladimir Marchenko \u003c\nvladimir at marchenko.co.uk\u003e wrote:\n\n\u003e one possible bootstrap method of last resort,\n\u003e\n\u003e 1. create a convention of bitcoind listening on a specific last octest\n\u003e of IPv4 address, let's say, .14 when possible. Those of us who have\n\u003e access to IP space would use .14's.\n\u003e\n\u003e 2. if no other bootstrap method works, client could start scanning\n\u003e x.x.x.14 addresses, perhaps in some semi-intelligent order (starting\n\u003e from more pobable /8's and /16's), if enough people place bitcoind on\n\u003e x.x.x.14 than after a 10-100 thousand checks it bound to find a\n\u003e bitcoind peer.\n\u003e\n\u003e It's messy, with all the excessive scanning etc... but it does not\n\u003e depend on anything except a bunch of bitcoind by convention preferring\n\u003e listening on x.x.x.14's.\n\u003e\n\u003e Given that this is a method of last resort in bootrap chain it whould\n\u003e hopefully not lead to DDOS on those unlucky to own *.14 and not\n\u003e running bitcoind there. Also the more people are running bitcoind on\n\u003e .14, the quicker it would find a peer, the less scanning to do. It is\n\u003e kind of self-regualting.\n\u003e\n\u003e For whatever it worth...\n\u003e\n\u003e\n\u003e On 13 June 2011 10:56, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\u003e \u003e On Mon, Jun 13, 2011 at 5:38 AM, Christian Decker\n\u003e \u003e \u003cdecker.christian at gmail.com\u003e wrote:\n\u003e \u003e\u003e BitTorrent trackers are used to handle several thousands of requests, so\n\u003e \u003e\u003e they would probably scale well enough. I'm not even talking about using\n\u003e the\n\u003e \u003e\u003e DHT trackers, but using old fashioned HTTP based trackers. The fact that\n\u003e \u003e\u003e each bitcoin client would contact the tracker would make it very hard\n\u003e for an\n\u003e \u003e\u003e attacker to get bootstrapping clients to exclusively connect to his\n\u003e \u003e\u003e compromised clients. I would say that using a tracker such as\n\u003e OpenBittorrent\n\u003e \u003e\u003e provides the same advantages as using an IRC channel.\n\u003e \u003e\n\u003e \u003e And how does the client discover HTTP trackers? You're either\n\u003e \u003e hardcoding -those- into the client, or adding an additional bootstrap\n\u003e \u003e step to discover them. Either way, it has the same problems as other\n\u003e \u003e current methods.\n\u003e \u003e\n\u003e \u003e The history and experience of gnutella's web caches vs. UDP host\n\u003e \u003e caches seems highly relevant here.\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e Jeff Garzik\n\u003e \u003e exMULTI, Inc.\n\u003e \u003e jgarzik at exmulti.com\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e EditLive Enterprise is the world's most technically advanced content\n\u003e \u003e authoring tool. Experience the power of Track Changes, Inline Image\n\u003e \u003e Editing and ensure content is compliant with Accessibility Checking.\n\u003e \u003e http://p.sf.net/sfu/ephox-dev2dev\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e EditLive Enterprise is the world's most technically advanced content\n\u003e authoring tool. Experience the power of Track Changes, Inline Image\n\u003e Editing and ensure content is compliant with Accessibility Checking.\n\u003e http://p.sf.net/sfu/ephox-dev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110613/d921638d/attachment.html\u003e",
"sig": "c46f5b74d1ac8a97f4a859b0a5b7d8ac047e034269c920a38f2cb566ac16d0ebf39c47c53452d2f9af89b261621980ae69677fbaa0496cb215295f3e08d5e492"
}