From: Tim Ruffing <tim.ruffing@mmci•uni-saarland.de>
To: Chris Pacia <ctpacia@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties
Date: Mon, 11 Aug 2014 13:38:39 +0200 [thread overview]
Message-ID: <1446506.FNP3GnOpud@calzone> (raw)
In-Reply-To: <CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]
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.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 648 bytes --]
next prev parent reply other threads:[~2014-08-11 11:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-06 22:22 Tim Ruffing
2014-08-07 13:00 ` xor
2014-08-09 10:04 ` Tim Ruffing
2014-08-09 13:10 ` Sergio Lerner
2014-08-09 20:17 ` Mark Friedenbach
2014-08-11 6:25 ` Chris Pacia
2014-08-11 6:30 ` Chris Pacia
2014-08-11 11:38 ` Tim Ruffing [this message]
2014-08-11 12:08 ` Mike Hearn
2014-08-11 17:06 ` Mark Friedenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1446506.FNP3GnOpud@calzone \
--to=tim.ruffing@mmci$(echo .)uni-saarland.de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=ctpacia@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox