Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <adam.back@gmail.com>) id 1UZRQN-0001GK-A2
	for bitcoin-development@lists.sourceforge.net;
	Mon, 06 May 2013 19:50:15 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.83.50 as permitted sender)
	client-ip=74.125.83.50; envelope-from=adam.back@gmail.com;
	helo=mail-ee0-f50.google.com; 
Received: from mail-ee0-f50.google.com ([74.125.83.50])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UZRQM-0000pv-F2
	for bitcoin-development@lists.sourceforge.net;
	Mon, 06 May 2013 19:50:15 +0000
Received: by mail-ee0-f50.google.com with SMTP id e50so1983500eek.37
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 06 May 2013 12:50:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-hashcash:x-hashcash:x-hashcash:x-hashcash;
	bh=kEa7l5iDaFHjDGLDdzPNY1SE88BcaLI4wlgRYbT0nRo=;
	b=LqpqNfzBoY2PL5/yw7EWa+m27SAXs1efJhIMrMeDqroj3r/RTLKfc+iZbvGj/JEa7U
	0TESUmTfO8mU64IawjLcUlmNINq3aj97dCl4ndwvEgkLeN5SvfljoWhFb12h1tz5pyRR
	I8gfPZsn56Dj32uR2POTMb58S3PKs6K4VylXQyJvrXY4uXh0/gdB12zKc6ATs4AhsEoA
	sMtGUUNSVckHFqRycRbnSHszYPuVZKM6C+YRR2Yev9CflbCcgqoSR2rdt7QQzRt3mNaA
	DePqq7ZdloDhnstNig62hxjf2HLW2pXSED/uqLq4I4wJFOezYpJywD/L6U8ZP4G3ExSa
	ShPA==
X-Received: by 10.14.0.129 with SMTP id 1mr17491545eeb.43.1367869808081;
	Mon, 06 May 2013 12:50:08 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
	by mx.google.com with ESMTPSA id
	bn53sm35304652eeb.7.2013.05.06.12.50.06 for <multiple recipients>
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 06 May 2013 12:50:07 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
	id BA0E72E069E; Mon,  6 May 2013 21:50:04 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
	Mon, 6 May 2013 21:50:03 +0200
Date: Mon, 6 May 2013 21:50:03 +0200
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20130506195003.GB4583@netbook.cypherspace.org>
References: <20130506161216.GA5193@petertodd.org>
	<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
	<20130506163732.GB5193@petertodd.org>
	<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
	<20130506171943.GA22505@petertodd.org>
	<CAAS2fgQDa463Xb=D64LDenGn=mX+OXvD_bG=jXGYLnhFbgknsw@mail.gmail.com>
	<20130506175331.GB22505@petertodd.org>
	<CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com>
	<20130506183222.GB3797@netbook.cypherspace.org>
	<20130506190857.GA23095@petertodd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130506190857.GA23095@petertodd.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130506:pete@petertodd.org::S90HxfqQZoXAdzyH:0000000000000000000
	00000000000000000000000008+e
X-Hashcash: 1:20:130506:gmaxwell@gmail.com::Wi5haAC5kKQkcR9g:0000000000000000000
	0000000000000000000000001zlH
X-Hashcash: 1:20:130506:bitcoin-development@lists.sourceforge.net::/8q5wzofidcC0
	bVb:000000000000000000000r9i
X-Hashcash: 1:20:130506:adam@cypherspace.org::7RvNbjne3M4ovVFX:00000000000000000
	0000000000000000000000007EpN
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(adam.back[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1UZRQM-0000pv-F2
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
 for pruned nodes)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2013 19:50:15 -0000

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