From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XGnwB-0004Sf-Gv for bitcoin-development@lists.sourceforge.net; Mon, 11 Aug 2014 11:38:51 +0000 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; Received: from infao0809.mpi-klsb.mpg.de ([139.19.1.49] helo=hera.mpi-klsb.mpg.de) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1XGnw9-0005Kz-QB for bitcoin-development@lists.sourceforge.net; Mon, 11 Aug 2014 11:38:51 +0000 Received: from zak.mpi-klsb.mpg.de ([139.19.1.29]:54225) by hera.mpi-klsb.mpg.de (envelope-from ) with esmtp (Exim 4.80) id 1XGnw0-0005pS-BQ; Mon, 11 Aug 2014 13:38:42 +0200 Received: from [141.70.80.5] (port=45471 helo=calzone.localnet) by zak.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) id 1XGnvz-0007lO-Vu; Mon, 11 Aug 2014 13:38:40 +0200 From: Tim Ruffing To: Chris Pacia 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: References: <8137823.B0x87S28xY@calzone> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart140776882.gREGzQnYAN"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-MPI-Local-Sender: true X-Spam-Score: -1.6 (-) 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 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1XGnw9-0005Kz-QB Cc: bitcoin-development@lists.sourceforge.net 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 11:38:51 -0000 --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" 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--