Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.178 as permitted sender)
	client-ip=74.125.82.178; envelope-from=gavinandresen@gmail.com;
	helo=mail-we0-f178.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0T7y8jqhMDUsf-HNw1sJnVuXngMa3x5+O5qgRE6eswew@mail.gmail.com>
References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com>
	<453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com>
	<CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com>
	<CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com>
	<CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com>
	<20130418090444.GA30995@savin>
	<CANEZrP0AYaWnVhrAbMXP0BGhb=CZMg_-PYVzwKbcCoRKC9V2rw@mail.gmail.com>
	<20130418100806.GA13908@savin>
	<CANEZrP0T7y8jqhMDUsf-HNw1sJnVuXngMa3x5+O5qgRE6eswew@mail.gmail.com>
Date: Thu, 18 Apr 2013 09:37:46 -0400
Message-ID: <CABsx9T18vvd1B4hSGU2eMnQTT9N-6Eoq29RAw_NiYdoNwe5uog@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=e89a8f2356f73a209b04daa2b568
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Precedence: list

--e89a8f2356f73a209b04daa2b568
Content-Type: text/plain; charset=ISO-8859-1

> sure it's worth doing, at least immediately. Weakening the non-final ==
>>
> non-standard test to give a window of, say, 3 blocks, would be fine I
>> think.
>>
>
> Sure. I think Gavin wants some kind of wider memory pool limiter policy
> which would encompass such a thing already.
>

Yes.

I don't want to spend any time thinking about memory pool transaction
replacement until after we pay some technical debt:

+ Memory-limited memory pool, with relay policy matching block-creation
policy
+ Child-pays-for-parent fees
+ Auto-computed fees, based on transactions moving from the memory pool
into blocks


-- 
--
Gavin Andresen

--e89a8f2356f73a209b04daa2b568
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=A0<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=
=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex">

<div><span style=3D"color:rgb(34,34,34)">sure it&#39;s worth doing, at leas=
t immediately. Weakening the non-final =3D=3D</span><br></div></blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">


non-standard test to give a window of, say, 3 blocks, would be fine I<br>
think.<br></blockquote><div><br></div></div><div>Sure. I think Gavin wants =
some kind of wider memory pool limiter policy which would encompass such a =
thing already.</div></div></div></div></blockquote><div><br></div><div>
Yes.</div><div><br></div><div>I don&#39;t want to spend any time thinking a=
bout memory pool transaction replacement until after we pay some technical =
debt:</div><div><br></div><div>+ Memory-limited memory pool, with relay pol=
icy matching block-creation policy</div>
<div>+ Child-pays-for-parent fees</div><div>+ Auto-computed fees, based on =
transactions moving from the memory pool into blocks</div></div><br clear=
=3D"all"><div><br></div>-- <br>--<br>Gavin Andresen<br>

--e89a8f2356f73a209b04daa2b568--