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 1TWRfK-00086G-O3 for bitcoin-development@lists.sourceforge.net; Thu, 08 Nov 2012 12:57:02 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TWRfG-0001Yo-Ov for bitcoin-development@lists.sourceforge.net; Thu, 08 Nov 2012 12:57:02 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id 5F58F60FF5; Thu, 8 Nov 2012 13:56:52 +0100 (CET) Date: Thu, 8 Nov 2012 13:56:52 +0100 From: Pieter Wuille To: Mike Hearn Message-ID: <20121108125651.GA10119@vps7135.xlshosting.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1TWRfG-0001Yo-Ov Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 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: Thu, 08 Nov 2012 12:57:02 -0000 On Thu, Nov 08, 2012 at 10:19:05AM +0100, Mike Hearn wrote: > Comments: > > BIP process: are we happy with how it is working? What can we do to improve > it? > > Needing some kind of process to allocate a number is over the top. I > skipped this for the bloom filtering BIP. We should take off the part of > the {{BIP}} template that says "don't just pick a number and add a bip" - > that's exactly what people should do. I'm not sure there's any need for an > editing role either. Right now, there seem to be little problems with allocation and viability of proposed BIPs, with hardly any reviewing/formal allocation being done in practice. In the past there have been collisions though, and there also have been nonsensical proposals. I'm in favor of some moderate form of process, but if the process becomes a burden more than a help, there is clearly a problem. It seems there is also little attractiveness to writing BIPs. If many proposals do not result in useful discussion, there is little incentive to write one except for those proposals that absolutely need to (p2p protocol, block validity rules, ...). That's a pity in my opinion - I'd like to see non-core proposals related to Bitcoin being discussed more often as well. > > Is it time to feature-freeze 0.8 > > I'd like more time to get the bloom filtering work in. It'll be easier to > promote the 0.8 release if we can sell it as "important > scalability/performance improvement for the network, upgrade to help > Bitcoin keep growing", as whilst there's no real auto update or organized > people who religiously update promotion is very important. I think > ultraprune + bloom filtering is the two major scalability improvements we > have right now. Agree, I think Bloom filtering should make it into 0.8 - it's a critical step to make SPV clients more useful for end users. Regarding ultraprune, there are a few TODOs left: * Auto-migrate old data (depends on -reindex, for which there is a pullreq) * UTXO set consistency checks at startup (-checklevel) -- Pieter