Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-05-07 š Original message:On Thu, May 07, 2015 at ...
š
Original date posted:2015-05-07
š Original message:On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote:
> > Certainly a consensus in this kind of technical community should be a
> > basic requirement for any serious commitment to blocksize increase.
> >
>
> I'm afraid I have come to disagree. I no longer believe this community can
> reach consensus on anything protocol related. Some of these arguments have
> dragged on for years. Consensus isn't even well defined - consensus of who?
> Anyone who shows up? And what happens when, inevitably, no consensus is
> reached? Stasis forever?
Care to be specific?
We've made lots of protocol related changes, as well as non-consensus
policy changes, often in quite short timeframes, and with little drama.
For instance BIP66 adopting is progressing smoothly, and itself was very
quickly developed as part of a broader response to a serious OpenSSL
flaw. My own BIP65 is getting wide consensus with little drama and good
peer review, and that's happening even without as much attention paid to
it from myself as I should have been giving it. The BIP62 malleability
softfork is going more slowly, but that's because peer review is finding
issues and fixing them - something to be expected in an environment
where we simply must be cautious.
As for the v0.11 release, it will have pruning, perhaps the biggest
change to the way Bitcoin Core works that we've ever made. Equally it's
notable how many people collaborated on the implementation of pruning,
again with little drama.
Sure, some stuff has been hard to get consensus on. But those things
carry high risks, and involve code and practices known to be dangerous.
In most cases we've found out the lack of consensus was spot on, and
controversial changes turn out later to have severe security
vulnerabilities. I read that as a sign that the peer review and
consensus building process works just fine.
--
'peter'[:-1]@petertodd.org
00000000000000000af0c4ba9d91c00d48c4493899d7235fd819ac76f16d148d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/9dc82f9c/attachment.sig>;
š Original message:On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote:
> > Certainly a consensus in this kind of technical community should be a
> > basic requirement for any serious commitment to blocksize increase.
> >
>
> I'm afraid I have come to disagree. I no longer believe this community can
> reach consensus on anything protocol related. Some of these arguments have
> dragged on for years. Consensus isn't even well defined - consensus of who?
> Anyone who shows up? And what happens when, inevitably, no consensus is
> reached? Stasis forever?
Care to be specific?
We've made lots of protocol related changes, as well as non-consensus
policy changes, often in quite short timeframes, and with little drama.
For instance BIP66 adopting is progressing smoothly, and itself was very
quickly developed as part of a broader response to a serious OpenSSL
flaw. My own BIP65 is getting wide consensus with little drama and good
peer review, and that's happening even without as much attention paid to
it from myself as I should have been giving it. The BIP62 malleability
softfork is going more slowly, but that's because peer review is finding
issues and fixing them - something to be expected in an environment
where we simply must be cautious.
As for the v0.11 release, it will have pruning, perhaps the biggest
change to the way Bitcoin Core works that we've ever made. Equally it's
notable how many people collaborated on the implementation of pruning,
again with little drama.
Sure, some stuff has been hard to get consensus on. But those things
carry high risks, and involve code and practices known to be dangerous.
In most cases we've found out the lack of consensus was spot on, and
controversial changes turn out later to have severe security
vulnerabilities. I read that as a sign that the peer review and
consensus building process works just fine.
--
'peter'[:-1]@petertodd.org
00000000000000000af0c4ba9d91c00d48c4493899d7235fd819ac76f16d148d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/9dc82f9c/attachment.sig>;