From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Date: Mon, 6 May 2013 18:47:22 +0200 [thread overview]
Message-ID: <CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com> (raw)
In-Reply-To: <20130506163732.GB5193@petertodd.org>
> 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.
next prev parent reply other threads:[~2013-05-06 16:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20 ` Jeff Garzik
2013-05-06 16:34 ` Mike Hearn
2013-05-06 16:37 ` Peter Todd
2013-05-06 16:47 ` Mike Hearn [this message]
2013-05-06 17:19 ` Peter Todd
2013-05-06 17:25 ` Jeff Garzik
2013-05-06 17:42 ` Gregory Maxwell
2013-05-06 17:53 ` Peter Todd
2013-05-06 18:01 ` Gregory Maxwell
2013-05-06 18:19 ` Peter Todd
2013-05-06 18:32 ` Adam Back
2013-05-06 19:08 ` Peter Todd
2013-05-06 19:50 ` Adam Back
2013-05-06 20:43 ` Peter Todd
2013-05-06 23:44 ` Peter Todd
2013-05-07 9:00 ` Mike Hearn
2013-05-09 0:57 ` John Dillon
2013-05-06 18:04 ` Adam Back
2013-05-06 18:25 ` Gregory Maxwell
2013-05-06 22:51 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13 ` Gregory Maxwell
2013-05-07 4:48 ` Petr Praus
2013-05-07 21:07 ` Matt Corallo
2013-05-07 9:17 ` Mike Hearn
2013-05-07 11:07 ` Adam Back
2013-05-07 12:04 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com' \
--to=mike@plan99.net \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox