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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1WjiUd-0004zd-EL
for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 05:09:39 +0000
X-ACL-Warn:
Received: from mail-pa0-f50.google.com ([209.85.220.50])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WjiUc-0001zF-6T
for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 05:09:39 +0000
Received: by mail-pa0-f50.google.com with SMTP id fb1so7646953pad.9
for <bitcoin-development@lists.sourceforge.net>;
Sun, 11 May 2014 22:09:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=KNfNxv8aUslnMOgmdhZUMlT8vsMkwNBh+q1IV9y7Pqs=;
b=KzewNOehNmDqc3kuDNLMBfEDav7gxFkaF4132FqVngMNKmGCpd8v6fPKRDASXqvBBC
gFuiIR5ieyg61EKPFnjV2nGBhnVI9Oqyd/d0ifbFYNmn7nM/X2KEbJoB3E96PQXPq7Ur
VTHydt7ZlNM6LUnJ5AM0HipzRf3BmA9lJhwSJgY4rVdJHItcNAIDvOay3vzUhVlRG3Uo
XsaY3bzPJf9hMwaav68CLt4FGiFNXe2yd5BkP2e/nuM2Wojd6FPHsoMZ1Go+sWuf8/cT
8rXxJXuulZSNimcGeYSxJ1yFXCt1FaeVEQGXuQwG9AfPb8r6u4ye45yeC0CJWPGFuul6
dGPQ==
X-Gm-Message-State: ALoCoQkpQksDmHIkdpDCU+KunTx4chV/Imi1yPgfF6uVbNPWOrnlnHBVs9xkxNHa7OHQLhJsTZNs
X-Received: by 10.66.230.193 with SMTP id ta1mr50819792pac.29.1399869668134;
Sun, 11 May 2014 21:41:08 -0700 (PDT)
Received: from [192.168.1.89] (99-6-44-248.lightspeed.sntcca.sbcglobal.net.
[99.6.44.248]) by mx.google.com with ESMTPSA id
jd5sm20395752pbb.18.2014.05.11.21.41.06
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 11 May 2014 21:41:07 -0700 (PDT)
Message-ID: <537050E0.2040008@thinlink.com>
Date: Sun, 11 May 2014 21:41:04 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <536589CC.8080005@thinlink.com>
<CANOOu=_tpqz8wdDGj9x_xT5QcT=CHRbr+5Cewj5xuZyJ+ZurNw@mail.gmail.com>
In-Reply-To: <CANOOu=_tpqz8wdDGj9x_xT5QcT=CHRbr+5Cewj5xuZyJ+ZurNw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WjiUc-0001zF-6T
Subject: Re: [Bitcoin-development] A statistical consensus rule for reducing
0-conf double-spend risk
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, 12 May 2014 05:09:39 -0000
Christophe Biocca wrote:
> The problem is that since the rule
> isn't enforceable, no miner will wait before mining on the longest
> chain (which is the rational move), and you're back to where we are
> now.
Back up to the miner who decided to include a "seasoned" double-spend in
his block. Let's say he saw it 21 seconds after he saw an earlier
spend, and included it, despite the rule.
The expected cost of including the respend is any revenue loss from
doing so: (total miner revenue of block)*(fraction of hashpower
following the rule). So today, if only 1% of hashpower follows the rule
(ie a near total failure of consensus implementation), he still loses at
least .25 BTC.
.25 BTC is about 1000x the typical "double-spend premium" I'm seeing
right now. Wouldn't the greedy-rational miner just decide to include
the earlier spend instead?
|
