š
Original date posted:2015-07-22
š Original message:-----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 <jgarzik at gmail.com> wrote:
>On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
>bitcoin-dev at 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-----
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 15:42:32
in reply to nevent1qā¦d24d
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:42:32Event JSON
{
"id": "ada5d9f03b173cebdb854e8e2d7b7da7d18e14ee6e793f584abcaaff95ca8f08",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686152552,
"kind": 1,
"tags": [
[
"e",
"2e544b01cfe0620e95990efdfb39d6c5828a4b2f5866e5b209d567b2efd50207",
"",
"root"
],
[
"e",
"45b7e168659380887bfd356d83dd0fa8f0d1c804ecde0592aa4edf678b8d689e",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "š
Original date posted:2015-07-22\nš Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nSorry, 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.\n\n\nOn 22 July 2015 13:43:19 GMT-04:00, Jeff Garzik \u003cjgarzik at gmail.com\u003e wrote:\n\u003eOn Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev \u003c\n\u003ebitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I don't agree with you at all.\n\u003e\u003e\n\u003e\u003e This is a case where if Jeff doesn't understand that issue, he's\n\u003e\u003e proposing changes that he's not competent enough to understand, and\n\u003eit'd\n\u003e\u003e save us a lot of review effort if he left that discussion. Equally,\n\u003eJeff\n\u003e\u003e is in a position in the dev community where he should be that\n\u003ecompetent;\n\u003e\u003e if he actually isn't it does a lot of good for the broader community\n\u003eto\n\u003e\u003e change that opinion.\n\u003e\u003e\n\u003e\u003e I personally *don't* think he's doing that, rather I believe he knows\n\u003e\u003e full well it's a bad patch and is proposing it because he wants to\n\u003epush\n\u003e\u003e discussion towards a solution. Often trolling the a audience with bad\n\u003e\u003e patches is an effective way to motivate people to respond by writing\n\u003e\u003e better ones; Jeff has told me he often does exactly that.\n\u003e\u003e\n\u003e\u003e\n\u003emmmm kay. Let's try to keep it technical, please.\n\u003e\n\u003e2MB is a limit that has been discussed as a viable next-step, meeting\n\u003ewith\n\u003ethe most consensus.\n\u003e\n\u003e2MB gets beyond the 1MB hard fork issue, while still remaining within a\n\u003esafety cap that should ensure the system does not go \"off the rails\" as\n\u003esome has predicted.\n\u003e\n\u003eSecurity, privacy and centralization are not going to disappear at 2MB.\n\u003e\n\u003eFurther, a limited step gains valuable field data for judging whether\n\u003efurther steps are warranted - thus informing the \"better block size\n\u003esolution\" development process.\n\u003e\n\u003eFinally, as stated in the initial PR, it is intended as a viable\n\u003efallback\n\u003eshould we reach a point of criticality where the user community feels a\n\u003eblock size increase is warranted, yet cannot reach consensus on a\n\u003efancy,\n\u003eall-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc.\n\u003e\n\u003eI am open to suggestions for improving BIP 102. The goal is a minimum\n\u003ecomplexity fallback that others have previously agreed was a useful\n\u003ekick-the-can compromise - a static 2MB cap.\n-----BEGIN PGP SIGNATURE-----\n\niQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsBl2\nAAoJEMCF8hzn9Lnc47AIAICM9pA+Jc6rkJ14U0vYqzhwTHmxuaNTXodmI1z88OKM\nzCCJQHNw/Xhy339/ZGFeUuVS/Csw275dtzZutLoZamnGnQLh9LllxYFzN8eGJkCL\nEcfo0JcyhduwUihgDfzgE++z5/Q0z5sIo+pZBNipqXW1+N0P/GAvYlHqeb9r0uXG\nccJghZUTwqzm6aySfvXVveTmp0AtjVko1jP1sTxF2pI/RIqBdMY4wEsZvmEhX7Tk\ng2iRiPWiEIYR1qETm6e5aQ/tj8W73932s15ozIM35nD5QId5qotQHTVttLAruQvl\n2Z35F79TIYDvYtnnRNWIsOyiwreH/y5c0kSUIgrjASA=\n=+jTv\n-----END PGP SIGNATURE-----",
"sig": "b599ac93570844ad2bd40b54b2adab3f9d45cc67f37a5d43b4d41393e48c287315fc0fd0ab5b49705572801dc93eae631d1529467a5e430641659a59624b1422"
}