summaryrefslogtreecommitdiff
path: root/7d/a36658baf052358661f0f0da5e5337f3c67aea
blob: a7385aef1b7d51bde01cfd323d6bd8a6065d84f1 (plain)
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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1UedF8-0001M0-9a
	for bitcoin-development@lists.sourceforge.net;
	Tue, 21 May 2013 03:28:06 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.46 as permitted sender)
	client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f46.google.com; 
Received: from mail-oa0-f46.google.com ([209.85.219.46])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UedF7-0005Cj-AG
	for bitcoin-development@lists.sourceforge.net;
	Tue, 21 May 2013 03:28:06 +0000
Received: by mail-oa0-f46.google.com with SMTP id h2so196950oag.5
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 20 May 2013 20:28:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.124.18 with SMTP id me18mr233289oeb.100.1369106879997;
	Mon, 20 May 2013 20:27:59 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.11.230 with HTTP; Mon, 20 May 2013 20:27:59 -0700 (PDT)
Received: by 10.76.11.230 with HTTP; Mon, 20 May 2013 20:27:59 -0700 (PDT)
In-Reply-To: <CAPg+sBjmXyLkgfwzC8h+ZFkmyUf6nzbGo0oAWR9nsJOTOfOXEg@mail.gmail.com>
References: <519AC3A8.1020306@quinnharris.me>
	<CA+i0-i_+Tes+ePRqmDGEXDQ_L=S5y8gHBKk77zaLgTGOS3OMyA@mail.gmail.com>
	<CAPg+sBjmXyLkgfwzC8h+ZFkmyUf6nzbGo0oAWR9nsJOTOfOXEg@mail.gmail.com>
Date: Mon, 20 May 2013 20:27:59 -0700
X-Google-Sender-Auth: 1i7GVk6631PiScz7VX_kXI-s9pU
Message-ID: <CANEZrP1inofLkfcb3q+_yBd6ZX0OGs-mNbcmu9+ECwn5wVD7jw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b4503043df0d504dd320913
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: 1UedF7-0005Cj-AG
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Double Spend Notification
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: Tue, 21 May 2013 03:28:06 -0000

--047d7b4503043df0d504dd320913
Content-Type: text/plain; charset=UTF-8

Indeed, that has been proposed but it's a dumb idea and I'm very sceptical
it will go anywhere.  Certainly no decision was made. The arguments for it
are based on some quite faulty thinking about economics. Double spend
notifications have been proposed a long time ago, I believe Matt has
indicated some interest in implementing them and that is the right way to
go.
On 20 May 2013 18:57, "Pieter Wuille" <pieter.wuille@gmail.com> wrote:

> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus <robbak@robbak.com>
> wrote:
> > So the decision has been made to make 0-conf double spends trivial, so no
> > one will ever trust 0-confs. If a later transaction appears with a larger
> > fee, it will be considered to be the valid one, and the first one
> dropped,
> > as long as the first one has not been confirmed. This makes undoing a
> > mistaken transaction possible.
>
> This has been suggested, but I know of no such decision having been made.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--047d7b4503043df0d504dd320913
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Indeed, that has been proposed but it&#39;s a dumb idea and =
I&#39;m very sceptical it will go anywhere.=C2=A0 Certainly no decision was=
 made. The arguments for it are based on some quite faulty thinking about e=
conomics. Double spend notifications have been proposed a long time ago, I =
believe Matt has indicated some interest in implementing them and that is t=
he right way to go.</p>

<div class=3D"gmail_quote">On 20 May 2013 18:57, &quot;Pieter Wuille&quot; =
&lt;<a href=3D"mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.com</a>&=
gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus &lt;<a href=3D"mailto:robb=
ak@robbak.com">robbak@robbak.com</a>&gt; wrote:<br>
&gt; So the decision has been made to make 0-conf double spends trivial, so=
 no<br>
&gt; one will ever trust 0-confs. If a later transaction appears with a lar=
ger<br>
&gt; fee, it will be considered to be the valid one, and the first one drop=
ped,<br>
&gt; as long as the first one has not been confirmed. This makes undoing a<=
br>
&gt; mistaken transaction possible.<br>
<br>
This has been suggested, but I know of no such decision having been made.<b=
r>
<br>
--<br>
Pieter<br>
<br>
---------------------------------------------------------------------------=
---<br>
Try New Relic Now &amp; We&#39;ll Send You this Cool Shirt<br>
New Relic is the only SaaS-based application performance monitoring service=
<br>
that delivers powerful full stack analytics. Optimize and monitor your<br>
browser, app, &amp; servers with just a few lines of code. Try New Relic<br=
>
and get this awesome Nerd Life shirt! <a href=3D"http://p.sf.net/sfu/newrel=
ic_d2d_may" target=3D"_blank">http://p.sf.net/sfu/newrelic_d2d_may</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--047d7b4503043df0d504dd320913--