Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=gavinandresen@gmail.com;
	helo=mail-ww0-f53.google.com; 
MIME-Version: 1.0
Date: Wed, 15 Feb 2012 14:20:10 -0500
Message-ID: <CABsx9T1bgQCT64ywo9t6ti6b2S1yZ9AAkXNRQdHFUpZ+m-UHrw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Bitcoin-development] 14 Feb IRC meeting summary
Precedence: list

Full conversation starts here:
  http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/02/14/5#l2892558

Summary of what was discussed/decided; please correct anything I get wrong:

1. BIP 16 support is at about 34% of hashing power, so we'll continue
to ask big pools and miners to upgrade and will re-evaluate support on
March 1'st, with a potential switchover date if there is enough
support of March 15'th.

2. On February 20'th the protocol changes to include checksums on the
initial version messages. version includes an 'addrFrom' field with
your IP address, and there are (unconfirmed) reports of NAT routers
changing the contents of packets to modify the inside-the-NAT IP
address to the outside-the-NAT address. If you've got a router that
does that, then the version message checksum will be wrong and you'll
be unable to connect.

Two things are being done to address this:

+ A patch that puts the outside-the-NAT IP address in addrFrom. That's
a good idea in any case, exposing interior IP addresses was a mistake.
There will be either a 0.5.3 or 0.5.2.1 release available for anybody
affected.

+ An alert will be sent next Friday on the main network directing
people to a to-be-created bitcoin.org/feb20 web page explaining the
issue.

3. The third issue was how to deal with potential chain-splitting
attacks involving duplicate coinbase transactions. The general
consensus is that in the long-term requiring that the first four bytes
of every coinbase be the block height is the best solution, but
looking for and 'discouraging' just blocks that have duplicate
coinbases is a reasonable short-term solution.

There's still some research and thinking to be done on this issue (see
the IRC discussion for details), but I expect that the final version
of bitcoin-qt/bitcoind version 0.6 will be putting the block height
into coinbases that it creates.


-- 
--
Gavin Andresen