đź“… Original date posted:2021-06-27
đź“ť Original message:If different users want different incompatible things (enough on each
side), there's no way to avoid the split. We shouldn't try to avoid
such a split.
Users decide the rules, not miners nor developers.
On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Ultimately there is only one answer to this question. Get majority hash power support.
>
> Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
>
> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
>
> Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
>
> e
>
> > On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
> >
> > For some definitions of “block”.
> >
> > Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
> >
> > Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
> >
> > e
> >
> >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
> >> still slow it down.
> >>
> >> It also already has the trinary state you seem to be describing (although
> >> perhaps this could be better documented in the BIP): users who oppose the
> >> softfork can and should treat the successful signal (whether MASF or UASF) as
> >> invalid, thereby ensuring they do not follow a chain with the rules in force.
> >>
> >> No additional bit is needed, as softforks are coordinated between users, NOT
> >> miners (who have no particular say in them, aside from their role as also
> >> being users). The miner involvement is only out of necessity (to set the bit
> >> in the header, which users coordinate with) and potentially to accelerate
> >> activation by protecting upgrade-lagging users.
> >>
> >> Luke
> >>
> >>
> >>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
> >>> Given the recent controversy over upgrade mechanisms for the
> >>> non-controversial taproot upgrade, I have been thinking about ways to solve
> >>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
> >>> make the point that lazy miners failing to upgrade in a timely manner slow
> >>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> >>> proponents make the point that LOT=true can lead to undesirable forks that
> >>> might cause a lot of chaos. I believe both points are essentially correct
> >>> and have created a proposal
> >>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
> >>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
> >>>
> >>> The proposal uses trinary version signaling rather than binary signaling.
> >>> For any particular prospective soft fork upgrade, this allows for three
> >>> signaling states:
> >>>
> >>> * Actively support the change.
> >>> * Actively oppose the change.
> >>> * Not signaling (neither support or oppose). This is the default state.
> >>>
> >>> Using this additional information, we can release non-contentious upgrades
> >>> much quicker (with a much lower percent of miners signaling support). For
> >>> contentious upgrades, miners who oppose the change are incentivized to
> >>> update their software to a version that can actively signal opposition to
> >>> the change. The more opposition there is, the higher the threshold
> >>> necessary to lock in the upgrade. With the parameters I currently
> >>> recommended in the proposal, this chart shows how much support signaling
> >>> would be necessary given a particular amount of active opposition
> >>> signaling:
> >>>
> >>> [image: thresholdChart.png]
> >>> If literally no one signals opposition, a 60% threshold should be
> >>> relatively safe because it is a supermajority amount that is unlikely to
> >>> change significantly very quickly (ie if 60% of miners support the change
> >>> today, its unlikely that less than a majority of miners would support the
> >>> change a year or two from now), and if no one is signaling opposition,
> >>> chances are that the vast majority of the other 40% would also eventually
> >>> signal support.
> >>>
> >>> This both gives an incentive for "lazy" miners to upgrade if they actually
> >>> oppose the change while at the same time allowing these lazy miners to
> >>> remain lazy without slowing down the soft fork activation much.
> >>>
> >>> I think now is the right time to discuss new soft fork upgrade mechanisms,
> >>> when there are no pressing soft fork upgrades ready to deploy. Waiting
> >>> until we need to deploy a soft fork to discuss this will only delay things
> >>> and cause contention again like it did with taproot.
> >>>
> >>> I'm very curious to know what people think of this mechanism. I would
> >>> appreciate any comments here, or written as github issues on the proposal
> >>> repo itself.
> >>>
> >>> Thanks,
> >>> BT
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> 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
Jorge TimĂłn [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 22:55:26
in reply to nevent1q…vvzx
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 22:55:26Event JSON
{
"id": "e5c10e75d85ed24675166b04c8c844a409959112bc6a1a0b7edc9e3f936edd58",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686178526,
"kind": 1,
"tags": [
[
"e",
"5797d0294435e51d4826adffbf11af7c30760fc78d83446f2f227fe2888bc6d8",
"",
"root"
],
[
"e",
"c8379456a6ec8b43acf81d447e2d58c127d011bce246e48b651190c08434571b",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2021-06-27\n📝 Original message:If different users want different incompatible things (enough on each\nside), there's no way to avoid the split. We shouldn't try to avoid\nsuch a split.\nUsers decide the rules, not miners nor developers.\n\nOn Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Ultimately there is only one answer to this question. Get majority hash power support.\n\u003e\n\u003e Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.\n\u003e\n\u003e If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.\n\u003e\n\u003e Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.\n\u003e\n\u003e e\n\u003e\n\u003e \u003e On Jun 26, 2021, at 14:43, Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e For some definitions of “block”.\n\u003e \u003e\n\u003e \u003e Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.\n\u003e \u003e\n\u003e \u003e Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.\n\u003e \u003e\n\u003e \u003e e\n\u003e \u003e\n\u003e \u003e\u003e On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can\n\u003e \u003e\u003e still slow it down.\n\u003e \u003e\u003e\n\u003e \u003e\u003e It also already has the trinary state you seem to be describing (although\n\u003e \u003e\u003e perhaps this could be better documented in the BIP): users who oppose the\n\u003e \u003e\u003e softfork can and should treat the successful signal (whether MASF or UASF) as\n\u003e \u003e\u003e invalid, thereby ensuring they do not follow a chain with the rules in force.\n\u003e \u003e\u003e\n\u003e \u003e\u003e No additional bit is needed, as softforks are coordinated between users, NOT\n\u003e \u003e\u003e miners (who have no particular say in them, aside from their role as also\n\u003e \u003e\u003e being users). The miner involvement is only out of necessity (to set the bit\n\u003e \u003e\u003e in the header, which users coordinate with) and potentially to accelerate\n\u003e \u003e\u003e activation by protecting upgrade-lagging users.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Luke\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e\u003e On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:\n\u003e \u003e\u003e\u003e Given the recent controversy over upgrade mechanisms for the\n\u003e \u003e\u003e\u003e non-controversial taproot upgrade, I have been thinking about ways to solve\n\u003e \u003e\u003e\u003e the problems that both sides brought up. In short, BIP8 LOT=true proponents\n\u003e \u003e\u003e\u003e make the point that lazy miners failing to upgrade in a timely manner slow\n\u003e \u003e\u003e\u003e down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false\n\u003e \u003e\u003e\u003e proponents make the point that LOT=true can lead to undesirable forks that\n\u003e \u003e\u003e\u003e might cause a lot of chaos. I believe both points are essentially correct\n\u003e \u003e\u003e\u003e and have created a proposal\n\u003e \u003e\u003e\u003e \u003chttps://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b\n\u003e \u003e\u003e\u003e ip-trinary-version-bits.md\u003e for soft fork upgrades that solve both problems.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e The proposal uses trinary version signaling rather than binary signaling.\n\u003e \u003e\u003e\u003e For any particular prospective soft fork upgrade, this allows for three\n\u003e \u003e\u003e\u003e signaling states:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e * Actively support the change.\n\u003e \u003e\u003e\u003e * Actively oppose the change.\n\u003e \u003e\u003e\u003e * Not signaling (neither support or oppose). This is the default state.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Using this additional information, we can release non-contentious upgrades\n\u003e \u003e\u003e\u003e much quicker (with a much lower percent of miners signaling support). For\n\u003e \u003e\u003e\u003e contentious upgrades, miners who oppose the change are incentivized to\n\u003e \u003e\u003e\u003e update their software to a version that can actively signal opposition to\n\u003e \u003e\u003e\u003e the change. The more opposition there is, the higher the threshold\n\u003e \u003e\u003e\u003e necessary to lock in the upgrade. With the parameters I currently\n\u003e \u003e\u003e\u003e recommended in the proposal, this chart shows how much support signaling\n\u003e \u003e\u003e\u003e would be necessary given a particular amount of active opposition\n\u003e \u003e\u003e\u003e signaling:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e [image: thresholdChart.png]\n\u003e \u003e\u003e\u003e If literally no one signals opposition, a 60% threshold should be\n\u003e \u003e\u003e\u003e relatively safe because it is a supermajority amount that is unlikely to\n\u003e \u003e\u003e\u003e change significantly very quickly (ie if 60% of miners support the change\n\u003e \u003e\u003e\u003e today, its unlikely that less than a majority of miners would support the\n\u003e \u003e\u003e\u003e change a year or two from now), and if no one is signaling opposition,\n\u003e \u003e\u003e\u003e chances are that the vast majority of the other 40% would also eventually\n\u003e \u003e\u003e\u003e signal support.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e This both gives an incentive for \"lazy\" miners to upgrade if they actually\n\u003e \u003e\u003e\u003e oppose the change while at the same time allowing these lazy miners to\n\u003e \u003e\u003e\u003e remain lazy without slowing down the soft fork activation much.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e I think now is the right time to discuss new soft fork upgrade mechanisms,\n\u003e \u003e\u003e\u003e when there are no pressing soft fork upgrades ready to deploy. Waiting\n\u003e \u003e\u003e\u003e until we need to deploy a soft fork to discuss this will only delay things\n\u003e \u003e\u003e\u003e and cause contention again like it did with taproot.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e I'm very curious to know what people think of this mechanism. I would\n\u003e \u003e\u003e\u003e appreciate any comments here, or written as github issues on the proposal\n\u003e \u003e\u003e\u003e repo itself.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Thanks,\n\u003e \u003e\u003e\u003e BT\n\u003e \u003e\u003e\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "d97fa34c6ae062f3ae9078c303c52f9ac194a740ec815377d77dc22ac0ca14a91797b1b488be15d79b67790e18c4118f48f682dc92aa63a7f0ccf66b01f75364"
}