From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Tue, 12 Mar 2013 10:10:15 +0100 X-Google-Sender-Auth: pFxA8Ph6_McVQlWVmlgoreEkJ74 Message-ID: From: Mike Hearn To: Pieter Wuille 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-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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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 >