š
Original date posted:2021-02-28
š Original message: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>
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
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210228/df85cf85/attachment-0001.html>;
Jeremy [ARCHIVE] /
npub1q8ā¦8qwta
2023-06-07 18:29:19
in reply to nevent1qā¦r6he
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 18:29:19Event JSON
{
"id": "278cd20747014933ae03d0a113bdc9da5a3c7ff3e51e30e4d3cef31eca17b7c3",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686162559,
"kind": 1,
"tags": [
[
"e",
"fa02b951f7d42f12ecb1d08d8129fee00ff24850ac6e199295db5844f5cb757f",
"",
"root"
],
[
"e",
"300de4ac2470577bef83214d175a742225e7d7cea468f57a7a07c5af75fda516",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "š
Original date posted:2021-02-28\nš Original message:Miners still can generate invalid blocks as a result of SPV mining, and it\ncould be profitable to do \"bad block enhanced selfish mining\" to take\nadvantage of it.\n\n\nHard to analyze exactly what that looks like, but...\n\nE.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate\nto mine bad blocks would mean 1/4th of the time you could make 20% of the\nhashrate mine bad blocks, overall a \u003e 5% (series expansion) benefit. One\ncould analyze out that the lost hash rate for bad blocks only matters for\nthe first difficulty adjustment period you're doing this for too, as the\nhashrate drop will be accounted for -- but then a miner can switch back to\nmining valid chain, giving themselves a larger % of hashrate.\n\nSo it is still possible that an un-upgraded miner will fail part 3, and\nattempting to accommodate un-upgraded miners leads to some nasty\noscillating hashrate being optimal.\n\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Sun, Feb 28, 2021 at 11:52 AM Matt Corallo \u003clf-lists at mattcorallo.com\u003e\nwrote:\n\n\u003e Note further that mandatory signaling isn't \"just\" a flag day - unlike a\n\u003e Taproot flag day (where miners running Bitcoin\n\u003e Core unmodified today will not generate invalid blocks), a mandatory\n\u003e signaling flag day blatantly ignores goal (3) from\n\u003e my original post - it results in any miner who has not taken active action\n\u003e (and ensured every part of their often-large\n\u003e infrastructure has been correctly reconfigured) generating invalid blocks.\n\u003e\n\u003e As for \"Taproot\" took too long, hey, at least if its locked in people can\n\u003e just build things assuming it exists. Some\n\u003e already are, but once its clearly locked in, there's no reason to not\n\u003e continue other work at the same time.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:\n\u003e \u003e I agree with much of the logic presented by Matt here.\n\u003e \u003e\n\u003e \u003e BIP8 was intended to be simpler to agree on to maintain consensus, yet\n\u003e we find ourselves in a situation where a \"tiny\"\n\u003e \u003e parameter has the potential to cause great network disruption and\n\u003e confusion (rationality is not too useful a concept\n\u003e \u003e here given differing levels of sophistication and information). It is\n\u003e therefore much simpler and more likely to be\n\u003e \u003e universally understood by all network participants to just have a flag\n\u003e day. It is easier to communicate what users\n\u003e \u003e should do and when.\n\u003e \u003e\n\u003e \u003e This is ultimately not coercive to users because the upgrade for Taproot\n\u003e itself is provable and analyzable on its own,\n\u003e \u003e but activation parameters based on what % of economically relevant nodes\n\u003e are running an upgrade by a certain date are\n\u003e \u003e not. Selecting these sorts of complicated consensus parameters may\n\u003e ultimately present more opportunity for a cooptable\n\u003e \u003e consensus process than something more straightforward.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e That said, a few points strike me as worth delving into.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e 1) Con: Mandatory signalling is no different than a flag day. Mandatory\n\u003e signaling is effectively 2 flag days -- one for\n\u003e \u003e the signaling rule, 1 for the taproot type. The reason for the 2 week\n\u003e gap between flag day for signaling and flag day\n\u003e \u003e for taproot rules is, more or less, so that nodes who aren't taproot\n\u003e ready at the 1st flag day do not end up SPV mining\n\u003e \u003e (using standardness rules in mempool prevents them from mining an\n\u003e invalid block on top of a valid tip, but does not\n\u003e \u003e ensure the tip is valid).\n\u003e \u003e 2) Con: Releasing a flag day without releasing the LOT=true code leading\n\u003e up to that flag day means that clients would\n\u003e \u003e not be fully compatible with an early activation that could be proposed\n\u003e before the flag day is reached. E.g., LOT=true\n\u003e \u003e is a flag day that retains the possibility of being compatible with\n\u003e other BIP8 releases without changing software.\n\u003e \u003e 3) Pro: BIP-8 is partially in service of \"early activation\" and . I'm\n\u003e personally skeptical that early activation is/was\n\u003e \u003e ever a good idea. A fixed activation date may be largely superior for\n\u003e business purposes, software engineering schedules,\n\u003e \u003e etc. I think even with signaling BIP8, it would be possibly superior to\n\u003e activate rules at a fixed date (or a quantized\n\u003e \u003e set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).\n\u003e \u003e 4) Pro: part of the argument for BIP-8=false is that it is possible that\n\u003e the rule could not activate, if signaling does\n\u003e \u003e not occur, providing additional stopgap against dev collusion and bugs.\n\u003e But BIP-8 can activate immediately (with start\n\u003e \u003e times being proposed 1 month after release?) so we don't have certainty\n\u003e around how much time there is for that secondary\n\u003e \u003e review process (read -- I think it isn't that valuable) and if there\n\u003e *is* a deadly bug discovered, we might want to\n\u003e \u003e hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule\n\u003e activates it enables more mining reward). So I\n\u003e \u003e think that it's a healthier mindset to release a with definite deadline\n\u003e and not rule out having to do a hard fork if\n\u003e \u003e there is a grave issue (we shouldn't ever release a SF if we think this\n\u003e is at all likely, mind you).\n\u003e \u003e 5) Con: It's already taken so long for taproot, the schedule around\n\u003e taproot was based on the idea it could early\n\u003e \u003e activate, 2022 is now too far away. I don't know how to defray this\n\u003e other than, if your preferred idea is 1 year flag\n\u003e \u003e day, to do that via LOT=true so that taproot can still have early\n\u003e activation if desired.\n\u003e \u003e\n\u003e \u003e Overall I agree with the point that all the contention around LOT, makes\n\u003e a flag day look not so bad. And something\n\u003e \u003e closer to a flag day might not be so bad either for future forks as well.\n\u003e \u003e\n\u003e \u003e However, I think given the appetite for early activation, if a flag day\n\u003e is desired I think LOT=true is the best option\n\u003e \u003e at this time as it allows our flag day to remain compatible with such an\n\u003e early activation.\n\u003e \u003e\n\u003e \u003e I think we can also clearly communicate that LOT=true for Taproot is not\n\u003e a precedent setting occurence for any future\n\u003e \u003e forks (hold me accountable to not using this as precedent this should I\n\u003e ever advocate for a SF with similar release\n\u003e \u003e parameters).\n\u003e \u003e\n\u003e \u003e\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210228/df85cf85/attachment-0001.html\u003e",
"sig": "aa5109e3923ca5362c84f11ee8773f0e93042985fa7ddbba1c21a2955168c664a5c45d1047ce95a10a3c6455adcd6d47eedf7275234f9e878385bd84097cc677"
}