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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XGt3i-0000rB-7N for bitcoin-development@lists.sourceforge.net; Mon, 11 Aug 2014 17:06:58 +0000 Received: from mail-qc0-f178.google.com ([209.85.216.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XGt3e-000844-Di for bitcoin-development@lists.sourceforge.net; Mon, 11 Aug 2014 17:06:58 +0000 Received: by mail-qc0-f178.google.com with SMTP id x3so1802569qcv.37 for ; Mon, 11 Aug 2014 10:06:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nog5N5XC9aOHADAdnopDjLiHLHYTHRCtpxfIp7ObZ/4=; b=beE85SaHF5kkK5K15TjvYHRK4gVFGdPjYi4OaeJ/BcsemMDrA/151ki4XB0Aj+dFTQ 2uupe5Ca5MBiCNQtKbE2i3csUpj2kDO/PT/ORrwGmBKy15e0WYUvPWogCJXz+VrdRWu5 tpzJIMRIA/gPvUK6ISJJUNWlfPjDuD/Tt6B9FjP+XVdCTRQtENAYN3VFBXgoeNuEQnq7 tqL68BIf7Q0U2s0Sm/63T5oA6WHi+Cdfl8y9xkb7N3K2YzlPx9KNfxUWQjEkeqbZZzPv VQ6E97y0jP+f6IVqWSewmJV17wC0RJGZtMW7CSg1wUY8g4nKiWh/ivRJ0ounXb8IcX5u rxPg== X-Gm-Message-State: ALoCoQmuxM7X5OK2a8nndkNX3nrRNAb8EL0togHpdmu8Oc792FayW18NhIZYjVRo7RXHpa6ZAsJs MIME-Version: 1.0 X-Received: by 10.224.123.8 with SMTP id n8mr66016109qar.40.1407776808771; Mon, 11 Aug 2014 10:06:48 -0700 (PDT) Received: by 10.140.47.175 with HTTP; Mon, 11 Aug 2014 10:06:48 -0700 (PDT) X-Originating-IP: [50.0.37.37] In-Reply-To: <1446506.FNP3GnOpud@calzone> References: <8137823.B0x87S28xY@calzone> <1446506.FNP3GnOpud@calzone> Date: Mon, 11 Aug 2014 10:06:48 -0700 Message-ID: From: Mark Friedenbach To: Tim Ruffing Content-Type: multipart/alternative; boundary=089e0149ca709c3c8e05005d944b X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1XGt3e-000844-Di 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 17:06:58 -0000 --089e0149ca709c3c8e05005d944b Content-Type: text/plain; charset=UTF-8 There should not be a requirement at this level to ensure validity. That would too constrain use cases of implementations of your protocol. It is not difficult to imagine use cases where parties generate chained transactions on top of unconfimed transactions. Although malleability currently makes this difficult to do safely in general, it is not inconceivable that there are circumstances where it would nevertheless be safe or otherwise desireable. It is a good security recommendation that clients validate the inputs to a shuffle they are participating in. What this means depends on the client -- checking the UTXO set for a full node, making some getutxos queries for a SPV client. But this should remain a recommendation, not a requirement. On Mon, Aug 11, 2014 at 4:38 AM, Tim Ruffing < tim.ruffing@mmci.uni-saarland.de> wrote: > 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. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e0149ca709c3c8e05005d944b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There should not be a requirement at this level to en= sure validity. That would too constrain use cases of implementations of you= r protocol. It is not difficult to imagine use cases where parties generate= chained transactions on top of unconfimed transactions. Although malleabil= ity currently makes this difficult to do safely in general, it is not incon= ceivable that there are circumstances where it would nevertheless be safe o= r otherwise desireable.

It is a good security recommendation that clients validate the in= puts to a shuffle they are participating in. What this means depends on the= client -- checking the UTXO set for a full node, making some getutxos quer= ies for a SPV client. But this should remain a recommendation, not a requir= ement.


On Mon,= Aug 11, 2014 at 4:38 AM, Tim Ruffing <tim.ruffing@mmci.uni= -saarland.de> wrote:
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 reasonabl= e 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. Somethin= g like
getUTXO seems to be a possibility. I think even SPV-clients can verify the<= br> validity of the tx that created the input that is designated for mixing. Th= en
the only remaining reason why it could be invalid is that the input could h= ave
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. This transaction could even be provided by lightweight client that g= ot
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 authen= ticated
> but it should be good enough for this purpose. The worst that would ha= ppen
> 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 t= he p2p
> > variety) cannot perform this check.
> >
> > You could skip the verification part and if the inputs turn out t= o be
> > invalid then you'll find out when it doesn't confirm. Thi= s 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 pro= of for
> > the input. This would require inputs to have at least one confirm= ation,
> > however.

-----------------------------------------= -------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e0149ca709c3c8e05005d944b--