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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <1446506.FNP3GnOpud@calzone>
References: <8137823.B0x87S28xY@calzone>
	<CAB+qUq6_ukUYnBkb3exOM+rSRSBz1ho2j60G1oxnLx4_zM91SQ@mail.gmail.com>
	<CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
	<1446506.FNP3GnOpud@calzone>
Date: Mon, 11 Aug 2014 14:08:24 +0200
Message-ID: <CANEZrP0CLMgCsJnW4-CSLnH_n4Gzb_BuiqOSAn29x-qJM1vEJA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
Content-Type: multipart/alternative; boundary=001a113cde6072fce705005969a8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin
 without trusted third parties
Precedence: list

--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

<div dir=3D"ltr">Putting the efficacy of coinjoin to one side:<div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Aug 11, 2014 at 1:38 P=
M, Tim Ruffing <span dir=3D"ltr">&lt;<a href=3D"mailto:tim.ruffing@mmci.uni=
-saarland.de" target=3D"_blank">tim.ruffing@mmci.uni-saarland.de</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Then=C2=A0the only remaining reason why it c=
ould be invalid is that the input could have<br>
been spent already otherwise. But in this case, only one honest client with=
<br>
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<br>
cheat.</blockquote><div><br></div><div>Bear in mind that getutxo does not r=
eturn the spending transaction - it can&#39;t because the UTXO set doesn=
9;t record this information (a spent txo is deleted).=C2=A0</div><div><br><=
/div>
<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&#39;t really make much difference because they could swallow the transa=
ction you&#39;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 <i>must</i>=C2=A0be =
able to reach at least one peer who believes in the same world as you do.</=
div>
<div><br></div></div></div></div>

--001a113cde6072fce705005969a8--