On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev
<[email protected]> 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 <[email protected]
<mailto:[email protected]>> 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
> [email protected]
<mailto:[email protected]>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
