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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Uedej-0002bM-2d
for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 03:54:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.178 as permitted sender)
client-ip=209.85.217.178; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f178.google.com;
Received: from mail-lb0-f178.google.com ([209.85.217.178])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Uedei-0004dc-7k
for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 03:54:33 +0000
Received: by mail-lb0-f178.google.com with SMTP id w10so260348lbi.37
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 20:54:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.26.225 with SMTP id o1mr240866lag.43.1369108465400; Mon,
20 May 2013 20:54:25 -0700 (PDT)
Received: by 10.112.69.140 with HTTP; Mon, 20 May 2013 20:54:25 -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:54:25 -0700
Message-ID: <CAAS2fgRCpXUgw=GpE9_AcTgWcdCaDC6_16Xp5+oOZC0_1xmf-w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Uedei-0004dc-7k
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:54:33 -0000
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille <pieter.wuille@gmail.com> wr=
ote:
> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus <robbak@robbak.com> wrot=
e:
>> So the decision has been made to make 0-conf double spends trivial, so n=
o
>> one will ever trust 0-confs. If a later transaction appears with a large=
r
>> fee, it will be considered to be the valid one, and the first one droppe=
d,
>> 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.
Indeed. I've argued against it pretty aggressively, but I am starting
to find arguments for and against pure fee-based replacement more
equally persuasive.
Regardless of the eventual outcome, fees today aren't a major
motivator vs subsidy and overall network health=E2=80=94 and even if some
protection isn't 100% there are plenty of cases where the risk is
averaged across many small transactions and any reduction of risk is a
reduction in operating cost. (No one is going to double spend your
soda machine at high speed=E2=80=94 so you can like increase your prices by
the amount of successful double spends you experience and call it
done)
On the other hand, it's well established that people underestimate the
costs of unlikely risks. More deterministic behavior can result in
safer interactions more than _better_ behavior. If we believe that in
the long term self-interest will result in pure-fee based replacement
being wide spread then it is also good to not build a dependency on
behavior that will not last.
One point that was only recently exposed to me is that replacement
combined with child-pays-for-parent creates a new kind of double spend
_defense_: If someone double spends a payment to an online key of
yours, you can instantly produce a child transaction that pays 100% of
the double spend to fees... so a double spender can hurt you but not
profit from it. (and if your side of the transaction is
potentially/partially reversible he will lose)...
But then again, a race to burn more money is kinda ... odd and even if
the benefit of resisting the double spends is only a short term
benefit, a short term benefit can be greatly important in encouraging
Bitcoin adoption. ... and the long term behavior is far from certain.
So at least from my position it's far from clear what should be done here.
I've noticed a number of people who seem to be swayed by replace by
fee=E2=80=94 or at least its inevitability if not value. So even ignoring
developers there may evolve a community consensus here regardless of
what I think about it.
My SO pointed that that the transaction burning race described above
sounds like an economists wet dream: it's one of those silly cases
they use in experiments to probe human behavior... except it sounds
like a possible eventual outcome in systems used by people. Perhaps
it would be useful to point some graduate students at this question
and see what they can come up with about it.
|
