📅 Original date posted:2015-12-17
📝 Original message:On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>
That's taking a big risk. "Build up some fee pressure" is essentially
risking a Fee Event if uptake is slower than planned, or traffic is greater
than expected.
>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>
A hard fork will never achieve 100% There are many credible folks and
estimates who feel a May hard fork is reasonable and doable.
Further, hard forks restore the full trustless nature of the post-hard-fork
nodes. Soft forks continually erode that. That's why SW should come via
hard fork. The end result is more secure - 100% validation of witness
transactions.
If regular hard fork plans are proposed in public, many months in advance,
there is plenty of time for the community to react. Hard forks create a
more predictable market and environment for Users, and a more secure
network.
Further, even if you believe SW makes hard fork unnecessary, it is the
responsible thing to code and communicate to users the plan for a Fee Event
just in case SW uptake and extension block use does not match theoretical
projections of SW proponents.
Finally, SW does not eliminate and is orthogonal to Short Term Problem #1
(orig. email - drift into ECE)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/f044cec8/attachment-0001.html>;
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 17:46:31
in reply to nevent1q…76x7
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 17:46:31Event JSON
{
"id": "20336228c9c9bf0134108e7f8bb85172696edd33c299383223a72d4f887cdd17",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686159991,
"kind": 1,
"tags": [
[
"e",
"46b1d48aa4e00b636e8dc4e9c37e717542bb528954bcd46114dd6b14e1119e69",
"",
"root"
],
[
"e",
"f3c46db761969dfc3ed4b33a56db82172083d42d8c8c147e2b546e2f95f3a1ac",
"",
"reply"
],
[
"p",
"45d091c7bcdbb8674dc8b91c60f7323053ab1432c4c882fd2d9897fe502eebed"
]
],
"content": "📅 Original date posted:2015-12-17\n📝 Original message:On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo \u003clf-lists at mattcorallo.com\u003e\nwrote:\n\n\u003e A large part of your argument is that SW will take longer to deploy than a\n\u003e hard fork, but I completely disagree. Though I do not agree with some\n\u003e people claiming we can deploy SW significantly faster than a hard fork,\n\u003e once the code is ready (probably a six month affair) we can get it deployed\n\u003e very quickly. It's true the ecosystem may take some time to upgrade, but I\n\u003e see that as a feature, not a bug - we can build up some fee pressure with\n\u003e an immediate release valve available for people to use if they want to pay\n\u003e fewer fees.\n\u003e\n\nThat's taking a big risk. \"Build up some fee pressure\" is essentially\nrisking a Fee Event if uptake is slower than planned, or traffic is greater\nthan expected.\n\n\n\n\u003e\n\u003e On the other hand, a hard fork, while simpler for the ecosystem to upgrade\n\u003e to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5\n\u003e from today if we all put off heads down and work). One thing that has\n\u003e concerned me greatly through this whole debate is how quickly people seem\n\u003e to think we can roll out a hard fork. Go look at the distribution of node\n\u003e versions on the network today and work backwards to get nearly every node\n\u003e upgraded... Even with a year between fork-version-release and\n\u003e fork-activation, we'd still kill a bunch of nodes and instead of reducing\n\u003e their security model, lead them to be outright robbed.\n\u003e\n\nA hard fork will never achieve 100% There are many credible folks and\nestimates who feel a May hard fork is reasonable and doable.\n\nFurther, hard forks restore the full trustless nature of the post-hard-fork\nnodes. Soft forks continually erode that. That's why SW should come via\nhard fork. The end result is more secure - 100% validation of witness\ntransactions.\n\nIf regular hard fork plans are proposed in public, many months in advance,\nthere is plenty of time for the community to react. Hard forks create a\nmore predictable market and environment for Users, and a more secure\nnetwork.\n\nFurther, even if you believe SW makes hard fork unnecessary, it is the\nresponsible thing to code and communicate to users the plan for a Fee Event\njust in case SW uptake and extension block use does not match theoretical\nprojections of SW proponents.\n\nFinally, SW does not eliminate and is orthogonal to Short Term Problem #1\n(orig. email - drift into ECE)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/f044cec8/attachment-0001.html\u003e",
"sig": "b2a15a46fdecd617feb18849a48833f93f8216826037f4893e4fca392158f6a132afc7f690f06f91ce8cfd2e89ec97692574d668b91ce0de1088fa4e883f9e24"
}