From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y5YXb-0007fv-7Z for bitcoin-development@lists.sourceforge.net; Mon, 29 Dec 2014 11:31:15 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.45 as permitted sender) client-ip=74.125.82.45; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f45.google.com; Received: from mail-wg0-f45.google.com ([74.125.82.45]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y5YXC-0004Lw-VX for bitcoin-development@lists.sourceforge.net; Mon, 29 Dec 2014 11:31:15 +0000 Received: by mail-wg0-f45.google.com with SMTP id b13so18654390wgh.4 for ; Mon, 29 Dec 2014 03:30:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.61.168 with SMTP id q8mr107190448wjr.53.1419852642829; Mon, 29 Dec 2014 03:30:42 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Mon, 29 Dec 2014 03:30:42 -0800 (PST) In-Reply-To: <3685166.ROb67lzbMM@coldstorage> References: <3685166.ROb67lzbMM@coldstorage> Date: Mon, 29 Dec 2014 11:30:42 +0000 X-Google-Sender-Auth: ih4LrnGfE13t_X8OcClXaPAOtW0 Message-ID: From: Mike Hearn To: Thomas Zander Content-Type: multipart/alternative; boundary=047d7bacbeb668ce86050b593498 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1Y5YXC-0004Lw-VX Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Cartographer X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 11:31:15 -0000 --047d7bacbeb668ce86050b593498 Content-Type: text/plain; charset=UTF-8 > > Can you explain further where limitations and problems were hit? > Well, look at the feature list :) The biggest need from my POV is querying support. It's awkward to try and retrofit flexible key=value pair queries onto DNS, it just wasn't designed for that. With HTTP it's easy. This will become more important in future as the protocol evolves. For example, some nodes will soon stop serving the block chain because they start pruning. Today this is managed with a hack: pruning nodes just stop providing *all* services to the p2p network. This takes them out of the DNS seeds entirely. But they can actually still provide download of the parts of the chain they still have, and they can provide transaction filtering and relay support, along with misc other things. With the current DNS protocol you get an all or nothing choice - so probably seeds that only support it will elect to only show nodes that have the entire block chain, because that's what Bitcoin Core would find most useful. SPV wallets have slightly different needs. In theory you could come up with a pile of hacks to specify what the client needs in the DNS query, but then you have a v2 protocol anyway and might as well go the whole way. Additionally, with DNS it's awkward to provide extra data in the responses beyond IP address and it's VERY awkward to sign the responses. Signing the responses has a couple of benefits. The biggest is, in future it'd be nice to have an authenticated and encrypted network, to raise the bar for sybil and MITM attacks. DNS seeding can't be upgraded to support that with any reasonable level of effort. And DNS is awkward to configure/set up. Actually DNS is just awkward, period. The second benefit of signing is it provides audibility. If you see a seed give bad answers, you can now prove it to other people. There is also the previously discussed issue that DNS seeds sometimes get blocked by aggressive networks because they start serving IPs that are infected with malware i.e. they look like fast-flux sites. Using a simple HTTP based protocol fixes all of these problems in one go. Now, re: privacy. Firstly, Peter, get help. I'm serious. You are starting to sound like an auto-generated parody of yourself. When you can't debate something as boring as HTTP vs DNS without trying to raise an angry mob using bizarre conspiracy theories, that's not normal. I don't think the "DNS has caches" issue is worth worrying about for a lot of reasons: 1. Full nodes try as hard as they can to open ports and advertise their IP addresses to everyone. Even if you change the defaults to disable that, you're about to connect to a bunch of random computers with no reputation anyway. 2. Lists of stale IP addresses are hardly useful to regular people and network operators can identify Bitcoin users by looking for traffic on port 8333, so it's unclear what threat model is being addressed here. 3. The biggest users of the seeds are all SPV wallets. Every single one of these already phones home to check for online updates. 4. DNS proxying only hides part of the IP address. If you're serious about this you want to be doing lookups via Tor. Whilst it's possible to use the DNS seeds via Tor in a reasonable way with exit diversity (and bitcoinj does), doing it requires low level Tor protocol programming that is out of reach for most implementors. An HTTP lookup is trivial with any HTTP stack that supports SOCKS. 5. ISPs also deploy transparent HTTP caches. The Cartographer protocol uses HTTP with inline signing so responses can be cached, once the right headers are being set. tl;dr it's unclear that DNS caching actually solves any real privacy problem but regardless, you can get the same distributed caching with HTTP as with DNS. So in the end it makes little difference. I believe that Cartographer is a better protocol all round and there are no costs beyond the one-time upgrades, but even if for some reason you disagree with the five privacy points above, I think the benefits still massively outweigh the costs. --047d7bacbeb668ce86050b593498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you explain further where limitations and pr= oblems were hit?

Well, look at the feat= ure list :)

The biggest need from my POV is queryi= ng support. It's awkward to try and retrofit flexible key=3Dvalue pair = queries onto DNS, it just wasn't designed for that. With HTTP it's = easy. This will become more important in future as the protocol evolves. Fo= r example, some nodes will soon stop serving the block chain because they s= tart pruning. Today this is managed with a hack: pruning nodes just stop pr= oviding all services to the p2p network. This takes them out of the = DNS seeds entirely. But they can actually still provide download of the par= ts of the chain they still have, and they can provide transaction filtering= and relay support, along with misc other things.=C2=A0

With the current DNS protocol you get an all or nothing choice - so p= robably seeds that only support it will elect to only show nodes that have = the entire block chain, because that's what Bitcoin Core would find mos= t useful. SPV wallets have slightly different needs.

In theory you could come up with a pile of hacks to specify what the cli= ent needs in the DNS query, but then you have a v2 protocol anyway and migh= t as well go the whole way.

Additionally, with DNS= it's awkward to provide extra data in the responses beyond IP address = and it's VERY awkward to sign the responses. Signing the responses has = a couple of benefits. The biggest is, in future it'd be nice to have an= authenticated and encrypted network, to raise the bar for sybil and MITM a= ttacks. DNS seeding can't be upgraded to support that with any reasonab= le level of effort. And DNS is awkward to configure/set up. Actually DNS is= just awkward, period.

The second benefit of signi= ng is it provides audibility. If you see a seed give bad answers, you can n= ow prove it to other people.

There is also the pre= viously discussed issue that DNS seeds sometimes get blocked by aggressive = networks because they start serving IPs that are infected with malware i.e.= they look like fast-flux sites.

Using a simple HT= TP based protocol fixes all of these problems in one go.

Now, re: privacy.=C2=A0

Firstly, Peter, get= help. I'm serious. You are starting to sound like an auto-generated pa= rody of yourself. When you can't debate something as boring as HTTP vs = DNS without trying to raise an angry mob using bizarre conspiracy theories,= that's not normal.

I don't think the &quo= t;DNS has caches" issue is worth worrying about for a lot of reasons:<= /div>
  1. Full nodes try as hard as they can to open ports and adve= rtise their IP addresses to everyone. Even if you change the defaults to di= sable that, you're about to connect to a bunch of random computers with= no reputation anyway.

  2. Lists of stale IP addresses are hard= ly useful to regular people and network operators can identify Bitcoin user= s by looking for traffic on port 8333, so it's unclear what threat mode= l is being addressed here.

  3. The biggest users of the seeds a= re all SPV wallets. Every single one of these already phones home to check = for online updates.

  4. DNS proxying only hides part of the IP = address. If you're serious about this you want to be doing lookups via = Tor. Whilst it's possible to use the DNS seeds via Tor in a reasonable = way with exit diversity (and bitcoinj does), doing it requires low level Tor protocol programming that is out of reach for most impl= ementors. An HTTP lookup is trivial with any HTTP stack that supports SOCKS= .

  5. ISPs also deploy transparent HTTP caches. The Cartographe= r protocol uses HTTP with inline signing so responses can be cached, once t= he right headers are being set.
tl;dr it's unclear that D= NS caching actually solves any real privacy problem but regardless, you can= get the same distributed caching with HTTP as with DNS. So in the end it m= akes little difference.

I believe that Carto= grapher is a better protocol all round and there are no costs beyond the on= e-time upgrades, but even if for some reason you disagree with the five pri= vacy points above, I think the benefits still massively outweigh the costs.=
--047d7bacbeb668ce86050b593498--