From: Pieter Wuille <pieter.wuille@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday
Date: Thu, 8 Nov 2012 13:56:52 +0100 [thread overview]
Message-ID: <20121108125651.GA10119@vps7135.xlshosting.net> (raw)
In-Reply-To: <CANEZrP0LUv69wYwg_6ivPc=mFiGEYKomaJXmmT2Zm14bKik0bQ@mail.gmail.com>
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
next prev parent reply other threads:[~2012-11-08 12:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 18:47 Gavin Andresen
2012-11-06 19:13 ` Luke-Jr
2012-11-06 19:56 ` slush
2012-11-06 22:12 ` Luke-Jr
2012-11-07 19:37 ` Pieter Wuille
2012-11-08 9:19 ` Mike Hearn
2012-11-08 12:56 ` Pieter Wuille [this message]
2012-11-08 13:07 ` Gregory Maxwell
[not found] ` <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com>
2012-11-08 13:10 ` [Bitcoin-development] Fwd: " Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121108125651.GA10119@vps7135.xlshosting.net \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox