path: root/3e/77042d827eeed35899f443a1e00bc7646083d3

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 <mh.in.england@gmail.com>)
	id 1UFLE1-0000WH-1h; Tue, 12 Mar 2013 09:10:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.42 as permitted sender)
	client-ip=209.85.219.42; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f42.google.com; 
Received: from mail-oa0-f42.google.com ([209.85.219.42])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UFLDx-0007q1-1J; Tue, 12 Mar 2013 09:10:25 +0000
Received: by mail-oa0-f42.google.com with SMTP id i18so5576147oag.29
	for <multiple recipients>; Tue, 12 Mar 2013 02:10:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.1.225 with SMTP id 1mr11238381oep.141.1363079415656; Tue,
	12 Mar 2013 02:10:15 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.86.169 with HTTP; Tue, 12 Mar 2013 02:10:15 -0700 (PDT)
In-Reply-To: <CAPg+sBjm+e=A+edSRHXU7JSqyfSc4hou_SRdQHF48xhKQGA4zA@mail.gmail.com>
References: <CAPg+sBip_4Jtxhq+rm-na2=RSJ_PuoZt+akGgJyo0b_Bwbr1Dw@mail.gmail.com>
	<CAPg+sBjm+e=A+edSRHXU7JSqyfSc4hou_SRdQHF48xhKQGA4zA@mail.gmail.com>
Date: Tue, 12 Mar 2013 10:10:15 +0100
X-Google-Sender-Auth: pFxA8Ph6_McVQlWVmlgoreEkJ74
Message-ID: <CANEZrP2V9uDQ-dmyaUBbsCuj5u3Mrh+jvU9RDpYkrKQV6+t0tQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1UFLDx-0007q1-1J
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	bitcoin-security@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Warning: many 0.7 nodes break on large
 number of tx/block; fork risk
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, 12 Mar 2013 09:10:25 -0000

Just so we're all on the same page, can someone confirm my
understanding  - are any of the following statements untrue?

BDB ran out of locks.
However, only on some 0.7 nodes. Others, perhaps nodes using different
flags, managed it.
We have processed 1mb sized blocks on the testnet.
Therefore it isn't presently clear why that particular block caused
lock exhaustion when other larger blocks have not.

The reason for increasing the soft limit is still present (we have run
out of space).
Therefore transactions are likely to start stacking up in the memory
pool again very shortly, as they did last week.
There are no bounds on the memory pool size. If too many transactions
enter the pool then nodes will start to die with OOM failures.
Therefore it is possible that we have a very limited amount of time
until nodes start dying en-masse.
Even if nodes do not die, users have no way to find out what the
current highest fees/bids for block space are, nor any way to change
the fee on sent transactions.
Therefore Bitcoin will shortly start to break for the majority of
users who don't have a deep understanding of the system.


If all the above statements are true, we appear to be painted into a
corner - can't roll forward and can't roll back, with very limited
time to come up with a solution. I see only a small number of
alternatives:

1) Start aggressively trying to block or down-prioritize SatoshiDice
transactions at the network level, to buy time and try to avoid
mempool exhaustion. I don't know a good way to do this, although it
appears that virtually all their traffic is actually coming via
blockchain.infos My Wallet service. During their last outage block
sizes seemed to drop to around 50kb. Alternatively, ask SD to
temporarily suspend their service (this seems like a long shot).

2) Perform a crash hard fork as soon as possible, probably with no
changes in it except a new block size limit. Question - try to lift
the 1mb limit at the same time, or not?




On Tue, Mar 12, 2013 at 2:01 AM, Pieter Wuille <pieter.wuille@gmail.com> wr=
ote:
> Hello again,
>
> block 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023
> (height=3D225430) seems indeed to have cause pre-0.8 and 0.8 nodes to for=
k (at
> least mostly). Both chains are being mined on - the 0.8 one growing faste=
r.
>
> After some emergency discussion on #bitcoin-dev, it seems best to try to =
get
> the majority mining power back on the "old" chain, that is, the one which
> 0.7 accepts (with
> 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at heigh=
t
> 225430). That is the only chain every client out there will accept. BTC
> Guild is switching to 0.7, so majority should abandon the 0.8 chain soon.
>
> Short advice: if you're a miner, please revert to 0.7 until we at least
> understand exactly what causes this. If you're a merchant, and are on 0.8=
,
> stop processing transactions until both sides have switched to the same
> chain again. We'll see how to proceed afterwards.
>
> --
> Pieter
>
>
>
> On Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>>
>> Hello everyone,
>>
>> =C3=8D've just seen many reports of 0.7 nodes getting stuck around block
>> 225430, due to running out of lock entries in the BDB database. 0.8 node=
s do
>> not seem to have a problem.
>>
>> In any case, if you do not have this block:
>>
>>   2013-03-12 00:00:10 SetBestChain: new
>> best=3D000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c
>> height=3D225439  work=3D853779625563004076992  tx=3D14269257  date=3D201=
3-03-11
>> 23:49:08
>>
>> you're likely stuck. Check debug.log and db.log (look for 'Lock table is
>> out of available lock entries').
>>
>> If this is a widespread problem, it is an emergency. We risk having
>> (several) forked chains with smaller blocks, which are accepted by 0.7
>> nodes. Can people contact pool operators to see which fork they are on?
>> Blockexplorer and blockchain.info seem to be stuck as well.
>>
>> Immediate solution is upgrading to 0.8, or manually setting the number o=
f
>> lock objects higher in your database. I'll follow up with more concrete
>> instructions.
>>
>> If you're unsure, please stop processing transactions.
>>
>> --
>> Pieter
>
>
>
> -------------------------------------------------------------------------=
-----
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>