-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sorry, but I think you need to re-read my first message. What you've written below has nothing to do with what I actually said re: how you're BIP102 and associated pull-req doesn't measure miner consensus.
On 22 July 2015 13:43:19 GMT-04:00, Jeff Garzik <jgar...@gmail.com> wrote: >On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I don't agree with you at all. >> >> This is a case where if Jeff doesn't understand that issue, he's >> proposing changes that he's not competent enough to understand, and >it'd >> save us a lot of review effort if he left that discussion. Equally, >Jeff >> is in a position in the dev community where he should be that >competent; >> if he actually isn't it does a lot of good for the broader community >to >> change that opinion. >> >> I personally *don't* think he's doing that, rather I believe he knows >> full well it's a bad patch and is proposing it because he wants to >push >> discussion towards a solution. Often trolling the a audience with bad >> patches is an effective way to motivate people to respond by writing >> better ones; Jeff has told me he often does exactly that. >> >> >mmmm kay. Let's try to keep it technical, please. > >2MB is a limit that has been discussed as a viable next-step, meeting >with >the most consensus. > >2MB gets beyond the 1MB hard fork issue, while still remaining within a >safety cap that should ensure the system does not go "off the rails" as >some has predicted. > >Security, privacy and centralization are not going to disappear at 2MB. > >Further, a limited step gains valuable field data for judging whether >further steps are warranted - thus informing the "better block size >solution" development process. > >Finally, as stated in the initial PR, it is intended as a viable >fallback >should we reach a point of criticality where the user community feels a >block size increase is warranted, yet cannot reach consensus on a >fancy, >all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc. > >I am open to suggestions for improving BIP 102. The goal is a minimum >complexity fallback that others have previously agreed was a useful >kick-the-can compromise - a static 2MB cap. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsBl2 AAoJEMCF8hzn9Lnc47AIAICM9pA+Jc6rkJ14U0vYqzhwTHmxuaNTXodmI1z88OKM zCCJQHNw/Xhy339/ZGFeUuVS/Csw275dtzZutLoZamnGnQLh9LllxYFzN8eGJkCL Ecfo0JcyhduwUihgDfzgE++z5/Q0z5sIo+pZBNipqXW1+N0P/GAvYlHqeb9r0uXG ccJghZUTwqzm6aySfvXVveTmp0AtjVko1jP1sTxF2pI/RIqBdMY4wEsZvmEhX7Tk g2iRiPWiEIYR1qETm6e5aQ/tj8W73932s15ozIM35nD5QId5qotQHTVttLAruQvl 2Z35F79TIYDvYtnnRNWIsOyiwreH/y5c0kSUIgrjASA= =+jTv -----END PGP SIGNATURE----- _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
