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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SIPYY-00039i-Sn
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 19:19:47 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=etotheipi@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SIPYX-0005X6-M0
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 19:19:46 +0000
Received: by wibhn6 with SMTP id hn6so5246045wib.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Apr 2012 12:19:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.91.10 with SMTP id ca10mr18406695wib.17.1334258379576;
Thu, 12 Apr 2012 12:19:39 -0700 (PDT)
Received: by 10.180.8.7 with HTTP; Thu, 12 Apr 2012 12:19:39 -0700 (PDT)
In-Reply-To: <CA+8xBpc5CZ9Sx4MwPdeS0-5frnV9B+mJ5OwcPoUVrygTawiJBg@mail.gmail.com>
References: <CA+8xBpc5CZ9Sx4MwPdeS0-5frnV9B+mJ5OwcPoUVrygTawiJBg@mail.gmail.com>
Date: Thu, 12 Apr 2012 15:19:39 -0400
Message-ID: <CALf2ePzvwW6VU0YA+6WNCBHzK2rGc5p1uXGvbYG2uS__S-bjoQ@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=f46d043c093ec0d3d504bd803ce4
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
(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
X-Headers-End: 1SIPYX-0005X6-M0
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic
behavior
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, 12 Apr 2012 19:19:47 -0000
--f46d043c093ec0d3d504bd803ce4
Content-Type: text/plain; charset=ISO-8859-1
My one big concern about this that users find a way to exploit this
behavior for themselves. If it's too easy for users to create tx they know
will get stuck and expire, it's no different than letting them cancel their
zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so
I send it using a combination of inputs and fees that I know will lead to
it being stuck and expire.
On the other hand, if such conditions are deterministic enough, it could be
detected by the recipient and flagged.
It's not a huge deal, but it's something to consider.
-Alan
On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik <jgarzik@exmulti.com> wrote:
> Not sure whether this rises to the level of a BIP or not, as it is
> largely an implementation change.
>
> One of my From-Day-One complaints about bitcoin is that transactions
> behavior could be far more deterministic (predictable), from a user
> standpoint. Transactions in the current system can easily remain in
> limbo forever.
>
> One big step in making transactions behave more predictably would be
> to remove transactions from the memory pool, if they have not made it
> into a block for a couple days. i.e.
>
> 1. N = 1 or 2 or whatever the community prefers. Ideally enough time
> for a third-tier miner, mining strange TXs, finds a block.
> 2. H1 = height of block chain, when a TX is received
> 3. H2 = H1 + (144 * N)
> 4. If block chain height reaches H2, and TX has not made it into a
> block, drop TX from memory pool
>
> Although this only impacts a small amount of TX's ultimately, what it
> does do is give us the ability -- once miners have upgraded to this
> rule -- to tell bitcoin users that their transactions "expire" after N
> days.
>
> Backwards compatibility should not be an issue; clients are free to
> retransmit their TX at any time, as usual, thereby "resetting the
> clock" for all peers who have forgotten the TX in question.
>
> Once in place, clients may then implement code that notices a TX has
> expired (read: likely to have been forgotten by the network, assuming
> they themselves have stopped retransmitting it). Then you can start
> working on wallet/coin recovery, perhaps resending with a higher fee
> etc.
>
> The above change is not really "fill-or-kill" but it should be a big
> step, opening the door to deterministic TX behavior.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d043c093ec0d3d504bd803ce4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
My one big concern about this that users find a way to exploit this behavio=
r for themselves. =A0<meta http-equiv=3D"content-type" content=3D"text/html=
; charset=3Dutf-8">If it's too easy for users to create tx they know wi=
ll get stuck and expire, it's no different than letting them cancel the=
ir zero-conf transactions. =A0i.e. I pay 0.5 BTC in a store for a candy bar=
, so I send it using a combination of inputs and fees that I know will lead=
to it being stuck and expire. =A0<div>
<br></div><div>On the other hand, if such conditions are deterministic enou=
gh, it could be detected by the recipient and flagged.<div><br></div><div>I=
t's not a huge deal, but it's something to consider. =A0</div><div>
<br></div><div>-Alan</div><div><br><div><br><br><div class=3D"gmail_quote">=
On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik <span dir=3D"ltr"><<a href=
=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
Not sure whether this rises to the level of a BIP or not, as it is<br>
largely an implementation change.<br>
<br>
One of my From-Day-One complaints about bitcoin is that transactions<br>
behavior could be far more deterministic (predictable), from a user<br>
standpoint. =A0Transactions in the current system can easily remain in<br>
limbo forever.<br>
<br>
One big step in making transactions behave more predictably would be<br>
to remove transactions from the memory pool, if they have not made it<br>
into a block for a couple days. =A0i.e.<br>
<br>
1. =A0N =3D 1 or 2 or whatever the community prefers. =A0Ideally enough tim=
e<br>
for a third-tier miner, mining strange TXs, finds a block.<br>
2. =A0H1 =3D height of block chain, when a TX is received<br>
3. =A0H2 =3D H1 + (144 * N)<br>
4. =A0If block chain height reaches H2, and TX has not made it into a<br>
block, drop TX from memory pool<br>
<br>
Although this only impacts a small amount of TX's ultimately, what it<b=
r>
does do is give us the ability -- once miners have upgraded to this<br>
rule -- to tell bitcoin users that their transactions "expire" af=
ter N<br>
days.<br>
<br>
Backwards compatibility should not be an issue; clients are free to<br>
retransmit their TX at any time, as usual, thereby "resetting the<br>
clock" for all peers who have forgotten the TX in question.<br>
<br>
Once in place, clients may then implement code that notices a TX has<br>
expired (read: likely to have been forgotten by the network, assuming<br>
they themselves have stopped retransmitting it). =A0Then you can start<br>
working on wallet/coin recovery, perhaps resending with a higher fee<br>
etc.<br>
<br>
The above change is not really "fill-or-kill" but it should be a =
big<br>
step, opening the door to deterministic TX behavior.<br>
<br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
For Developers, A Lot Can Happen In A Second.<br>
Boundary is the first to Know...and Tell You.<br>
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!<br>
<a href=3D"http://p.sf.net/sfu/Boundary-d2dvs2" target=3D"_blank">http://p.=
sf.net/sfu/Boundary-d2dvs2</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div></div>
--f46d043c093ec0d3d504bd803ce4--
|
