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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YYMqJ-0005Lm-O9
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Mar 2015 22:53:39 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.43 as permitted sender)
client-ip=74.125.82.43; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f43.google.com;
Received: from mail-wg0-f43.google.com ([74.125.82.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YYMqI-0005mk-RY
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Mar 2015 22:53:39 +0000
Received: by wgbcc7 with SMTP id cc7so47546402wgb.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 18 Mar 2015 15:53:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.181.27.201 with SMTP id ji9mr10961603wid.20.1426719212819;
Wed, 18 Mar 2015 15:53:32 -0700 (PDT)
Received: by 10.28.218.8 with HTTP; Wed, 18 Mar 2015 15:53:32 -0700 (PDT)
Received: by 10.28.218.8 with HTTP; Wed, 18 Mar 2015 15:53:32 -0700 (PDT)
In-Reply-To: <CANMKXkMSDQHWFOR+SzZW15axjXtZVD9-tsO4+e+XDYQDNBuX5w@mail.gmail.com>
References: <CANMKXkMSDQHWFOR+SzZW15axjXtZVD9-tsO4+e+XDYQDNBuX5w@mail.gmail.com>
Date: Wed, 18 Mar 2015 23:53:32 +0100
Message-ID: <CAAt2M19w3Zm-Ph=c5PxFAYTrLN9noZq1aqCZVXYH0YzA2u6nxw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Dennis Sullivan <dennis.jm.sullivan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3476adfdac6051197f3a6
X-Spam-Score: 0.4 (/)
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
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Headers-End: 1YYMqI-0005mk-RY
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Are Instant Confirmations safe?
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: Wed, 18 Mar 2015 22:53:39 -0000
--001a11c3476adfdac6051197f3a6
Content-Type: text/plain; charset=UTF-8
Den 18 mar 2015 23:38 skrev "Dennis Sullivan" <dennis.jm.sullivan@gmail.com
>:
>
> Hello. This is my first time posting to this list. I wanted to ask your
opinions on something relating to confirmation times.
>
> I recently read about a "transaction locking" proposal which claims to
make it possible to accept 0-conf transactions with guarantee they will get
mined. This seems rather dubious to me, because if there was merit to the
system, I would have already expected to see discussion on this list
regarding it.
Sounds like it would be weak to sybil attacks (deterministically choosing
my own nodes sounds great!), and of course Finney attacks (single-block
reversal) and defecting miners (what are you gonna do, punish miners with
limited network connectivity as well? You'll risk forking the network).
Zero-conf is only safe if nobody's actively trying to attack you. It has no
inherent security in and of itself. For low values the risk is usually
tolerated. For large values there's too much risk of making yourself a
target.
--001a11c3476adfdac6051197f3a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 18 mar 2015 23:38 skrev "Dennis Sullivan" <<a href=3D"mail=
to:dennis.jm.sullivan@gmail.com">dennis.jm.sullivan@gmail.com</a>>:<br>
><br>
> Hello. This is my first time posting to this list. I wanted to ask you=
r opinions on something relating to confirmation times.<br>
><br>
> I recently read about a "transaction locking" proposal which=
claims to make it possible to accept 0-conf transactions with guarantee th=
ey will get mined. This seems rather dubious to me, because if there was me=
rit to the system, I would have already expected to see discussion on this =
list regarding it.</p>
<p dir=3D"ltr">Sounds like it would be weak to sybil attacks (deterministic=
ally choosing my own nodes sounds great!), and of course Finney attacks (si=
ngle-block reversal) and defecting miners (what are you gonna do, punish mi=
ners with limited network connectivity as well? You'll risk forking the=
network). </p>
<p dir=3D"ltr">Zero-conf is only safe if nobody's actively trying to at=
tack you. It has no inherent security in and of itself. For low values the =
risk is usually tolerated. For large values there's too much risk of ma=
king yourself a target. </p>
--001a11c3476adfdac6051197f3a6--
|
