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
|
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 <dennis.jm.sullivan@gmail.com>) id 1YYMbk-0004qr-NP
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Mar 2015 22:38:36 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.195 as permitted sender)
client-ip=209.85.214.195;
envelope-from=dennis.jm.sullivan@gmail.com;
helo=mail-ob0-f195.google.com;
Received: from mail-ob0-f195.google.com ([209.85.214.195])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YYMbj-0005LO-HQ
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Mar 2015 22:38:36 +0000
Received: by obcwp18 with SMTP id wp18so2399780obc.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 18 Mar 2015 15:38:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.242.106 with SMTP id wp10mr5771797obc.14.1426718310128;
Wed, 18 Mar 2015 15:38:30 -0700 (PDT)
Received: by 10.202.62.4 with HTTP; Wed, 18 Mar 2015 15:38:30 -0700 (PDT)
Date: Wed, 18 Mar 2015 22:38:30 +0000
Message-ID: <CANMKXkMSDQHWFOR+SzZW15axjXtZVD9-tsO4+e+XDYQDNBuX5w@mail.gmail.com>
From: Dennis Sullivan <dennis.jm.sullivan@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=e89a8ff2521a11e352051197be14
X-Spam-Score: -0.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
(dennis.jm.sullivan[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
X-Headers-End: 1YYMbj-0005LO-HQ
Subject: [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:38:36 -0000
--e89a8ff2521a11e352051197be14
Content-Type: text/plain; charset=UTF-8
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.
The scheme operates as follows:
As implemented into Darkcoin, an InstantX transaction is broadcast spending
certain outputs. Certain nodes determined deterministically will sign a
message which is relayed across the network locking this tx in mempool such
it's inputs cannot be double spent. All nodes are instructed to reject any
conflicting transactions and flush out any existing txs in the mempool that
conflict with this "locked" tx. From this point onwards, the network will
refuse to relay double spends and will also reject blocks that contain a
conflicting tx thus forcing miners to play ball.
The idea is once a transaction receives a "consensus lock" across nodes in
the mempool, the tx will eventually get mined as there is no way it can be
double spent and no way a miner can mine a double spend of the consensus
locked transaction. At the very least, this seems like it could be turned
in on itself to fork the network because of the ability to cause blocks to
be rejected. I am sure there is an attack vector there somewhere.
A full explanation is published in this paper:
https://www.darkcoin.io/wp-content/uploads/2014/09/InstantTX.pdf
Dennis
--e89a8ff2521a11e352051197be14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello. This is my first time posting to this list. I =
wanted to ask your opinions on something relating to confirmation times.</d=
iv><div><br></div>I recently read about a "transaction locking" p=
roposal 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 discus=
sion on this list regarding it.<div><br>The scheme operates as follows:</di=
v><div><br></div><div>As implemented into Darkcoin, an InstantX transaction=
is broadcast spending certain outputs. Certain nodes determined determinis=
tically will=C2=A0sign a message which is relayed across the network lockin=
g this tx in mempool such it's inputs cannot be double spent. All nodes=
are instructed to reject any conflicting transactions and flush out any ex=
isting txs in the mempool that conflict with this "locked" tx. Fr=
om this point onwards, the network will refuse to relay double spends and w=
ill also reject blocks that contain a conflicting tx thus forcing miners to=
play ball.</div><div><br></div><div>The idea is once a transaction receive=
s a "consensus lock" across nodes in the mempool, the tx will eve=
ntually get mined as there is no way it can be double spent and no way a mi=
ner can mine a double spend of the consensus locked transaction. At the ver=
y least, this seems like it could be turned in on itself to fork the networ=
k because of the ability to cause blocks to be rejected. I am sure there is=
an attack vector there somewhere.</div><div><br></div><div>A full explanat=
ion is published in this paper:=C2=A0<a href=3D"https://www.darkcoin.io/wp-=
content/uploads/2014/09/InstantTX.pdf">https://www.darkcoin.io/wp-content/u=
ploads/2014/09/InstantTX.pdf</a></div><div><br></div><div>Dennis</div><div>=
<br></div></div>
--e89a8ff2521a11e352051197be14--
|
