Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-11 Thread Mark Friedenbach
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.ruff...@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
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-11 Thread Mike Hearn
Putting the efficacy of coinjoin to one side:

On Mon, Aug 11, 2014 at 1:38 PM, Tim Ruffing <
tim.ruff...@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.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-11 Thread Tim Ruffing
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.

signature.asc
Description: This is a digitally signed message part.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development