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
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 ctpa...@gmail.com wrote:
One issue I do see is the protocol requires participants
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
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
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
You are raising valid questions and one goal of our posting here is indeed to
discuss exactly these system issues.
On Thursday 07 August 2014 15:00:11 you wrote:
I think the description at your website leaves out the truly interesting
part: How do you decentralize this securely?
- How do
Hi Tim,
It's clear from the paper that the second party in the protocol can
de-anonymize the first party. So it's seems that dishonest shufflers
would prefer to be in that position in the queue.
There are two possible solutions to this:
1. Derive the first order of parties in the shuffle from
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner sergioler...@certimix.com
wrote:
Hi Tim,
It's clear from the paper that the second party in the protocol can
de-anonymize the first party. So it's seems that dishonest shufflers would
prefer to be in that position in the queue.
That's not
On Thursday, August 07, 2014 12:22:31 AM Tim Ruffing wrote:
- Decentralization / no third party:
There is no (trusted or untrusted) third party in a run of the protocol.
(Still, as in all mixing solutions, users need some way to gather together
before they can run the protocol. This can be
9 matches
Mail list logo
