{"type":"rich","version":"1.0","author_name":"npub17t0q8zqty0mzjuk6t6jul40zvszs0jwds0kkxy3d8x5xef60073sckadm9","author_url":"https://nostr.ae/npub17t0q8zqty0mzjuk6t6jul40zvszs0jwds0kkxy3d8x5xef60073sckadm9","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-05-23\n📝 Original message:I'm glad some discussion has been moved back here.\n\nCorrect me if I am wrong, but currently core developers are arguing over\nwhether or not to allow an optional configuration switch which defaults off\nbut signals and enforces BIP148 when used. Who are we protecting users\nfrom, themselves? Are you protecting core? from what? I am somewhat\ngenuinely befuddled by those who can't even allow a user config switch to\nbe set.\n\nI guess I find it all incredibly silly, but perhaps I suffer from some\nbasic confusion.\n\n\n\nOn Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I also do not support the BIP 148 UASF, and I'd like to add to the points\n\u003e that Greg has already raised in this thread.\n\u003e\n\u003e BIP 148 would introduce a new consensus rule that softforks out non-segwit\n\u003e signalling blocks in some time period.  I reject this consensus rule as\n\u003e both arbitrary and needlessly disruptive.  Bitcoin's primary purpose is to\n\u003e reach consensus on the state of a shared ledger, and even though I think\n\u003e the Bitcoin network ought to adopt segwit, I don't think that concern\n\u003e trumps the goal of not splitting the network.\n\u003e\n\u003e Many BIP 148 advocates seem to start with the assumption that segwit\n\u003e already has a lot of support, and suggest that BIP 148 does as well.\n\u003e However I don't think it's fair or correct to separate the activation\n\u003e proposal for segwit from the rest of the segwit proposal.  The deployment\n\u003e parameters for segwit are consensus-critical; assuming that some other\n\u003e deployment has consensus because it would result in the rest of the segwit\n\u003e proposal activating is an unjustified leap.\n\u003e\n\u003e Even if there were no feasible alternate segwit deployment method\n\u003e available to us, I would hesitate to recommend that the network adopt a\n\u003e potentially consensus-splitting approach, even though I firmly believe that\n\u003e the ideas behind segwit are fundamentally good ones.  But fortunately that\n\u003e is not the situation we are in; we have substantially less disruptive\n\u003e methods available to us to activate it, even if the current BIP 9\n\u003e deployment were to fail -- such as another BIP 9 deployment in the future,\n\u003e or perhaps a BIP 149 deployment.\n\u003e\n\u003e If we do pursue a \"user-activated\" deployment of segwit, I'd recommend\n\u003e that we do so in a more careful way than BIP 148 or 149 currently suggest,\n\u003e which as I understand would otherwise make very few changes to the current\n\u003e implementation.  However, due to the BIP 9 activation assumption, the\n\u003e Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together\n\u003e the idea that miners would both enforce the rules and mine segwit blocks.\n\u003e However, we can separate these concerns, as we started to do in the Bitcoin\n\u003e Core 0.14.1 release, where mining segwit blocks is not required in order to\n\u003e generally mine or signal for segwit in the software.  And we can go further\n\u003e still: without too much work, we could make further improvements to\n\u003e accommodate miners who, for whatever reason, don't want to upgrade their\n\u003e systems, such as by improving block relay from pre-segwit peers [1], or\n\u003e optimizing transaction selection for miners who are willing to enforce the\n\u003e segwit rules but haven't upgraded their systems to mine segwit blocks [2].\n\u003e\n\u003e If we would seek to activate a soft-fork with less clear miner signaling\n\u003e (such as BIP 149), then I think such improvements are warranted to minimize\n\u003e network disruption.  In general, we should not seek to censor hashpower on\n\u003e the network unless we have a very important reason for doing so.  While the\n\u003e issues here are nuanced, if I were to evaluate the BIP 148 soft-fork\n\u003e proposal on the spectrum of \"censorship attack on Bitcoin\" to \"benign\n\u003e protocol upgrade\", BIP 148 strikes me as closer to the former than the\n\u003e latter.  There is simply no need here to orphan these non-signalling blocks\n\u003e that could otherwise be used to secure the network.\n\u003e\n\u003e To go further: I think BIP 148 is ill-conceived even for achieving its own\n\u003e presumed goals -- the motivation for adding a consensus rule that applies\n\u003e to the version bits on blocks is surely for the effect such bits have on\n\u003e older software, such as Bitcoin Core releases 0.13.1 and later.  Yet in\n\u003e trying to bring those implementations along as segwit-enforcing software,\n\u003e BIP 148 would risk forking from such clients in the short term!  If one\n\u003e really cared about maintaining consensus with older, segwit-enabled\n\u003e software, it would make far more sense to seek segwit activation in a way\n\u003e that didn't fork from them (such as BIP 149, or a new BIP 9 deployment\n\u003e after this one times out).  And if one doesn't care about such consensus,\n\u003e then it'd be far simpler to just set (e.g.) August 1 as the flag day\n\u003e activation of segwit, and not play these contortionist games with block\n\u003e version bits, which carry no useful or intrinsic meaning.  Either of these\n\u003e two approaches should have the advantage of reduced fork risk, compared\n\u003e with BIP 148.\n\u003e\n\u003e Of course, everyone is free to run the software of their choosing.  I\n\u003e write this to both generally convey my opposition to a careless proposal,\n\u003e which I believe represents a way of thinking that is detrimental to\n\u003e Bitcoin's long run success, and specifically explain why I oppose inclusion\n\u003e of this proposal in the Bitcoin Core implementation [3].  The Bitcoin Core\n\u003e project hasn't been, and shouldn't be, careless in deploying consensus\n\u003e changes.  Instead, I think the Bitcoin Core project ought to stand up for\n\u003e the best practices that our community has learned about how to deploy such\n\u003e changes (specifically for minimizing chain-split risk when deploying a soft\n\u003e fork!), and I think we should all avoid adoption or encouragement of\n\u003e practices that would depart from the high standards we are capable of\n\u003e achieving.\n\u003e\n\u003e\n\u003e  [1] https://lists.linuxfoundation.org/pipermail/\n\u003e bitcoin-dev/2017-March/013811.html\n\u003e  [2] https://github.com/bitcoin/bitcoin/pull/9955\n\u003e  [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925\n\u003e\n\u003e\n\u003e --Suhas Daftuar\n\u003e\n\u003e\n\u003e On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I do not support the BIP148 UASF for some of the same reasons that I\n\u003e\u003e do support segwit:  Bitcoin is valuable in part because it has high\n\u003e\u003e security and stability, segwit was carefully designed to support and\n\u003e\u003e amplify that engineering integrity that people can count on now and\n\u003e\u003e into the future.\n\u003e\u003e\n\u003e\u003e I do not feel the the approach proposed in BIP148 really measures up\n\u003e\u003e to the standard set by segwit itself, or the existing best practices\n\u003e\u003e in protocol development in this community.\n\u003e\u003e\n\u003e\u003e The primary flaw in BIP148 is that by forcing the activation of the\n\u003e\u003e existing (non-UASF segwit) nodes it almost guarantees at a minor level\n\u003e\u003e of disruption.\n\u003e\u003e\n\u003e\u003e Segwit was carefully engineered so that older unmodified miners could\n\u003e\u003e continue operating _completely_ without interruption after segwit\n\u003e\u003e activates.\n\u003e\u003e\n\u003e\u003e Older nodes will not include segwit spends, and so their blocks will\n\u003e\u003e not be invalid even if they do not have segwit support. They can\n\u003e\u003e upgrade to it on their own schedule. The only risk non-participating\n\u003e\u003e miners take after segwit activation is that if someone else mines an\n\u003e\u003e invalid block they would extend it, a risk many miners already\n\u003e\u003e frequently take with spy-mining.\n\u003e\u003e\n\u003e\u003e I do not think it is a horrible proposal: it is better engineered than\n\u003e\u003e many things that many altcoins do, but just not up to our normal\n\u003e\u003e standards. I respect the motivations of the authors of BIP 148.  If\n\u003e\u003e your goal is the fastest possible segwit activation then it is very\n\u003e\u003e useful to exploit the \u003e80% of existing nodes that already support the\n\u003e\u003e original version of segwit.\n\u003e\u003e\n\u003e\u003e But the fastest support should not be our goal, as a community-- there\n\u003e\u003e is always some reckless altcoin or centralized system that can support\n\u003e\u003e something faster than we can-- trying to match that would only erode\n\u003e\u003e our distinguishing value in being well engineered and stable.\n\u003e\u003e\n\u003e\u003e \"First do no harm.\" We should use the least disruptive mechanisms\n\u003e\u003e available, and the BIP148 proposal does not meet that test.  To hear\n\u003e\u003e some people-- non-developers on reddit and such-- a few even see the\n\u003e\u003e forced orphaning of 148 as a virtue, that it's punitive for\n\u003e\u003e misbehaving miners. I could not not disagree with that perspective any\n\u003e\u003e more strongly.\n\u003e\u003e\n\u003e\u003e Of course, I do not oppose the general concept of a UASF but\n\u003e\u003e _generally_ a soft-fork (of any kind) does not need to risk disruption\n\u003e\u003e of mining, just as segwit's activation does not.  UASF are the\n\u003e\u003e original kind of soft-fork and were the only kind of fork practiced by\n\u003e\u003e Satoshi. P2SH was activated based on a date, and all prior ones were\n\u003e\u003e based on times or heights.  We introduced miner based activation as\n\u003e\u003e part of a process of making Bitcoin more stable in the common case\n\u003e\u003e where the ecosystem is all in harmony.  It's kind of weird to see UASF\n\u003e\u003e portrayed as something new.\n\u003e\u003e\n\u003e\u003e It's important the users not be at the mercy of any one part of the\n\u003e\u003e ecosystem to the extent that we can avoid it-- be it developers,\n\u003e\u003e exchanges, chat forums, or mining hardware makers.  Ultimately the\n\u003e\u003e rules of Bitcoin work because they're enforced by the users\n\u003e\u003e collectively-- that is what makes Bitcoin Bitcoin, it's what makes it\n\u003e\u003e something people can count on: the rules aren't easy to just change.\n\u003e\u003e\n\u003e\u003e There have been some other UASF proposals that avoid the forced\n\u003e\u003e disruption-- by just defining a new witness bit and allowing\n\u003e\u003e non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I\n\u003e\u003e think they are vastly superior. They would be slower to deploy, but I\n\u003e\u003e do not think that is a flaw.\n\u003e\u003e\n\u003e\u003e We should have patience. Bitcoin is a system that should last for all\n\u003e\u003e ages and power mankind for a long time-- ten years from now a couple\n\u003e\u003e years of dispute will seem like nothing. But the reputation we earn\n\u003e\u003e for stability and integrity, for being a system of money people can\n\u003e\u003e count on will mean everything.\n\u003e\u003e\n\u003e\u003e If these discussions come up, they'll come up in the form of reminding\n\u003e\u003e people that Bitcoin isn't easily changed at a whim, even when the\n\u003e\u003e whims are obviously good, and how that protects it from being managed\n\u003e\u003e like all the competing systems of money that the world used to use\n\u003e\u003e were managed. :)\n\u003e\u003e\n\u003e\u003e So have patience, don't take short cuts.  Segwit is a good improvement\n\u003e\u003e and we should respect it by knowing that it's good enough to wait for,\n\u003e\u003e and for however its activated to be done the best way we know how.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\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\u003e\n\n\n-- \nSteven Pine\n(510) 517-7075\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170523/6d4ec9c9/attachment.html\u003e"}