1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
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 <pw@vps7135.xlshosting.net>) 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 <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>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
|
