Date: Thu, 8 Nov 2012 13:56:52 +0100
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20121108125651.GA10119@vps7135.xlshosting.net>
References: <CABsx9T1K+XKr=OT5TC4d1KiQ_kXH+giCWHPiS=t7-NyVOmGTDw@mail.gmail.com>
	<CAPg+sBisYEMWzS5JNXAoB5EeHc=YboOJqsktEqON1dY6Lo2SsA@mail.gmail.com>
	<CANEZrP0LUv69wYwg_6ivPc=mFiGEYKomaJXmmT2Zm14bKik0bQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP0LUv69wYwg_6ivPc=mFiGEYKomaJXmmT2Zm14bKik0bQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday
Precedence: list

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