1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
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 1WwZ9A-0001kP-2W
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 15:48:36 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwZ98-0001tL-Cb
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 15:48:36 +0000
Received: by mail-ob0-f179.google.com with SMTP id uz6so6016187obc.10
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 08:48:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.114.229 with SMTP id jj5mr21019584obb.53.1402933708669;
Mon, 16 Jun 2014 08:48:28 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 08:48:28 -0700 (PDT)
In-Reply-To: <CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
<CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
Date: Mon, 16 Jun 2014 17:48:28 +0200
X-Google-Sender-Auth: rS4XYbr7fCunbfkEpQc5jcjLxRs
Message-ID: <CANEZrP3KKSkD7_R0Dvt600b7vh0oia78vHhPrPqSGBbwf9DsSQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Paul Goldstein <paul@realfoot.com>
Content-Type: multipart/alternative; boundary=001a11c2f644594a3b04fbf5f53f
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: 1WwZ98-0001tL-Cb
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
backwards compatible proto buffer extension
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, 16 Jun 2014 15:48:36 -0000
--001a11c2f644594a3b04fbf5f53f
Content-Type: text/plain; charset=UTF-8
>
> 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.
--001a11c2f644594a3b04fbf5f53f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div dir=3D"ltr">Mike Hearn, why don't we just have all nodes report at=
tempted double spends through the node network.</div></blockquote><div><br>=
</div><div>Please see <a href=3D"https://github.com/bitcoin/bitcoin/pull/38=
83">https://github.com/bitcoin/bitcoin/pull/3883</a> which implements this =
exact scheme. It can solve some kinds of double spends (probably), but othe=
rs - like ones done by corrupt miners (see bitundo) - can't be solved t=
his way.</div>
<div><br></div><div>Lawrence's motivation for this BIP is essentially t=
o act as a backup in case the Bitcoin native double spending protections en=
d up being too weak to be useful. It reintroduces a notion of centralised t=
rust as a layer on top of the Bitcoin protocol, but only for cases where th=
e 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 t=
o payment fraud go up, we can fall back to TTPs for a while until someone f=
inds 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 process=
ors 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 aro=
und a handful of payment processing companies.</div>
<div><br></div><div><br></div></div></div></div>
--001a11c2f644594a3b04fbf5f53f--
|
