Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1VA8PF-0001SH-NR
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Aug 2013 01:00:45 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.171 as permitted sender)
	client-ip=74.125.82.171; envelope-from=gavinandresen@gmail.com;
	helo=mail-we0-f171.google.com; 
Received: from mail-we0-f171.google.com ([74.125.82.171])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VA8PE-0004p7-OH
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Aug 2013 01:00:45 +0000
Received: by mail-we0-f171.google.com with SMTP id q55so1130875wes.16
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 15 Aug 2013 18:00:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.109.35 with SMTP id hp3mr3435584wib.52.1376614838580;
	Thu, 15 Aug 2013 18:00:38 -0700 (PDT)
Received: by 10.194.156.163 with HTTP; Thu, 15 Aug 2013 18:00:38 -0700 (PDT)
Date: Fri, 16 Aug 2013 11:00:38 +1000
Message-ID: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=e89a8f3ba25b723afa04e4061e28
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
	(gavinandresen[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: 1VA8PE-0004p7-OH
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Gavin's post-0.9 TODO list...
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: Fri, 16 Aug 2013 01:00:45 -0000

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

Mike asked what non-0.9 code I'm working on; the three things on the top of
my list are:

1) Smarter fee handling on the client side, instead of hard-coded fees. I
was busy today generating scatter-plots and histograms of transaction fees
versus priorities to get some insight into what miner policies look like
right now.

2) "First double-spend" relaying and alerting, to better support low-value
in-person transactions.  Related:
*Have *a *Snack*, Pay with
*Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>


3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
block size limit, how we can do it safely, and go through all of the
arguments that have been made against it and explain why they're wrong.

-- 
--
Gavin Andresen

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

<div dir=3D"ltr">Mike asked what non-0.9 code I&#39;m working on; the three=
 things on the top of my list are:<div><br></div><div>1) Smarter fee handli=
ng on the client side, instead of hard-coded fees. I was busy today generat=
ing scatter-plots and histograms of transaction fees versus priorities to g=
et some insight into what miner policies look like right now.</div>
<div><br></div><div>2) &quot;First double-spend&quot; relaying and alerting=
, to better support low-value in-person transactions. =A0Related:=A0</div><=
h3 class=3D"" style=3D"margin:0px;padding:0px;border:0px;font-weight:normal=
;font-size:16px;font-family:Arial,sans-serif">
<a href=3D"http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/=
P2P2013_093.pdf" style=3D"color:rgb(102,17,204);outline:none"><b style=3D"c=
olor:rgb(102,17,204);outline:none">Have=A0</b><font color=3D"#6611cc">a=A0<=
/font><b style=3D"color:rgb(102,17,204);outline:none">Snack</b><font color=
=3D"#6611cc">, Pay with=A0</font><b style=3D"color:rgb(102,17,204);outline:=
none">Bitcoins</b></a>=A0</h3>
<div><br></div><div>3) Work on 2-3 whitepapers on why we need to increase o=
r remove the 1MB block size limit, how we can do it safely, and go through =
all of the arguments that have been made against it and explain why they&#3=
9;re wrong.<div class=3D"gmail_extra">
<div><br></div>-- <br>--<br>Gavin Andresen<br>
</div></div><div class=3D"gmail_extra"><br></div></div>

--e89a8f3ba25b723afa04e4061e28--