public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Date: Mon, 6 May 2013 11:01:22 -0700	[thread overview]
Message-ID: <CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com> (raw)
In-Reply-To: <20130506175331.GB22505@petertodd.org>

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.



  reply	other threads:[~2013-05-06 18:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06 14:58 [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20   ` Jeff Garzik
2013-05-06 16:34     ` Mike Hearn
2013-05-06 16:37     ` Peter Todd
2013-05-06 16:47       ` Mike Hearn
2013-05-06 17:19         ` Peter Todd
2013-05-06 17:25           ` Jeff Garzik
2013-05-06 17:42           ` Gregory Maxwell
2013-05-06 17:53             ` Peter Todd
2013-05-06 18:01               ` Gregory Maxwell [this message]
2013-05-06 18:19                 ` Peter Todd
2013-05-06 18:32                 ` Adam Back
2013-05-06 19:08                   ` Peter Todd
2013-05-06 19:50                     ` Adam Back
2013-05-06 20:43                       ` Peter Todd
2013-05-06 23:44                         ` Peter Todd
2013-05-07  9:00           ` Mike Hearn
2013-05-09  0:57             ` John Dillon
2013-05-06 18:04         ` Adam Back
2013-05-06 18:25           ` Gregory Maxwell
2013-05-06 22:51             ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13               ` Gregory Maxwell
2013-05-07  4:48                 ` Petr Praus
2013-05-07 21:07                   ` Matt Corallo
2013-05-07  9:17                 ` Mike Hearn
2013-05-07 11:07                   ` Adam Back
2013-05-07 12:04                     ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox