{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-09\n📝 Original message:On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler \u003crryananizer at gmail.com\u003e wrote:\n\u003e\u003eI agree, but nothing I have advocated creates significant technical\n\u003e\u003edebt. It is also a bad engineering practice to combine functional\n\u003e\u003echanges (especially ones with poorly understood system wide\n\u003e\u003econsequences and low user autonomy) with structural tidying.\n\u003e\n\u003e I don't think I would classify placing things in consensus critical code\n\u003e when it doesn't need to be as \"structural tidying\".  Gavin said \"pile on\"\n\u003e which you took as implying \"a lot\", he can correct me, but I believe he\n\u003e meant \"add to\".\n\nNothing being discussed would move something from consensus critical\ncode to not consensus critical.\n\nWhat was being discussed was the location of the witness commitment;\nwhich is consensus critical regardless of where it is placed. Should\nit be placed in an available location which is compatible with the\nexisting network, or should the block hashing data structure\nimmediately be changed in an incompatible way to accommodate it in\norder to satisfy an ascetic sense of purity and to make fraud proofs\nsomewhat smaller?\n\nI argue that the size difference in the fraud proofs is not\ninteresting, the disruption to the network in an incompatible upgrade\nis interesting; and that if it really were desirable reorganization to\nmove the commitment point could be done as part of a separate change\nthat changes only the location of things (and/or other trivial\nadjustments); and that proceeding int this fashion would minimize\ndisruption and risk... by making the incompatible changes that will\nforce network wide software updates be as small and as simple as\npossible.\n\n\u003e\u003e (especially ones with poorly understood system wide consequences and low\n\u003e\u003e user autonomy)\n\u003e\n\u003e This implies there you have no confidence in the unit tests and functional\n\u003e testing around Bitcoin and should not be a reason to avoid refactoring.\n\u003e It's more a reason to increase testing so that you will have confidence when\n\u003e you refactor.\n\nI am speaking from our engineering experience in a  public,\nworld-wide, multi-vendor, multi-version, inter-operable, distributed\nsystem which is constantly changing and in production contains private\ncode, unknown and assorted hardware, mixtures of versions, unreliable\nnetworks, undisclosed usage patterns, and more sources of complex\nbehavior than can be counted-- including complex economic incentives\nand malicious participants.\n\nEven if we knew the complete spectrum of possible states for the\nsystem the combinatioric explosion makes complete testing infeasible.\n\nThough testing is essential one cannot \"unit test\" away all the risks\nrelated to deploying a new behavior in the network."}