{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-09\n📝 Original message:Greg, if you have actual data showing that putting the commitment in the\nlast transaction would be disruptive, and how disruptive, that would be\nappreciated. Of the mining hardware I have looked at, none of it cared at\nall what transactions other than the coinbase are. You need to provide a\npath to the coinbase for extranonce rolling, but the witness commitment\nwouldn't need to be updated.\n\nI'm sorry but it's not clear how this would be an incompatible upgrade,\ndisruptive to anything other than the transaction selection code. Maybe I'm\nmissing something? I'm not familiar with all the hardware or pooling setups\nout there.\n\nOn Wed, Dec 9, 2015 at 2:29 PM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler \u003crryananizer at gmail.com\u003e wrote:\n\u003e \u003e\u003eI agree, but nothing I have advocated creates significant technical\n\u003e \u003e\u003edebt. It is also a bad engineering practice to combine functional\n\u003e \u003e\u003echanges (especially ones with poorly understood system wide\n\u003e \u003e\u003econsequences and low user autonomy) with structural tidying.\n\u003e \u003e\n\u003e \u003e I don't think I would classify placing things in consensus critical code\n\u003e \u003e when it doesn't need to be as \"structural tidying\".  Gavin said \"pile on\"\n\u003e \u003e which you took as implying \"a lot\", he can correct me, but I believe he\n\u003e \u003e meant \"add to\".\n\u003e\n\u003e Nothing being discussed would move something from consensus critical\n\u003e code to not consensus critical.\n\u003e\n\u003e What was being discussed was the location of the witness commitment;\n\u003e which is consensus critical regardless of where it is placed. Should\n\u003e it be placed in an available location which is compatible with the\n\u003e existing network, or should the block hashing data structure\n\u003e immediately be changed in an incompatible way to accommodate it in\n\u003e order to satisfy an ascetic sense of purity and to make fraud proofs\n\u003e somewhat smaller?\n\u003e\n\u003e I argue that the size difference in the fraud proofs is not\n\u003e interesting, the disruption to the network in an incompatible upgrade\n\u003e is interesting; and that if it really were desirable reorganization to\n\u003e move the commitment point could be done as part of a separate change\n\u003e that changes only the location of things (and/or other trivial\n\u003e adjustments); and that proceeding int this fashion would minimize\n\u003e disruption and risk... by making the incompatible changes that will\n\u003e force network wide software updates be as small and as simple as\n\u003e possible.\n\u003e\n\u003e \u003e\u003e (especially ones with poorly understood system wide consequences and low\n\u003e \u003e\u003e user autonomy)\n\u003e \u003e\n\u003e \u003e This implies there you have no confidence in the unit tests and\n\u003e functional\n\u003e \u003e testing around Bitcoin and should not be a reason to avoid refactoring.\n\u003e \u003e It's more a reason to increase testing so that you will have confidence\n\u003e when\n\u003e \u003e you refactor.\n\u003e\n\u003e I am speaking from our engineering experience in a  public,\n\u003e world-wide, multi-vendor, multi-version, inter-operable, distributed\n\u003e system which is constantly changing and in production contains private\n\u003e code, unknown and assorted hardware, mixtures of versions, unreliable\n\u003e networks, undisclosed usage patterns, and more sources of complex\n\u003e behavior than can be counted-- including complex economic incentives\n\u003e and malicious participants.\n\u003e\n\u003e Even if we knew the complete spectrum of possible states for the\n\u003e system the combinatioric explosion makes complete testing infeasible.\n\u003e\n\u003e Though testing is essential one cannot \"unit test\" away all the risks\n\u003e related to deploying a new behavior in the network.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/5924c67f/attachment.html\u003e"}