From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFOA2-0008WG-KA for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 12:18:30 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.47 as permitted sender) client-ip=209.85.128.47; envelope-from=jtimonmv@gmail.com; helo=mail-qe0-f47.google.com; Received: from mail-qe0-f47.google.com ([209.85.128.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UFO9y-0006fu-U8 for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 12:18:30 +0000 Received: by mail-qe0-f47.google.com with SMTP id q19so2909828qeb.34 for ; Tue, 12 Mar 2013 05:18:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.32.9 with SMTP id a9mr21796107qad.87.1363090701444; Tue, 12 Mar 2013 05:18:21 -0700 (PDT) Received: by 10.49.11.140 with HTTP; Tue, 12 Mar 2013 05:18:21 -0700 (PDT) In-Reply-To: <20130312114426.GA3701@vps7135.xlshosting.net> References: <20130312114426.GA3701@vps7135.xlshosting.net> Date: Tue, 12 Mar 2013 13:18:21 +0100 Message-ID: From: =?ISO-8859-1?B?CUpvcmdlIFRpbfNu?= To: Pieter Wuille Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 (jtimonmv[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 X-Headers-End: 1UFO9y-0006fu-U8 Cc: Bitcoin Dev , Michael Gronager 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 12:18:30 -0000 A related question...some people mentioned yesterday on #bitcoin-dev that 0.5 appeared to be compatible with 0.8. Was that only for the "fatal block" and would have forked 0.8 later too or is it something else? I'm having a hard time understanding this 0.5 thing, if someone can bring some light to it I would appreciate it. Thanks in advance On 3/12/13, Pieter Wuille wrote: > On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote: >> Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented a= nd >> unknown criteria for block rejection, hence the upgrade went wrong. > > We're using "0.7" as a short moniker for all clients, but this was a > limitation that all > BDB-based bitcoins ever had. The bug is simply a limit in the number of l= ock > objects > that was reached. > > It's ironic that 0.8 was supposed to solve all problems we had due to BDB > (except the > wallet...), but now it seems it's still coming back to haunt us. I really > hated telling > miners to go back to 0.7, given all efforts to make 0.8 signficantly more > tolerable... > >> More space in the block is needed indeed, but the real problem you are >> describing is actually not missing space in the block, but proper handli= ng >> of mem-pool transactions. They should be pruned on two criteria: >> >> 1. if they gets to old >24hr >> 2. if the client is running out of space, then the oldest should probabl= y >> be pruned >> >> clients are anyway keeping, and re-relaying, their own transactions and >> hence it would mean only little, and only little for clients. Dropping >> free / old transaction is a much a better behavior than dying... Even a >> scheme where the client dropped all or random mempool txes would be a >> tolerable way of handling things (dropping all is similar to a restart, >> except for no user intervention). > > Right now, mempools are relatively small in memory usage, but with small > block sizes, > it indeed risks going up. In 0.8, conflicting (=3Ddouble spending) > transactions in the > chain cause clearing the mempool of conflicts, so at least the mempool is > bounded by > the size of the UTXO subset being spent. Dropping transactions from the > memory pool > when they run out of space seems a correct solution. I'm less convinced > about a > deterministic time-based rule, as that creates a double spending incentiv= e > at that > time, and a counter incentive to spam the network with your > risking-to-be-cleared > transaction as well. > > Regarding the block space, we've seen the pct% of one single block chain > space consumer > grow simultaneously with the introduction of larger blocks, so I'm not > actually convinced > there is right now a big need for larger blocks (note: right now). The > competition for > block chain space is mostly an issue for client software which doesn't de= al > correctly > with non-confirming transactions, and misleading users. It's mostly a > usability problem > now, but increasing block sizes isn't guaranteed to fix that; it may just > make more > space for spam. > > However, the presence of this bug, and the fact that a full solution is > available (0.8), > probably helps achieving consensus fixing it (=3Da hardfork) is needed, a= nd we > should take > advantage of that. But please, let's not rush things... > > -- > Piter > > -------------------------------------------------------------------------= ----- > 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 > --=20 Jorge Tim=F3n http://freico.in/ http://archive.ripple-project.org/