public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace•org>
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 21:50:03 +0200	[thread overview]
Message-ID: <20130506195003.GB4583@netbook.cypherspace.org> (raw)
In-Reply-To: <20130506190857.GA23095@petertodd.org>

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, providing a ZKP.  If the node ever double spends a coin,
>> it loses its reputation as the coin address is revealed.
>
>Be careful not to mix up the concept of a relay node with someone
>posessing Bitcoins. Node's don't spend coins, people/wallets do.

My comment was to say that a good behaviour bond for a relay node could be
put on an address that is defined as unspendable until such time as an
auditor can prove the node engaged in the undesired behaviour, at which
point the audit receives the payment as part of his proof.  Or until the
node ceases to operate.  Its a smart contract.

However I added to that, that it is still possible to do that while
preseving privacy, to point out that it is technically possible, for people
to be aware of in their mental toolbox, if it helps solve an otherwise
tricky problem.

So that would be a privacy preserving smart contract, the parties are
unknown, and unknowable (with unconditional security even), but still the
smart contract executes.  In some sense a privacy preserving smart-contract
is closer to the real point of Szabo's smart-contract idea because you cant
try to renege on the contract in a conventional court - because you cant
identify your counter-party.  Bitcoins privacy feature is fairly weak so
that is probably often not true.

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.

> Make the node identity expensive to obtain. For instance, construct PoW's
> including the node pubkey somehow,

that could be easily done with the work of creating a vanity address.  eg
address containing many leading 0s.

Adam



  reply	other threads:[~2013-05-06 19:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06 14:58 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
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 [this message]
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=20130506195003.GB4583@netbook.cypherspace.org \
    --to=adam@cypherspace$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=pete@petertodd$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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