public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties
Date: Mon, 11 Aug 2014 14:08:24 +0200	[thread overview]
Message-ID: <CANEZrP0CLMgCsJnW4-CSLnH_n4Gzb_BuiqOSAn29x-qJM1vEJA@mail.gmail.com> (raw)
In-Reply-To: <1446506.FNP3GnOpud@calzone>

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

Putting the efficacy of coinjoin to one side:

On Mon, Aug 11, 2014 at 1:38 PM, Tim Ruffing <
tim.ruffing@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.

[-- Attachment #2: Type: text/html, Size: 1607 bytes --]

  reply	other threads:[~2014-08-11 12:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-06 22:22 [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties Tim Ruffing
2014-08-07 13:00 ` xor
2014-08-09 10:04   ` Tim Ruffing
2014-08-09 13:10     ` Sergio Lerner
2014-08-09 20:17       ` Mark Friedenbach
2014-08-11  6:25 ` Chris Pacia
2014-08-11  6:30   ` Chris Pacia
2014-08-11 11:38     ` Tim Ruffing
2014-08-11 12:08       ` Mike Hearn [this message]
2014-08-11 17:06       ` Mark Friedenbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANEZrP0CLMgCsJnW4-CSLnH_n4Gzb_BuiqOSAn29x-qJM1vEJA@mail.gmail.com \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=tim.ruffing@mmci.uni-saarland.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox