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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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,
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
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 (
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
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.
19 matches
Mail list logo