From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 To: Peter Todd Message-ID: <20130506195003.GB4583@netbook.cypherspace.org> References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> <20130506171943.GA22505@petertodd.org> <20130506175331.GB22505@petertodd.org> <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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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