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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1RxkOr-0006xF-LJ
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Feb 2012 19:20:21 +0000
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;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RxkOn-0004R9-0j
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Feb 2012 19:20:21 +0000
Received: by wgbdr12 with SMTP id dr12so1252666wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 Feb 2012 11:20:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.96.8 with SMTP id do8mr10206028wib.21.1329333610879; Wed,
15 Feb 2012 11:20:10 -0800 (PST)
Received: by 10.223.112.199 with HTTP; Wed, 15 Feb 2012 11:20:10 -0800 (PST)
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
X-Spam-Score: -1.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
-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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RxkOn-0004R9-0j
Subject: [Bitcoin-development] 14 Feb IRC meeting summary
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: Wed, 15 Feb 2012 19:20:21 -0000
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
|
