I think it has been shown that an understanding of reasonableness is not universal, making any assertion about it as a collective goal kind of self-defeating. The question is what is achievable, not what is reasonable. I’m not making any value judgements here. Simply pointing out that anything other than a successful 51% attack will create a split.
e > On Feb 28, 2021, at 12:25, Matt Corallo <lf-li...@mattcorallo.com> wrote: > > Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at > [1], which I referenced and specifically addressed each of in the OP of this > thread. > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html > >> On 2/28/21 15:19, Eric Voskuil wrote: >> In the attempt to change consensus rules there is a simple set of choices: >> 1) hard fork: creates a chain split >> 2) soft fork: creates a chain split >> 3) 51% attack: does not create a chain split >> The presumption being that one can never assume 100% explicit adoption of >> any rule change. >> A 51% attack can of course fail. It is also possible that signaling can be >> untruthful. But miner signaling provides some level of assurance that it >> will be successful. This level of assurance is increased by adoption of a >> higher than majority threshold, as has been done in the past. >> Most of the discussion I’ve seen has been focused on who is in charge. >> Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nobody >> is in charge. >> The majority of those who mine can choose to enforce censorship any time >> they want. They don’t need anyone’s permission. No power is given to them by >> developers or anyone else. They have that power based on their own capital >> invested. >> Similarly, the economy (those who accept bitcoin) can enforce any rule >> change it wants to. And it can do so at any level of participation that >> wants to go along. Anyone can do this, it requires nobody’s permission. >> Furthermore, it is possible for the economy to signal its level of agreement >> in every transaction, as miners have done in blocks previously. >> But if the objective is to produce a rule change while avoiding a chain >> split, 50% is a much lower bar than 100%. If there is some other objective, >> it’s not clear to me what it is. >> e >>>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> >>> Miners still can generate invalid blocks as a result of SPV mining, and it >>> could be profitable to do "bad block enhanced selfish mining" to take >>> advantage of it. >>> >>> >>> Hard to analyze exactly what that looks like, but... >>> >>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate >>> to mine bad blocks would mean 1/4th of the time you could make 20% of the >>> hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One >>> could analyze out that the lost hash rate for bad blocks only matters for >>> the first difficulty adjustment period you're doing this for too, as the >>> hashrate drop will be accounted for -- but then a miner can switch back to >>> mining valid chain, giving themselves a larger % of hashrate. >>> >>> So it is still possible that an un-upgraded miner will fail part 3, and >>> attempting to accommodate un-upgraded miners leads to some nasty >>> oscillating hashrate being optimal. >>> >>> >>> -- >>> @JeremyRubin >>> <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin> >>> >>> >>>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-li...@mattcorallo.com >>>> <mailto:lf-li...@mattcorallo.com>> wrote: >>> >>> Note further that mandatory signaling isn't "just" a flag day - unlike a >>> Taproot flag day (where miners running >>> Bitcoin >>> Core unmodified today will not generate invalid blocks), a mandatory >>> signaling flag day blatantly ignores goal (3) >>> from >>> my original post - it results in any miner who has not taken active >>> action (and ensured every part of their >>> often-large >>> infrastructure has been correctly reconfigured) generating invalid >>> blocks. >>> >>> As for "Taproot" took too long, hey, at least if its locked in people >>> can just build things assuming it exists. Some >>> already are, but once its clearly locked in, there's no reason to not >>> continue other work at the same time. >>> >>> Matt >>> >>>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote: >>> > I agree with much of the logic presented by Matt here. >>> > >>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet >>> we find ourselves in a situation where a >>> "tiny" >>> > parameter has the potential to cause great network disruption and >>> confusion (rationality is not too useful a >>> concept >>> > here given differing levels of sophistication and information). It is >>> therefore much simpler and more likely to be >>> > universally understood by all network participants to just have a flag >>> day. It is easier to communicate what users >>> > should do and when. >>> > >>> > This is ultimately not coercive to users because the upgrade for >>> Taproot itself is provable and analyzable on >>> its own, >>> > but activation parameters based on what % of economically relevant >>> nodes are running an upgrade by a certain >>> date are >>> > not. Selecting these sorts of complicated consensus parameters may >>> ultimately present more opportunity for a >>> cooptable >>> > consensus process than something more straightforward. >>> > >>> > >>> > That said, a few points strike me as worth delving into. >>> > >>> > >>> > 1) Con: Mandatory signalling is no different than a flag day. >>> Mandatory signaling is effectively 2 flag days -- >>> one for >>> > the signaling rule, 1 for the taproot type. The reason for the 2 week >>> gap between flag day for signaling and >>> flag day >>> > for taproot rules is, more or less, so that nodes who aren't taproot >>> ready at the 1st flag day do not end up SPV >>> mining >>> > (using standardness rules in mempool prevents them from mining an >>> invalid block on top of a valid tip, but does not >>> > ensure the tip is valid). >>> > 2) Con: Releasing a flag day without releasing the LOT=true code >>> leading up to that flag day means that clients >>> would >>> > not be fully compatible with an early activation that could be >>> proposed before the flag day is reached. E.g., >>> LOT=true >>> > is a flag day that retains the possibility of being compatible with >>> other BIP8 releases without changing software. >>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm >>> personally skeptical that early activation >>> is/was >>> > ever a good idea. A fixed activation date may be largely superior for >>> business purposes, software engineering >>> schedules, >>> > etc. I think even with signaling BIP8, it would be possibly superior >>> to activate rules at a fixed date (or a >>> quantized >>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe >>> more). >>> > 4) Pro: part of the argument for BIP-8=false is that it is possible >>> that the rule could not activate, if >>> signaling does >>> > not occur, providing additional stopgap against dev collusion and >>> bugs. But BIP-8 can activate immediately (with >>> start >>> > times being proposed 1 month after release?) so we don't have >>> certainty around how much time there is for that >>> secondary >>> > review process (read -- I think it isn't that valuable) and if there >>> *is* a deadly bug discovered, we might want to >>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the >>> rule activates it enables more mining >>> reward). So I >>> > think that it's a healthier mindset to release a with definite >>> deadline and not rule out having to do a hard >>> fork if >>> > there is a grave issue (we shouldn't ever release a SF if we think >>> this is at all likely, mind you). >>> > 5) Con: It's already taken so long for taproot, the schedule around >>> taproot was based on the idea it could early >>> > activate, 2022 is now too far away. I don't know how to defray this >>> other than, if your preferred idea is 1 year >>> flag >>> > day, to do that via LOT=true so that taproot can still have early >>> activation if desired. >>> > >>> > Overall I agree with the point that all the contention around LOT, >>> makes a flag day look not so bad. And something >>> > closer to a flag day might not be so bad either for future forks as >>> well. >>> > >>> > However, I think given the appetite for early activation, if a flag >>> day is desired I think LOT=true is the best >>> option >>> > at this time as it allows our flag day to remain compatible with such >>> an early activation. >>> > >>> > I think we can also clearly communicate that LOT=true for Taproot is >>> not a precedent setting occurence for any >>> future >>> > forks (hold me accountable to not using this as precedent this should >>> I ever advocate for a SF with similar release >>> > parameters). >>> > >>> > >>> > _______________________________________________ >>> > bitcoin-dev mailing list >>> > bitcoin-dev@lists.linuxfoundation.org >>> <mailto:bitcoin-dev@lists.linuxfoundation.org> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> >>> > >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
