Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of
	mmci.uni-saarland.de designates 139.19.1.49 as permitted
	sender) client-ip=139.19.1.49;
	envelope-from=tim.ruffing@mmci.uni-saarland.de;
	helo=hera.mpi-klsb.mpg.de; 
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: Chris Pacia <ctpacia@gmail.com>
Date: Mon, 11 Aug 2014 13:38:39 +0200
Message-ID: <1446506.FNP3GnOpud@calzone>
User-Agent: KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
References: <8137823.B0x87S28xY@calzone>
	<CAB+qUq6_ukUYnBkb3exOM+rSRSBz1ho2j60G1oxnLx4_zM91SQ@mail.gmail.com>
	<CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart140776882.gREGzQnYAN";
	micalg="pgp-sha1"; protocol="application/pgp-signature"
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin
	without trusted third parties
Precedence: list


--nextPart140776882.gREGzQnYAN
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

Hmm, you are right. Lightweight clients are an interesting point, we have to 
think about a policy for them.

As you said, the worst case is that the tx will not confirm. So the only 
possible attack is DoS. For clients that rely on servers it's reasonable to 
trust their servers not to perform DoS. (Anyway, the servers could do worse 
attacks.)

For SPV-clients (without servers), I'm not sure at the moment. Something like 
getUTXO seems to be a possibility. I think even SPV-clients can verify the 
validity of the tx that created the input that is designated for mixing. 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. This transaction could even be provided by lightweight client that got 
if from a server; the transaction is signed by the cheating participant 
anyway.

Tim

On Monday 11 August 2014 02:30:16 Chris Pacia wrote:
> Actually getUTXO would probably work here as well. It isn't authenticated
> but it should be good enough for this purpose. The worst that would happen
> is the tx doesn't confirm.
> 
> On Aug 11, 2014 2:25 AM, "Chris Pacia" <ctpacia@gmail.com> wrote:
> > One issue I do see is the protocol requires participants to check the
> > inputs submitted by others are valid. Lite clients (at least of the p2p
> > variety) cannot perform this check.
> > 
> > You could skip the verification part and if the inputs turn out to be
> > invalid then you'll find out when it doesn't confirm. This would problem
> > open the protocol up to dos attacks and prevent part of the "blame" phase
> > from working properly.
> > 
> > Alternatively you can have the participants submit the merkle proof for
> > the input. This would require inputs to have at least one confirmation,
> > however.
--nextPart140776882.gREGzQnYAN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAABAgAGBQJT6Ks/AAoJEKAmVAtPJmh7o2sL/3SHsMrAnX/EGwWOMf1/tIpq
p65SZecMtJChSIic411M/h14uHn8DZ3faWhetj89/VHv3GSgGE4tpwk+9AYfEss5
NfdRzBlrJ80tu7vxmfat3HfwtZl+AzYA/omioIynW6s9Mat47HQzAINFajCvVq/i
U9WfYaJnMgd2ruic6eGQYiBRZKregCpVIV9yxqFJtFNWpkODY8JHw3R+FUbNutQI
69p9DS5iAx8BWLOPsAqq9vBivkwiDcRtfc2AyminxO6KzcmfAKFGZie30M5IFd9a
hysS7fdBJPjXw9yY+voWFr92bCP4Cc6IWpP5IXPNGJ8vfbPQjBLe2PPcxEto7d7j
zAF3HBpfdFC6OJ+mh+kaQ0ooF1HN4Rz7H2yRe7VLK1loVT+hToULTqrEVnKVnWUM
6Y8wP4TaQQZjnyqeJAoDLpQG6hihBOe6l2pjosefyZqO1NCgHwDuJ73tDMfmzPIH
huus7jeC/qkcTSZ7mtOlHPmRpCDBgOxf82S7WFMrcA==
=SNhx
-----END PGP SIGNATURE-----

--nextPart140776882.gREGzQnYAN--