diff options
| author | Mike Hearn <mike@plan99.net> | 2014-08-11 14:08:24 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-08-11 12:08:31 +0000 |
| commit | 6fa50d6b6d87f04a80dd93585ea9cfe7f75330f1 (patch) | |
| tree | a519b3b8dc0b6fc1cef34759ec513677b1830dad | |
| parent | 77882367a258c82e7585922beaad41a5352a80b4 (diff) | |
| download | pi-bitcoindev-6fa50d6b6d87f04a80dd93585ea9cfe7f75330f1.tar.gz pi-bitcoindev-6fa50d6b6d87f04a80dd93585ea9cfe7f75330f1.zip | |
Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties
| -rw-r--r-- | d8/e982be8237a8792acec897d42f6014a4fd1286 | 129 |
1 files changed, 129 insertions, 0 deletions
diff --git a/d8/e982be8237a8792acec897d42f6014a4fd1286 b/d8/e982be8237a8792acec897d42f6014a4fd1286 new file mode 100644 index 000000000..d90f5c83e --- /dev/null +++ b/d8/e982be8237a8792acec897d42f6014a4fd1286 @@ -0,0 +1,129 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1XGoOt-000441-6c + for bitcoin-development@lists.sourceforge.net; + Mon, 11 Aug 2014 12:08:31 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.219.43 as permitted sender) + client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; + helo=mail-oa0-f43.google.com; +Received: from mail-oa0-f43.google.com ([209.85.219.43]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1XGoOs-0005Jl-8q + for bitcoin-development@lists.sourceforge.net; + Mon, 11 Aug 2014 12:08:31 +0000 +Received: by mail-oa0-f43.google.com with SMTP id i7so6031542oag.30 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 11 Aug 2014 05:08:24 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.202.186.3 with SMTP id k3mr201631oif.18.1407758904784; Mon, + 11 Aug 2014 05:08:24 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.97.132 with HTTP; Mon, 11 Aug 2014 05:08:24 -0700 (PDT) +In-Reply-To: <1446506.FNP3GnOpud@calzone> +References: <8137823.B0x87S28xY@calzone> + <CAB+qUq6_ukUYnBkb3exOM+rSRSBz1ho2j60G1oxnLx4_zM91SQ@mail.gmail.com> + <CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com> + <1446506.FNP3GnOpud@calzone> +Date: Mon, 11 Aug 2014 14:08:24 +0200 +X-Google-Sender-Auth: VQoxeYDbr_RkgWKJoKCCXL_vdlw +Message-ID: <CANEZrP0CLMgCsJnW4-CSLnH_n4Gzb_BuiqOSAn29x-qJM1vEJA@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de> +Content-Type: multipart/alternative; boundary=001a113cde6072fce705005969a8 +X-Spam-Score: -0.5 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1XGoOs-0005Jl-8q +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin + without trusted third parties +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 11 Aug 2014 12:08:31 -0000 + +--001a113cde6072fce705005969a8 +Content-Type: text/plain; charset=UTF-8 + +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. + +--001a113cde6072fce705005969a8 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Putting the efficacy of coinjoin to one side:<div class=3D= +"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Aug 11, 2014 at 1:38 P= +M, Tim Ruffing <span dir=3D"ltr"><<a href=3D"mailto:tim.ruffing@mmci.uni= +-saarland.de" target=3D"_blank">tim.ruffing@mmci.uni-saarland.de</a>></s= +pan> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex">Then=C2=A0the only remaining reason why it c= +ould be invalid is that the input could have<br> +been spent already otherwise. But in this case, only one honest client with= +<br> +full information would suffice: a signed transaction that spends the money<= +br> +would convince even SPV-clients that the participant with this inputs tries= + to<br> +cheat.</blockquote><div><br></div><div>Bear in mind that getutxo does not r= +eturn the spending transaction - it can't because the UTXO set doesn= +9;t record this information (a spent txo is deleted).=C2=A0</div><div><br><= +/div> +<div>However, if you have sufficient peers and one is honest, the divergenc= +e 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 do= +esn't really make much difference because they could swallow the transa= +ction 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&#= +39;t do much about it even in the non-SPV context: you <i>must</i>=C2=A0be = +able to reach at least one peer who believes in the same world as you do.</= +div> +<div><br></div></div></div></div> + +--001a113cde6072fce705005969a8-- + + |