From: Mike Hearn <mike@plan99•net>
To: Paul Goldstein <paul@realfoot•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Date: Mon, 16 Jun 2014 17:48:28 +0200 [thread overview]
Message-ID: <CANEZrP3KKSkD7_R0Dvt600b7vh0oia78vHhPrPqSGBbwf9DsSQ@mail.gmail.com> (raw)
In-Reply-To: <CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]
>
> Mike Hearn, why don't we just have all nodes report attempted double
> spends through the node network.
>
Please see https://github.com/bitcoin/bitcoin/pull/3883 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't be solved
this way.
Lawrence'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'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 :-)
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't be able to deal with this complexity: if we can't make native
Bitcoin work well enough there, we're most likely to just lose that market
or watch it become entirely centralised around a handful of payment
processing companies.
[-- Attachment #2: Type: text/html, Size: 1855 bytes --]
next prev parent reply other threads:[~2014-06-16 15:48 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 12:00 Lawrence Nahum
2014-06-14 12:57 ` Andreas Schildbach
2014-06-15 9:22 ` Lawrence Nahum
2014-06-15 12:46 ` Andreas Schildbach
2014-06-15 14:09 ` Lawrence Nahum
2014-06-18 12:09 ` Lawrence Nahum
2014-06-18 13:25 ` Mike Hearn
2014-06-18 15:59 ` Daniel Rice
2014-06-18 16:09 ` Mike Hearn
2014-06-19 17:36 ` Daniel Rice
2014-06-25 14:01 ` sebastien requiem
2014-06-16 12:19 ` Mike Hearn
2014-06-16 12:25 ` Mike Hearn
2014-06-16 15:09 ` Daniel Rice
2014-06-16 15:26 ` Lawrence Nahum
2014-06-16 16:00 ` Daniel Rice
2014-06-16 16:07 ` Mike Hearn
2014-06-16 15:41 ` Paul Goldstein
2014-06-16 15:48 ` Mike Hearn [this message]
2014-06-16 16:30 ` Lawrence Nahum
2014-06-16 16:45 ` Mike Hearn
2014-06-16 16:56 ` Lawrence Nahum
2014-06-16 17:01 ` Mike Hearn
2014-06-16 17:16 ` Lawrence Nahum
2014-06-16 18:02 ` Alex Kotenko
2014-06-16 18:09 ` Mike Hearn
2014-06-16 20:29 ` Daniel Rice
2014-06-16 20:32 ` Mike Hearn
2014-06-16 20:37 ` Daniel Rice
2014-06-16 20:46 ` Mike Hearn
2014-06-16 20:53 ` Daniel Rice
2014-06-16 20:55 ` Mike Hearn
2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
2014-06-16 21:02 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Daniel Rice
2014-06-16 20:32 ` Alex Kotenko
2014-06-16 17:44 ` Jorge Timón
2014-06-17 15:58 ` Isidor Zeuner
2014-06-18 1:39 ` Tom Harding
2014-06-17 15:58 ` Isidor Zeuner
2014-06-18 9:15 ` Mike Hearn
2014-06-18 20:47 ` Natanael
2014-06-18 2:01 ` Tom Harding
2014-06-16 15:28 ` Lawrence Nahum
2014-06-16 15:43 ` Mike Hearn
2014-06-16 17:05 ` Lawrence Nahum
2014-06-16 8:53 Daniel Rice
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=CANEZrP3KKSkD7_R0Dvt600b7vh0oia78vHhPrPqSGBbwf9DsSQ@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=paul@realfoot$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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