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 > you're connection isn't being tampered with and is encrypted.
Because if you just want bitcoin p2p over SSL... just start up stunnel on another port. Done. You've still solved nothing about the problem of discovery issue. > 1) Non-repudiation is only useful with fraud proofs, and they will have > to be thought out for everything the node might claim. That isn't so. If a node is reliably rogue I can go manually gather evidence and people can manually take action against it. Consider the DNSseeds, right now fraud proofs really wouldn't matter— the limited amount of trust put in those things is based not on "oh no, nodes will ignore you in the future if you're bad", it's based on the ability of misconduct to sully the operator's reputation. But without non-repudiation the ability to tie reputation to good behavior is fairly limited especially if they perform targeted attacks. "Wasn't me" Instead— I'd argue that non-repudiation is always useful when there is trust. It's things like fidelity bonds— a trust generator that depend on automatic enforcement— that are only useful with fraud proofs. > Anyway, the concept of a per-node identity keypair is the first step > towards non-repudiation, and implementing SSL transport. Yea, indeed, per-node keys are useful for a bunch of things. Care is needed to avoid problems like deanonymizing use over tor with them. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
