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
5 matches
Mail list logo
