Chris Acheson [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-14 📝 Original message:Speaking as one of the ...
📅 Original date posted:2017-04-14
📝 Original message:Speaking as one of the BIP148 agitators:
> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.
I'm assuming that you're referring to the flag date "segwit is on now"
approach. This is more dangerous than the orphaning approach that BIP148
uses.
If we orphan non-signalling blocks on the flag date and don't have
majority hash power supporting us, there will be a chain split on the
flag day. We expect this to happen, we plan for it, and we employ
strategies to mitigate any damage. The bulk of the economy has
coordinated around this event happening. We even had the opportunity to
pull the plug before the flag date if things were looking too grim.
After the dust settles, 100% of the miners are guaranteed to have
upgraded, assuming they didn't choose to forgo 2+ weeks of income. Any
further chain splits would have to be the result of deliberate action by
51%+ of the mining power.
If we just have segwit activate on the flag date without orphaning the
blocks of non-segwit miners, we set ourselves up for a chain split at
some unknown time in the future. Without majority hash power on our
side, as soon as someone mines a segwit-invalid transaction, the chain
will split, with upgraded nodes and miners on one side, and non-upgraded
nodes and miners on the other side. The segwit-invalid transaction
doesn't even need to come from someone with their own mining equipment.
Open a short on BTC, rent some hash power, profit.
Since we don't know when this attack will occur, we won't be organized
and ready for it. It's also easy for both miners and users to get
complacent about it and fail to upgrade. The damage will be far worse
than if we had used the orphaning approach.
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test. To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
Punitive action against miners is not the point of BIP148, it's an
unavoidable side-effect of making the UASF less disruptive for the users
of Bitcoin. Minimizing disruption for users must take priority over
minimizing disruption for miners. Given the intensity of this dispute
and the bad faith of certain actors, some schadenfreude is bound to
occur. Don't let that distract you from the actual reasons that BIP148
is designed the way it is.
> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.
I respect this perspective, and I agree with it to a certain extent.
However, continuing to wait has costs. I do not believe we have the
luxury of continuing to wait for a couple more years. In doing so it's
entirely possible that we may damage our reputation for stability and
integrity rather than build on it.
We have a window of opportunity with BIP148, and it would be a waste not
to act on it. In the event that we still lack sufficient support by
July, we can abandon the project, and make plans for how best to proceed
from there.
Published at
2023-06-07 18:00:11Event JSON
{
"id": "ec93fea151bd1e36793b5a8d59d7f69cb67daf74276bee5fce8a24964066c508",
"pubkey": "06e56f9c048be33afaaac95b4e253cc6da954f51bdfa9a30eaf7ddb147c1de98",
"created_at": 1686160811,
"kind": 1,
"tags": [
[
"e",
"5d1e64c970da07b0178aa4b0869114a6c0b54023e99bc79f83d180601afc646b",
"",
"root"
],
[
"e",
"fbd01d4b408ad41ff9aaf49edd30c4c64950b1beb69c6de8fff62cb6f6aa43ad",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-04-14\n📝 Original message:Speaking as one of the BIP148 agitators:\n\n\u003e There have been some other UASF proposals that avoid the forced\n\u003e disruption-- by just defining a new witness bit and allowing\n\u003e non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I\n\u003e think they are vastly superior. They would be slower to deploy, but I\n\u003e do not think that is a flaw.\n\nI'm assuming that you're referring to the flag date \"segwit is on now\"\napproach. This is more dangerous than the orphaning approach that BIP148\nuses.\n\nIf we orphan non-signalling blocks on the flag date and don't have\nmajority hash power supporting us, there will be a chain split on the\nflag day. We expect this to happen, we plan for it, and we employ\nstrategies to mitigate any damage. The bulk of the economy has\ncoordinated around this event happening. We even had the opportunity to\npull the plug before the flag date if things were looking too grim.\n\nAfter the dust settles, 100% of the miners are guaranteed to have\nupgraded, assuming they didn't choose to forgo 2+ weeks of income. Any\nfurther chain splits would have to be the result of deliberate action by\n51%+ of the mining power.\n\nIf we just have segwit activate on the flag date without orphaning the\nblocks of non-segwit miners, we set ourselves up for a chain split at\nsome unknown time in the future. Without majority hash power on our\nside, as soon as someone mines a segwit-invalid transaction, the chain\nwill split, with upgraded nodes and miners on one side, and non-upgraded\nnodes and miners on the other side. The segwit-invalid transaction\ndoesn't even need to come from someone with their own mining equipment.\nOpen a short on BTC, rent some hash power, profit.\n\nSince we don't know when this attack will occur, we won't be organized\nand ready for it. It's also easy for both miners and users to get\ncomplacent about it and fail to upgrade. The damage will be far worse\nthan if we had used the orphaning approach.\n\n\u003e \"First do no harm.\" We should use the least disruptive mechanisms\n\u003e available, and the BIP148 proposal does not meet that test. To hear\n\u003e some people-- non-developers on reddit and such-- a few even see the\n\u003e forced orphaning of 148 as a virtue, that it's punitive for\n\u003e misbehaving miners. I could not not disagree with that perspective any\n\u003e more strongly.\n\nPunitive action against miners is not the point of BIP148, it's an\nunavoidable side-effect of making the UASF less disruptive for the users\nof Bitcoin. Minimizing disruption for users must take priority over\nminimizing disruption for miners. Given the intensity of this dispute\nand the bad faith of certain actors, some schadenfreude is bound to\noccur. Don't let that distract you from the actual reasons that BIP148\nis designed the way it is.\n\n\u003e We should have patience. Bitcoin is a system that should last for all\n\u003e ages and power mankind for a long time-- ten years from now a couple\n\u003e years of dispute will seem like nothing. But the reputation we earn\n\u003e for stability and integrity, for being a system of money people can\n\u003e count on will mean everything.\n\nI respect this perspective, and I agree with it to a certain extent.\nHowever, continuing to wait has costs. I do not believe we have the\nluxury of continuing to wait for a couple more years. In doing so it's\nentirely possible that we may damage our reputation for stability and\nintegrity rather than build on it.\n\nWe have a window of opportunity with BIP148, and it would be a waste not\nto act on it. In the event that we still lack sufficient support by\nJuly, we can abandon the project, and make plans for how best to proceed\nfrom there.",
"sig": "6867664a75939ca3a41f8fb8b9667f800e6ab0f00b33c6cbf2b79766cffd1e9148d3f7dfe5dc78e624ac41ab8815fe0d2bda29d68c24ff4904685b1033285de5"
}