Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-28 📝 Original message:SPV mining has been ...
📅 Original date posted:2021-02-28
📝 Original message:SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the
last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make
money by reducing the difficulty, but that is true as much today as during a fork. Still, I think you've made my point -
someone has to take an active, malicious action in order to mine a bad block, vs with forced signaling, someone only
needs to forget to reconfigure one out of one hundred pool servers they operate.
Matt
On 2/28/21 15:02, Jeremy 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-lists at mattcorallo.com <mailto:lf-lists at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> >
>
📝 Original message:SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the
last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make
money by reducing the difficulty, but that is true as much today as during a fork. Still, I think you've made my point -
someone has to take an active, malicious action in order to mine a bad block, vs with forced signaling, someone only
needs to forget to reconfigure one out of one hundred pool servers they operate.
Matt
On 2/28/21 15:02, Jeremy 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-lists at mattcorallo.com <mailto:lf-lists at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> >
>