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
|
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 <thomas@thomaszander.se>) id 1Xj0Cg-0005R7-J0
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Oct 2014 06:24:26 +0000
X-ACL-Warn:
Received: from lamora.getmail.no ([84.210.184.7])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Xj0Ce-0003VR-QL for bitcoin-development@lists.sourceforge.net;
Tue, 28 Oct 2014 06:24:26 +0000
Received: from localhost (localhost [127.0.0.1])
by lamora.getmail.no (Postfix) with ESMTP id 78C73A7343
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Oct 2014 07:24:18 +0100 (CET)
Received: from lamora.getmail.no ([127.0.0.1])
by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new,
port 10032) with ESMTP id cSDmH6HlZmHh
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Oct 2014 07:24:08 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by lamora.getmail.no (Postfix) with ESMTP id 95E2FA81D6
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Oct 2014 07:24:08 +0100 (CET)
X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net
Received: from lamora.getmail.no ([127.0.0.1])
by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new,
port 10026) with ESMTP id zdmwDRVN-qwr
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Oct 2014 07:24:08 +0100 (CET)
Received: from coldstorage.localnet (cm-84.208.97.23.getinternet.no
[84.208.97.23])
by lamora.getmail.no (Postfix) with ESMTP id 70B78A8013
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Oct 2014 07:24:08 +0100 (CET)
From: Thomas Zander <thomas@thomaszander.se>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 28 Oct 2014 07:24:07 +0100
Message-ID: <1835049.8OJNQBmq5F@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16-3-amd64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <544EFEE8.4000000@thinlink.com>
References: <544EA3D7.2050901@thinlink.com> <544EA85E.8010400@bluematt.me>
<544EFEE8.4000000@thinlink.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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: 1Xj0Ce-0003VR-QL
Subject: Re: [Bitcoin-development] DS Deprecation Window
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, 28 Oct 2014 06:24:26 -0000
On Monday 27. October 2014 19.26.48 Tom Harding wrote:
> Miner has to be very careful including a double-spend in his block -- he
> hopes:
How does it help the zero-confirmation to not include a payment? Doesn't that
just mean that if I send a double spend that neither of the payments will be
made? So the thief just got an even bigger incentive to double-spent!
> - that based on his measured time offset from the first spend he
> received, at most a tiny fraction of the network will delay his block
>
> - that not too many nodes saw an earlier spend that he didn't see,
> which could increase that fraction
>
> - that most other nodes saw his tx. Any who didn't will only learn
> about it by receiving his block, and they will assign it the time when
> they receive the block. That's likely to be more than T (30 seconds)
> after an earlier spend, so they would delay the block.
This doesn't addresses the point that Matt brought up.
Your proposal essentially has some side effects that would be disastrous to
miners. As detailed by the other two replies on this thread.
|
