On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote: > 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.
You mean scam you with a zero-conf transaction that hasn't actually been broadcast? You know how I feel about zero-conf. > 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. We already depend on OpenSSL, why not just use standard SSL? Define a per-node compressed pubkey to pass around, and then do whatever is easiest to get the actual SSL up and running. If we have to use that pubkey to in-turn sign for a secondary RSA key or whatever due to compatibility, no big deal. Define a new service bit SSL and if you connect to a SSL supporting node switch to SSL within the same TCP connection. > 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). Obfusication probably isn't the hard part, it's SPV bloom filter privacy that is the tough one, but probably a problem better handled by Tor. > 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. For phone stuff you should work with The Guardian Project - they've implemented Tor on Android among other things and want to find easier ways for apps to use it. -- 'peter'[:-1]@petertodd.org 000000000000014671272e3a4dd966bb56d4a9a27751b5cd4dc75dc931660cb5
Description: Digital signature
------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________ Bitcoin-development mailing list Bitcoinemail@example.com https://lists.sourceforge.net/lists/listinfo/bitcoin-development