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 t
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 wi
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
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
> i
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 confi
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner
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 clear to me. The 2nd part
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 the
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 Al
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
Hey,
We (a group of researchers in Germany) propose a decentralized protocol for
CoinJoin, a way to mix coins among users to improve anonymity. Our protocol is
called CoinShuffle. We believe that CoinShuffle is a way to implement CoinJoin
in the original spirit of Bitcoin, i.e., decentralized a
10 matches
Mail list logo