On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote: > On Mon, May 6, 2013 at 10:53 AM, Peter Todd 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. stunnel only works if both sides support it. re: discovery, the whole reason I brought up SSL was the idea that a seed whome you have a secure connection to, like HTTPS or SSL, can include the peer pubkey along with the peer's IP address, allowing you to be sure you've connected to the peer the seed is giving you rather than some other imposter. Equally it'll let you be sure you've connected to the correct peer the second time. For applications where you *don't* need non-repudiation SSL is already implemented and solves the secure peer communication issue, including encryption, in an efficient way without requiring a lot of code complexity to implement. SSL could be implemented as a Google Summar of Code project by an average developer, and importantly re-implemented by all the alt-clients out there with relatively little work. It may even be the case that some usage scenarios do find the CA system useful. I might want to do -addnode ssl://petertodd.org on my Android wallet to be sure I've connected to my Bitcoin node rather than some MITM ISP imposter. I already have a SSL cert from a CA for petertodd.org that I can use and my Android phone already has a list of CA's I can put a reasonable amount of trust in. > > 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. Sure, but how will non-repudiation be implemented? By having the node sign the messages they send with their pubkey, and as Mike suggests likely doing so in some sort of chained hash or preferably merkle mountain range to allow for constructing proofs over multiple messages. That has nothing to do with encrypting the transport, and will always be a lot slower than SSL's symmetric cipher for when you don't need non-repudiation but do want to be sure you've connected to the right node. > > 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. Per-node keys really need to be per listening address by default. In fact, I'd argue for creating new keys on startup by default. -- 'peter'[:-1]@petertodd.org 000000000000015ef6fc2fc45adc1de0c344e99a59453bb09ac470a1d02b787d