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
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <flavien.charlon@pixodegames.com>) id 1XEiYd-0005tQ-Fo
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Aug 2014 17:29:55 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of
pixodegames.com designates 209.85.217.181 as permitted sender)
client-ip=209.85.217.181;
envelope-from=flavien.charlon@pixodegames.com;
helo=mail-lb0-f181.google.com;
Received: from mail-lb0-f181.google.com ([209.85.217.181])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XEiYb-0003qT-TA
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Aug 2014 17:29:55 +0000
Received: by mail-lb0-f181.google.com with SMTP id 10so970615lbg.26
for <bitcoin-development@lists.sourceforge.net>;
Tue, 05 Aug 2014 10:29:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=pRPZ9hVbSvECAY227OCtdrL98hCsRbduz1R7mteWkbI=;
b=A/MTNaWPTMX7zYC+vfHzVliUW2H5Jgwu7A4UjAqi8B3iD2DbX9rfoHnAvaqRjbyW3E
Zr+xsC/0yjNHEv7sf+ftThUZGjL0bnQtZxq/OoAEefkeipicpXhvzwf2BRibjesEZ2Uy
TIi10TevCUgTt54WbJnIhjRLWdTbUXnEESwaFhECDRwGUrBdjFVKwOaxe41Url8ZCbPx
kvGq0i8sxcQIXEQcBZEhWPXypAztRKvLXCsrVZDEKGmX6b/h3j59UCKJQnYuE+7cafLq
gT3opEX1tRXBMxht7me13LbBHjSx1Z0vfbYzVzn3bATTQ54kVsM7sKKmb3Y0pnEa/uwb
k3qQ==
X-Gm-Message-State: ALoCoQnfO80jFre6lD0cFb5l1w3hPsc2UQinE9IvLeL67Ar9fK0AE1S9RxkWeKV+h1sOpXl4a42M
X-Received: by 10.112.129.9 with SMTP id ns9mr5236894lbb.23.1407258199029;
Tue, 05 Aug 2014 10:03:19 -0700 (PDT)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com
[209.85.215.42])
by mx.google.com with ESMTPSA id c7sm1181770laf.2.2014.08.05.10.03.18
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 05 Aug 2014 10:03:18 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id pv20so984349lab.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 05 Aug 2014 10:03:18 -0700 (PDT)
X-Received: by 10.152.87.82 with SMTP id v18mr5566752laz.17.1407258198490;
Tue, 05 Aug 2014 10:03:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.67.10 with HTTP; Tue, 5 Aug 2014 10:02:38 -0700 (PDT)
X-Originating-IP: [2a01:110:8:1003:494e:7ce7:f38e:659a]
In-Reply-To: <53DC329E.7090206@thinlink.com>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
<53DC329E.7090206@thinlink.com>
From: Flavien Charlon <flavien.charlon@coinprism.com>
Date: Tue, 5 Aug 2014 18:02:38 +0100
Message-ID: <CABbpET_=Xz2=mx-hwFOwQ0K=t=Rq=P6gyiDHCAYoaJzo1zJd0g@mail.gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=001a11c2ae8c0752fd04ffe4d506
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1XEiYb-0003qT-TA
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
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, 05 Aug 2014 17:29:55 -0000
--001a11c2ae8c0752fd04ffe4d506
Content-Type: text/plain; charset=UTF-8
> It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
arbitrary logic about which blocks the transaction can be valid in. This
would require that the client revalidate all transactions in its mempool
(really, only those making use of this opcode) whenever the chain tip
changes.
I have to say I like this idea, this would allow someone to prove they
can't spend funds before a given date, and vice versa, prove that the funds
can't ever be spent after a given date (and this is provably prunable,
isn't it?). Of course, there are some risks associated with that, but
nobody is forced to use it.
> flooding the network with unrelated high fee transactions
> in order to push a transaction out to where it can never be mined at
> all.
This becomes increasingly expensive as the deadline is further away, so not
very hard to mitigate.
On Sat, Aug 2, 2014 at 1:36 AM, Tom Harding <tomh@thinlink.com> wrote:
> On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> > 1. start setting nLockTime to the current height by default in newly
> > created transactions (or slightly below the current height, for
> > reorg-friendliness)
>
> Reorg-frendliness is the opposite of the rationale behind #2340, which
> proposes setting nLockTime at current-height + 1 to prevent
> "fee-sniping" reorgs...
>
>
> > 2. once users have had some time to upgrade to clients that set
> > nLockTime, start discouraging transactions without nLockTime --
> > possibly with a slightly higher fee required for relay
> > 3. start rate-limiting relay of transactions without an nLockTime
> > (maybe this alone could be used to achieve [2])
> > 4. add a new IsStandard rule rejecting transactions with an nLockTime
> > more than N blocks behind the current tip (for some fixed value N, to
> > be determined)
> >
>
> One way to proceed is implement #3753 (mempool janitor) in such a way
> that transactions with nLockTime are allowed to live a bit longer in the
> mempool (say 500 blocks) than those without (72 hours). In other words,
> as a first step, just actually start expiring things from the mempool in
> bitcoin core, and leave any relay fee adjustments or rate limiting for
> later. The isStandard change would be a good complement to #3753, to
> avoid relaying a tx that will soon expire by the nLockTime rule anyway.
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c2ae8c0752fd04ffe4d506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> It would make more sense to introduce a new scri=
pt opcode that pushes the current block height onto the operand stack. Then=
you could implement arbitrary logic about which blocks the transaction can=
be valid in. This would require that the client revalidate all transaction=
s in its mempool (really, only those making use of this opcode) whenever th=
e chain tip changes.</div>
<div><br></div><div>I have to say I like this idea, this would allow someon=
e to prove they can't spend funds before a given date, and vice versa, =
prove that the funds can't ever be spent after a given date=C2=A0(and t=
his is provably prunable, isn't it?). Of course, there are some risks a=
ssociated with that, but nobody is forced to use it.</div>
<div><br></div><div>> flooding the network with unrelated high fee trans=
actions<br>> in order to push a transaction out to where it can never be=
mined at<br> > all.</div><div><br></div><div>This becomes increasingly =
expensive as the deadline is further away, so not very hard to mitigate.</d=
iv>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
Aug 2, 2014 at 1:36 AM, Tom Harding <span dir=3D"ltr"><<a href=3D"mailt=
o:tomh@thinlink.com" target=3D"_blank">tomh@thinlink.com</a>></span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 7/31/2014 5:58 PM, Kaz Wesley wrote:=
<br>
> 1. start setting nLockTime to the current height by default in newly<b=
r>
> created transactions (or slightly below the current height, for<br>
> reorg-friendliness)<br>
<br>
</div>Reorg-frendliness is the opposite of the rationale behind #2340, whic=
h<br>
proposes setting nLockTime at current-height + 1 to prevent<br>
"fee-sniping" reorgs...<br>
<div><br>
<br>
> 2. once users have had some time to upgrade to clients that set<br>
> nLockTime, start discouraging transactions without nLockTime --<br>
> possibly with a slightly higher fee required for relay<br>
> 3. start rate-limiting relay of transactions without an nLockTime<br>
> (maybe this alone could be used to achieve [2])<br>
> 4. add a new IsStandard rule rejecting transactions with an nLockTime<=
br>
> more than N blocks behind the current tip (for some fixed value N, to<=
br>
> be determined)<br>
><br>
<br>
</div>One way to proceed is implement #3753 (mempool janitor) in such a way=
<br>
that transactions with nLockTime are allowed to live a bit longer in the<br=
>
mempool (say 500 blocks) than those without (72 hours). =C2=A0In other word=
s,<br>
as a first step, just actually start expiring things from the mempool in<br=
>
bitcoin core, and leave any relay fee adjustments or rate limiting for<br>
later. =C2=A0The isStandard change would be a good complement to #3753, to<=
br>
avoid relaying a tx that will soon expire by the nLockTime rule anyway.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Want fast and easy access to all the code in your enterprise? Index and<br>
search up to 200,000 lines of code with a free copy of Black Duck<br>
Code Sight - the same software that powers the world's largest code<br>
search on Ohloh, the Black Duck Open Hub! Try it now.<br>
<a href=3D"http://p.sf.net/sfu/bds" target=3D"_blank">http://p.sf.net/sfu/b=
ds</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>
</div></div></blockquote></div><br></div>
--001a11c2ae8c0752fd04ffe4d506--
|
