[Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

[Adam Back]

Bitcoin p2p seeding requirements hav some ToR similarities, and we went
through the same security considerations with Zero-Knowledge systems freedom
network.  Though bitcoins attacker profile and motivation is different - so
the defense maybe even more demanding.  At least you have no shortage of
nodes and perhaps merchant interest and general good-will to lean on.

At ZKS I proposed we should fix the exit node issue (exit sees where you go
often in the clear) with an apache mod so the freedom aip tunnel (ToR tunnel
equiv) could terminate right on the web site.  (ZKS freedom network is long
dead but some of the ideas I think made it into ToR, eg I hope my end2end
forward anonymity idea that is implemented in Zach Brown's cebolla.)

Anyway I'd have about DNS being of limited value: bitcoins primary
vulnerability IMO (so far) is network attacks to induce network splits,
local lower difficulty to a point that a local and artificially isolated
area of the network can be fooled into accepting an orphan branch as the
one-true block chain, maybe even from node first install time.

(btw I notice most of the binaries and tar balls are not signed, nor served
from SSL - at least for linux).

Therefore as it applies to discover, you want to be able to discover peers
through as many network routes, and even steganographic protocols as
possible.  eg if a popular web server (say apache, or an apache module) put
a steganographic peer discover relay from its own network area, even for a
small bitcoin fee, that would help a lot.  (Steganographic in the SSL sense
would just mean that the peer seed request to /btcseed.cgi would not be
distinguishable to someone highly sophisticated on the inside of the router
all the peers traffic is routed through.  Eg you could easily do this with a
special magic header that overwrites something else or deletes some
unnecessary header so that the request at least is a standard size, and pad
the response to the same size as the site index.html or whatever).  If the
user picks a few SSL sites and cross checks (more for high value) a subset
of peers available on all and uses them as his seed that seems like a better
direction.

In that way an attacker cant control the network without denying service to
popular SSL sites, which would be a warning sign to users, or having at his
disposal a SSL sub-CA cert (like happened with diginotar and gmail).  You
may be able to pin CAs for popular sites.  Obviously to the extent you're
using SSL you want to generally use EDH for forward-secrecy.  And not RC4 :)

Probably anysite that accepts bitcoin payment will be happy to run such a
mod-bitcoin.


With ToR, it has a similar bootstrap problem to bitcoin.  So while that may
help it is also passing the buck, not necessarily solving the problem.  And
as I said I think its possible bitcoin has a higher assurance need in that
the attackers motivated my $$ might put more effort in than the odd
dictatorship trying to pay lip service to preventing people reading pages on
a blacklist.


Given the vulnerability of DNS to poisoning I would not trust it too much. 
I know its just a bootstrap, but ideally you dont want to bootstrap from a
known publicly vulnerable protocol - it invites DNS poison net splits
against new users.


Also to the extent that users local clock is under his control (with
unuthentcated NTP?) he should also treat sudden dramatic changes in luck
(deviations from 10min interval) as suspicious.  

Unfortunately at present because of the first past the post nature of the
bitcoin lottery, reduced variance hashcash cannot be used, so its hard to
infer too much even from quite significant luck changes.

Adam

On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
>> Speaking of, off-topic for this discussion, but in the future
>> node-to-node communicate should be encrypted and signed
>
>Yes, I'd like to do this. The threat isn't really ISPs which are
>mostly trustable (the worst they normally do outside of places like
>China is dick about with ads), the big threat is people who use
>untrusted WiFi without realising and end up thinking they received
>money when actually they were just connected to a hotspot running in
>the attackers pocket. I'm rather expecting that kind of thing to
>happen in future.
>
>I think we can converge on the best solution with several iterations:
>
>Iteration 1) Make it clear in the UI that if the phone is connected to
>WiFi, payments from untrusted people should not be accepted. Currently
>the Android app merely says the money won't be spendable for a few
>minutes. It needs to communicate the "may not exist" aspect more
>clearly. If you're connected via a cell tower, the existing wording is
>fine - it's very unlikely your telco is trying to scam you in a
>person-to-person transaction, traffic is encrypted and 3G+ connections
>authenticate the network so you can't be MITMd except by your telco.
>Assuming you have a good list of IPs, of course.
>
>Iteration 2) Give nodes keys that appear in addr broadcasts and seed
>data (whether it be via https or otherwise), and have each node keep a
>running hash of all messages sent on a connection so far. Add a new
>protocol message that asks the node to sign the current accumulated
>hash. Not all messages really need to be signed, eg asking for
>signatures of blocks is sort of pointless at high difficulty levels
>because the structures are self proving and a simple watchdog timer
>that looks for unusually slow progress is probably enough. If the
>client keeps the same accumulated hash then when you encounter
>something you care about the accuracy of, you can ask for a signature
>over all traffic so far.
>
>Iteration 3) Do something about end to end encryption, just delegate
>everything to Tor, or find some other way to obfuscate the origin of a
>transaction (a mini onion network for example).
>
>Last time I looked, Tor wasn't really usable in library form and
>connecting to hidden services is really slow. So it'd be an issue to
>just re-use it out of the box, I think.