[Bitcoin-development] Requirement for relay field in version packet (protocol version = 70001)

2013-05-06 Thread Addy Yeow
From https://en.bitcoin.it/wiki/Protocol_specification#version, is the relay field (bool/1 byte) required in all version packets coming from client with protocol version = 70001? -- Introducing AppDynamics Lite, a free

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-06 Thread Mike Hearn
You are welcome to optimise P2P addr broadcasts or develop better bootstrap mechanisms. On Sun, May 5, 2013 at 3:12 PM, John Dillon john.dillon...@googlemail.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sorry I should have used the word bootstrapping there rather than

Re: [Bitcoin-development] Requirement for relay field in version packet (protocol version = 70001)

2013-05-06 Thread Mike Hearn
It's expected to be there, yes. On Mon, May 6, 2013 at 9:56 AM, Addy Yeow ayeo...@gmail.com wrote: From https://en.bitcoin.it/wiki/Protocol_specification#version, is the relay field (bool/1 byte) required in all version packets coming from client with protocol version = 70001?

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-06 Thread Pieter Wuille
On Mon, May 06, 2013 at 10:19:35AM +0200, Mike Hearn wrote: You are welcome to optimise P2P addr broadcasts or develop better bootstrap mechanisms. I think John's actually has a point here. If we're judging the quality of a protocol change by how compatible it is with DNS seeding, then we're

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

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-05-06 Thread Peter Todd
On Tue, Apr 30, 2013 at 10:17:23AM -0700, Jeremy Spilman wrote: [Aside] I was reading Peter's fidelitybond writeup for his idea on contract value accounting, and he points to Stephan's post from last September on payer-encoded metadata (

[Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

2013-05-06 Thread Adam Back
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote: On Mon, May 6, 2013 at 11:04 AM, Adam Back a...@cypherspace.org wrote: bitcoins primaryvulnerability IMO (so far) is network attacks to induce network splits, local lower difficulty to a point that a local and artificially

Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 3:51 PM, Adam Back a...@cypherspace.org wrote: Maybe I could hack a pool to co-opt it into my netsplit and do the work for me, or segment enough of the network to have some miners in it, and they do the work. Or you can just let it mine honestly and take the Bitcoins.