<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Mike Hearn, why don&#39;t we just have all nodes report attempted double spends through the node network.</div></blockquote><div><br></div><div>Please see <a href="https://github.com/bitcoin/bitcoin/pull/3883">https://github.com/bitcoin/bitcoin/pull/3883</a> which implements this exact scheme. It can solve some kinds of double spends (probably), but others - like ones done by corrupt miners (see bitundo) - can&#39;t be solved this way.</div>
<div><br></div><div>Lawrence&#39;s motivation for this BIP is essentially to act as a backup in case the Bitcoin native double spending protections end up being too weak to be useful. It reintroduces a notion of centralised trust as a layer on top of the Bitcoin protocol, but only for cases where the seller/recipient feels it&#39;d be useful. In this way it gives us slack: if someone is able to reliably double spend and the merchants losses due to payment fraud go up, we can fall back to TTPs for a while until someone finds a solution for Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we now have a better intermediary protocol than SWIFT :-)</div>
<div><br></div><div>In practice of course this is something payment processors like Bitpay and Coinbase will think about. Individual cafes etc who are just using mobile wallets won&#39;t be able to deal with this complexity: if we can&#39;t make native Bitcoin work well enough there, we&#39;re most likely to just lose that market or watch it become entirely centralised around a handful of payment processing companies.</div>
<div><br></div><div><br></div></div></div></div>