From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XGoOt-000441-6c for bitcoin-development@lists.sourceforge.net; Mon, 11 Aug 2014 12:08:31 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XGoOs-0005Jl-8q for bitcoin-development@lists.sourceforge.net; Mon, 11 Aug 2014 12:08:31 +0000 Received: by mail-oa0-f43.google.com with SMTP id i7so6031542oag.30 for ; Mon, 11 Aug 2014 05:08:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.186.3 with SMTP id k3mr201631oif.18.1407758904784; Mon, 11 Aug 2014 05:08:24 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.97.132 with HTTP; Mon, 11 Aug 2014 05:08:24 -0700 (PDT) In-Reply-To: <1446506.FNP3GnOpud@calzone> References: <8137823.B0x87S28xY@calzone> <1446506.FNP3GnOpud@calzone> Date: Mon, 11 Aug 2014 14:08:24 +0200 X-Google-Sender-Auth: VQoxeYDbr_RkgWKJoKCCXL_vdlw Message-ID: From: Mike Hearn To: Tim Ruffing Content-Type: multipart/alternative; boundary=001a113cde6072fce705005969a8 X-Spam-Score: -0.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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XGoOs-0005Jl-8q Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties 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, 11 Aug 2014 12:08:31 -0000 --001a113cde6072fce705005969a8 Content-Type: text/plain; charset=UTF-8 Putting the efficacy of coinjoin to one side: On Mon, Aug 11, 2014 at 1:38 PM, Tim Ruffing < tim.ruffing@mmci.uni-saarland.de> wrote: > Then the only remaining reason why it could be invalid is that the input > could have > been spent already otherwise. But in this case, only one honest client with > full information would suffice: a signed transaction that spends the money > would convince even SPV-clients that the participant with this inputs > tries to > cheat. Bear in mind that getutxo does not return the spending transaction - it can't because the UTXO set doesn't record this information (a spent txo is deleted). However, if you have sufficient peers and one is honest, the divergence can be detected and the operation stopped/the user alerted. If all peers are lying i.e. your internet connection is controlled by an attacker, it doesn't really make much difference because they could swallow the transaction you're trying to broadcast anyway. Ultimately if your peers think a TXO is spent and refuse to relay transactions that spend them, you can't do much about it even in the non-SPV context: you *must* be able to reach at least one peer who believes in the same world as you do. --001a113cde6072fce705005969a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Putting the efficacy of coinjoin to one side:

On Mon, Aug 11, 2014 at 1:38 P= M, Tim Ruffing <tim.ruffing@mmci.uni-saarland.de> wrote:
Then=C2=A0the only remaining reason why it c= ould be invalid is that the input could have
been spent already otherwise. But in this case, only one honest client with=
full information would suffice: a signed transaction that spends the money<= br> would convince even SPV-clients that the participant with this inputs tries= to
cheat.

Bear in mind that getutxo does not r= eturn the spending transaction - it can't because the UTXO set doesn= 9;t record this information (a spent txo is deleted).=C2=A0

<= /div>
However, if you have sufficient peers and one is honest, the divergenc= e can be detected and the operation stopped/the user alerted. If all peers = are lying i.e. your internet connection is controlled by an attacker, it do= esn't really make much difference because they could swallow the transa= ction you're trying to broadcast anyway. Ultimately if your peers think= a TXO is spent and refuse to relay transactions that spend them, you can&#= 39;t do much about it even in the non-SPV context: you must=C2=A0be = able to reach at least one peer who believes in the same world as you do.

--001a113cde6072fce705005969a8--