Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

[Gregory Maxwell <gmaxwell@gmail.com>]

On Mon, May 6, 2013 at 10:53 AM, Peter Todd <pete@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.