{"type":"rich","version":"1.0","author_name":"npub19jx6yq5fyvvcn3zlf0f60kr78q7wq5fy5qd9yqlqwumlqqcfc8rsl7fxhj","author_url":"https://nostr.ae/npub19jx6yq5fyvvcn3zlf0f60kr78q7wq5fy5qd9yqlqwumlqqcfc8rsl7fxhj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-09\n📝 Original message:\u003eI agree, but nothing I have advocated creates significant technical\n\u003edebt. It is also a bad engineering practice to combine functional\n\u003echanges (especially ones with poorly understood system wide\n\u003econsequences and low user autonomy) with structural tidying.\n\nI don't think I would classify placing things in consensus critical code\nwhen it doesn't need to be as \"structural tidying\".  Gavin said \"pile on\"\nwhich you took as implying \"a lot\", he can correct me, but I believe he\nmeant \"add to\".\n\n\u003e (especially ones with poorly understood system wide consequences and low\nuser autonomy)\n\nThis implies there you have no confidence in the unit tests and functional\ntesting around Bitcoin and should not be a reason to avoid refactoring.\nIt's more a reason to increase testing so that you will have confidence\nwhen you refactor.\n\nAlso I don't think Martin Fowler would agree with you...\n\n\"Refactoring should be done in conjunction with adding new features.\"\n\n\"Always leave the code better than when you found it.\"\n\n\"Often you start working on adding new functionality and you realize the\nexisting structures don't play well with what you're about to do.\n\nIn this situation it usually pays to begin by refactoring the existing code\ninto the shape you now know is the right shape for what you're about to do.\"\n\n-Martin Fowler\n\n\n\n\n\n\n\n\nOn Tue, Dec 8, 2015 at 7:31 PM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e Create a 1-megabyte transaction, with all of it's inputs spending\n\u003e \u003e segwitness-spending SIGHASH_ALL inputs.\n\u003e \u003e\n\u003e \u003e Because the segwitness inputs are smaller in the block, you can fit more\n\u003e of\n\u003e \u003e them into 1 megabyte. Each will hash very close to one megabyte of data.\n\u003e\n\u003e Witness size comes out of the 1MB at a factor of 0.25. It is not\n\u003e possible to make a block which has signatures with the full 1MB of\n\u003e data under the sighash while also having signatures externally.  So\n\u003e every byte moved into the witness and thus only counted as 25% comes\n\u003e out of the data being hashed and is hashed nInputs (*checksigs) less\n\u003e times.\n\u003e\n\u003e \u003e I think it is a huge mistake not to \"design for success\" (see\n\u003e \u003e http://gavinandresen.ninja/designing-for-success ).\n\u003e\n\u003e We are designing for success; including the success of being able to\n\u003e adapt and cope with uncertainty-- which is the most critical kind of\n\u003e success we can have in a world where nothing is and can be\n\u003e predictable.\n\u003e\n\u003e \u003e I think it is a huge mistake to pile on technical debt in\n\u003e consensus-critical\n\u003e \u003e code. I think we should be working harder to make things simpler, not\n\u003e more\n\u003e \u003e complex, whenever possible.\n\u003e\n\u003e I agree, but nothing I have advocated creates significant technical\n\u003e debt. It is also a bad engineering practice to combine functional\n\u003e changes (especially ones with poorly understood system wide\n\u003e consequences and low user autonomy) with structural tidying.\n\u003e\n\u003e \u003e And I think there are pretty big self-inflicted current problems because\n\u003e \u003e worries about theoretical future problems have prevented us from coming\n\u003e to\n\u003e \u003e consensus on simple solutions.\n\u003e\n\u003e That isn't my perspective. I believe we've suffered delays because of\n\u003e a strong desire to be inclusive and hear out all ideas, and not\n\u003e forestall market adoption, even for ideas that eschewed pragmatism and\n\u003e tried to build for forever in a single step and which in our hear of\n\u003e hearts we knew were not the right path today. It's time to move past\n\u003e that and get back on track with the progress can make and have been\n\u003e making, in terms of capacity as well as many other areas. I think that\n\u003e is designing for success.\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/20151208/ac78b75c/attachment.html\u003e"}