Matt Corallo [ARCHIVE] on Nostr: đź“… Original date posted:2021-02-28 đź“ť Original message:Glad you asked! Yes, your ...
đź“… Original date posted:2021-02-28
đź“ť Original message: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 at 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-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>;
>> >
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
đź“ť Original message: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 at 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-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>;
>> >
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev