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

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You mean scam you with a zero-conf transaction that hasn't actually been broadcast? Yeah. Or just scam you at all. It's hard to imagine an organisation as a big as a mobile carrier engaging in financial scamming (roaming fees excepted).

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

2013-05-07 Thread Mike Hearn
You mean scam you with a zero-conf transaction that hasn't actually been broadcast? Yeah. Or just scam you at all. It's hard to imagine an organisation as a big as a mobile carrier engaging in financial scamming (roaming fees excepted). I've said this before, but I think it's worth repeating.

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

2013-05-06 Thread Peter Todd
On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote: More generally, I think this shows clearly how SPV nodes have weaker security than constantly operating full nodes, which we knew already, so why not build a better SPV-specific system instead? I've noticed on my Android phone how it

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

2013-05-06 Thread Mike Hearn
I've noticed on my Android phone how it often takes quite awhile to find a peer that will actually accept an incoming connection, which isn't surprising really: why should a regular node care about responding to SPV nodes quickly? I haven't seen that - remote nodes don't have any special

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

2013-05-06 Thread Peter Todd
On Mon, May 06, 2013 at 12:20:12PM -0400, Jeff Garzik wrote: Security will be no worse than before - if any one server/seed is honest you're ok - and hopefully better due to the accountability. Obviously Indeed, the DNS seeds are just servers run by trusted individuals anyway. Yup, and

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

2013-05-06 Thread Mike Hearn
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

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

2013-05-06 Thread Peter Todd
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

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

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote: 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. We already depend on OpenSSL, why not just use standard SSL? SSL doesn't actually

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

2013-05-06 Thread Peter Todd
On Mon, May 06, 2013 at 10:42:19AM -0700, Gregory Maxwell wrote: On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote: 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. We already

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

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote: We don't have non-repudiation now, why make that a requirement for the first version? Adding non-repudiation is something that has to happen at the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure

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

2013-05-06 Thread 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

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

2013-05-06 Thread Peter Todd
On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote: On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote: We don't have non-repudiation now, why make that a requirement for the first version? Adding non-repudiation is something that has to happen at the Bitcoin

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

2013-05-06 Thread Adam Back
On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote: Hmm: maybe one could use a Brands private credential with offline double spend detection, with the reputation but not coin address of the node disclosed, and the nodes coin address embedded in the proof. Each node could be is own CA,

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

2013-05-06 Thread Peter Todd
On Mon, May 06, 2013 at 09:50:03PM +0200, Adam Back wrote: Of course you'd probably need zerocoin to stand much chance of proving an address private key of an unlinked coin was in the double-spend disclosed attribute in the first place, and as we know zerocoin is not that efficient. Sounds