📅 Original date posted:2017-03-28
📝 Original message:On 2017/3/28 10:31, Wang Chun via bitcoin-dev wrote:
> The basic idea is, let's stop the debate for whether we should upgrade
> to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,
> so any final decision would be a soft fork to this already deployed
> release. If by 2020, we still agree 1MB is enough, it can be changed
> back to 1MB limit and it would also a soft fork on top of that.
While I think this idea isn't bad in and of itself, there is an
assumption being made that the community would come to consensus
regarding a future soft fork. This, IMO, is a dangerous assumption.
Failure would potentially leave the network at a hard fork well past any
current proposal. It would also potentially lead to miners becoming
hostile players and making political demands. ("Soft fork down to X MB
or I'll shut down 15% of the network hashrate and work to shut down more
elsewhere.") I'd hope we can all agree that such a scenario would be
terrible.
I do agree that the idea of giving everybody plenty of time to plan is
critical. (Telecom providers need months, if not years, to plan for even
simple upgrades, which often are not as simple as they look on paper.) I
just think this proposal, while well-meaning, comes across as a bit of a
trojan horse as-is. I can't get behind it, although it could potentially
be molded into something else that's interesting, e.g., Johnson Lau's
Spoonnet. Fork-to-minimum, while introducing its own potential problems,
would put much less pressure on full nodes, and on the ecosphere as a
whole if the max needed to be soft forked down.
(I'd also like to see SegWit go live so that we can get an idea of how
much pressure there really is on the network, thereby giving us a better
idea of how high we can go. I still think we're flying a bit blind in
that regard.)
--
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark at vt.edu
PGP key ID: 26623924
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/3355f573/attachment.sig>;
Douglas Roark [ARCHIVE] /
npub12v…dqa4q
2023-06-07 17:58:03
in reply to nevent1q…8yul
Author Public Key
npub12vlytlltjj7g3s227u9jtx2g8qtsu7gscynnn99k808ydr4vygcqvdqa4qPublished at
2023-06-07 17:58:03Event JSON
{
"id": "9948aa5b8927a0143c4d3b9d33bb983a9162259c8d339e36a2a277b8dbe7b7d1",
"pubkey": "533e45ffeb94bc88c14af70b25994838170e7910c1273994b63bce468eac2230",
"created_at": 1686160683,
"kind": 1,
"tags": [
[
"e",
"f66fb8ea0b053d3b896ce377aea38775ffc7975376c3ee96291861cf920b456b",
"",
"root"
],
[
"e",
"e21824465e53aeeed0b23f67e13cd7799b58f5b664cdb674962927ad9d726558",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2017-03-28\n📝 Original message:On 2017/3/28 10:31, Wang Chun via bitcoin-dev wrote:\n\u003e The basic idea is, let's stop the debate for whether we should upgrade\n\u003e to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,\n\u003e so any final decision would be a soft fork to this already deployed\n\u003e release. If by 2020, we still agree 1MB is enough, it can be changed\n\u003e back to 1MB limit and it would also a soft fork on top of that.\n\nWhile I think this idea isn't bad in and of itself, there is an\nassumption being made that the community would come to consensus\nregarding a future soft fork. This, IMO, is a dangerous assumption.\nFailure would potentially leave the network at a hard fork well past any\ncurrent proposal. It would also potentially lead to miners becoming\nhostile players and making political demands. (\"Soft fork down to X MB\nor I'll shut down 15% of the network hashrate and work to shut down more\nelsewhere.\") I'd hope we can all agree that such a scenario would be\nterrible.\n\nI do agree that the idea of giving everybody plenty of time to plan is\ncritical. (Telecom providers need months, if not years, to plan for even\nsimple upgrades, which often are not as simple as they look on paper.) I\njust think this proposal, while well-meaning, comes across as a bit of a\ntrojan horse as-is. I can't get behind it, although it could potentially\nbe molded into something else that's interesting, e.g., Johnson Lau's\nSpoonnet. Fork-to-minimum, while introducing its own potential problems,\nwould put much less pressure on full nodes, and on the ecosphere as a\nwhole if the max needed to be soft forked down.\n\n(I'd also like to see SegWit go live so that we can get an idea of how\nmuch pressure there really is on the network, thereby giving us a better\nidea of how high we can go. I still think we're flying a bit blind in\nthat regard.)\n\n-- \n---\nDouglas Roark\nCryptocurrency, network security, travel, and art.\nhttps://onename.com/droark\njoroark at vt.edu\nPGP key ID: 26623924\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/3355f573/attachment.sig\u003e",
"sig": "01dbe5f727a9257392ca473fe8a32dda449175e0af0d0bcce06d5f42648f2f5018f40a1924c962abf50b03af8f00dedf0c347280967f1c3e8f405deb89217b88"
}