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.
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
13 matches
Mail list logo
