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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SNT0a-0004Z5-9l
for bitcoin-development@lists.sourceforge.net;
Thu, 26 Apr 2012 18:01:37 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f47.google.com;
Received: from mail-qa0-f47.google.com ([209.85.216.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SNT0W-0000cs-IQ
for bitcoin-development@lists.sourceforge.net;
Thu, 26 Apr 2012 18:01:36 +0000
Received: by qabg1 with SMTP id g1so4761726qab.13
for <bitcoin-development@lists.sourceforge.net>;
Thu, 26 Apr 2012 11:01:27 -0700 (PDT)
Received: by 10.224.202.66 with SMTP id fd2mr6313994qab.9.1335463287159;
Thu, 26 Apr 2012 11:01:27 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id i8sm6234118qah.4.2012.04.26.11.01.25
(version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 11:01:26 -0700 (PDT)
Message-ID: <4F998D5B.9070708@gmail.com>
Date: Thu, 26 Apr 2012 14:00:59 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20120426154928.GA13737@savin.lan> <CAMGNxUs3eDaYHpg=ZqXQPC5+kQXZwhqUngH2t2OFaTa4x7vPcw@mail.gmail.com>
<20120426173000.GB16099@savin.lan>
In-Reply-To: <20120426173000.GB16099@savin.lan>
Content-Type: multipart/alternative;
boundary="------------090209030207020504050406"
X-Spam-Score: -0.5 (/)
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
(etotheipi[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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SNT0W-0000cs-IQ
Subject: Re: [Bitcoin-development] Trusted identities
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: Thu, 26 Apr 2012 18:01:37 -0000
This is a multi-part message in MIME format.
--------------090209030207020504050406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 04/26/2012 01:30 PM, Peter Todd wrote:
>
>> More difficulty shortens the safe time we can transact large volumes in,
>> which is good for the network.
>>
>> I'm not sure of the current implementation of replacement transactions, can
>> anyone on the core team speak to this? Can I replace transactions, or is
>> that part of the spec unimplemented or deprecated right now?
> My understanding is it's completely disabled.
Went on a scavenger hunt with Gavin a couple weeks concerning tx
replacement. The conclusion was that if,
(1) Transaction has lock-time in the future AND
(2) Transaction has non-maximum sequence number
Then the transaction will both propagate and be accepted into nodes'
memory pools, but will not go into any block until locktime expires. If
the lock-time is in the past OR sequence number on all TxIns is
0xffffffff, then it will be immediately valid and included in the
blockchain.
But the actual "replacement" mechanism is disabled. Therefore, the
nodes accept the tx as if it's replaceable, but don't allow it to be
replaced. This means that it is effectively replaceable *once*, but
only if you inject a final transaction into the blockchain. You can't
broadcast a final version of the same tx, because it will conflict with
the non-final one sitting in all the other nodes' memory pools. You
need a miner to agree to remove the non-final tx from their memory pool
and specifically include your replacement.
-Alan
--------------090209030207020504050406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 04/26/2012 01:30 PM, Peter Todd wrote:
<blockquote cite="mid:20120426173000.GB16099@savin.lan" type="cite"><br>
<blockquote type="cite">
<pre wrap="">More difficulty shortens the safe time we can transact large volumes in,
which is good for the network.
I'm not sure of the current implementation of replacement transactions, can
anyone on the core team speak to this? Can I replace transactions, or is
that part of the spec unimplemented or deprecated right now?
</pre>
</blockquote>
<pre wrap="">
My understanding is it's completely disabled.
</pre>
</blockquote>
<br>
Went on a scavenger hunt with Gavin a couple weeks concerning tx
replacement. The conclusion was that if,<br>
(1) Transaction has lock-time in the future AND<br>
(2) Transaction has non-maximum sequence number<br>
<br>
Then the transaction will both propagate and be accepted into nodes'
memory pools, but will not go into any block until locktime
expires. If the lock-time is in the past OR sequence number on all
TxIns is 0xffffffff, then it will be immediately valid and included
in the blockchain.<br>
<br>
But the actual "replacement" mechanism is disabled. Therefore, the
nodes accept the tx as if it's replaceable, but don't allow it to be
replaced. This means that it is effectively replaceable <b>once</b>,
but only if you inject a final transaction into the blockchain.
You can't broadcast a final version of the same tx, because it will
conflict with the non-final one sitting in all the other nodes'
memory pools. You need a miner to agree to remove the non-final tx
from their memory pool and specifically include your replacement.<br>
<br>
-Alan<br>
<br>
<br>
</body>
</html>
--------------090209030207020504050406--
|
