Gareth Williams [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-06 📝 Original message:What you're describing is ...
📅 Original date posted:2017-03-06
📝 Original message:What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with.
It is always possible for a majority of hashpower to censor transactions they disagree with. Users may view that as an attack, and can always respond with a POW hard fork.
Bitcoin only works if the majority of hashpower is not hostile to the users.
On 6 March 2017 9:29:35 PM AEDT, Edmund Edgar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>> User activated soft forks, or perhaps more accurately called
>'economically
>> forced soft forks' are a tool to use if the miners are in clear
>opposition
>> to the broader economy.
>
>I don't think they work for that, at least not for new features,
>because miners will presumably just head the whole thing off by
>orphaning the whole class of non-standard transactions that are the
>subject of the fork. In the SegWit case, they'd just orphan anything
>that looks like a SegWit transaction, valid or not. That way they
>don't need to worry about ending up on the wrong side of the upgrade,
>because no transaction affected by the proposed rule change will ever
>get into the longest chain. Rational node operators (particularly
>exchanges) will likely also adopt their stricter rule change, since
>they know any chain that breaks it will end up being orphaned, so you
>don't want to act on a payment that you see confirmed in it. So then
>you're back where you started, except that your soft-fork is now a
>de-facto hard-fork, because you have to undo the new, stricter rule
>that the miners introduced to head off your shenannigans.
>
>Where they're interesting is where you can do something meaningful by
>forcing some transactions through on a once-off basis. For example, if
>the Chinese government identified an address belonging to Uighur
>separatists and leaned on Chinese miners to prevent anything from that
>address confirming, it might be interesting for users to say, "If
>these utxos are not spent by block X, your block is invalid".
>
>They might also be interesting for feature upgrades in a world where
>mining is radically decentralized and upgrades are fighting against
>inertia rather than opposition, but sadly that's not the world we
>currently live in.
Published at
2023-06-07 17:57:04Event JSON
{
"id": "e4a91c8de1ab8762476167c77243c8e3abd5da13a3fd3ec8641e5f347935253e",
"pubkey": "959a9c23e3a17ee9df362d7f12c50fbdefd93d94208519d2110bc65e3e9ed411",
"created_at": 1686160624,
"kind": 1,
"tags": [
[
"e",
"884240603140ed27b03f27320d4379ba808b85a816007fd6f0068a3a767a99ca",
"",
"root"
],
[
"e",
"5ca6905c5742d7c912f3b45c253e1748420f783bd518f908d02c77def8058634",
"",
"reply"
],
[
"p",
"ec200970b5049a1e4c3051316531624de7bcd038fb1fdecd69ecad2851ca7d3c"
]
],
"content": "📅 Original date posted:2017-03-06\n📝 Original message:What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with.\n\nIt is always possible for a majority of hashpower to censor transactions they disagree with. Users may view that as an attack, and can always respond with a POW hard fork. \n\nBitcoin only works if the majority of hashpower is not hostile to the users.\n\n\nOn 6 March 2017 9:29:35 PM AEDT, Edmund Edgar via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eOn 6 March 2017 at 18:18, David Vorick via bitcoin-dev\n\u003e\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e User activated soft forks, or perhaps more accurately called\n\u003e'economically\n\u003e\u003e forced soft forks' are a tool to use if the miners are in clear\n\u003eopposition\n\u003e\u003e to the broader economy.\n\u003e\n\u003eI don't think they work for that, at least not for new features,\n\u003ebecause miners will presumably just head the whole thing off by\n\u003eorphaning the whole class of non-standard transactions that are the\n\u003esubject of the fork. In the SegWit case, they'd just orphan anything\n\u003ethat looks like a SegWit transaction, valid or not. That way they\n\u003edon't need to worry about ending up on the wrong side of the upgrade,\n\u003ebecause no transaction affected by the proposed rule change will ever\n\u003eget into the longest chain. Rational node operators (particularly\n\u003eexchanges) will likely also adopt their stricter rule change, since\n\u003ethey know any chain that breaks it will end up being orphaned, so you\n\u003edon't want to act on a payment that you see confirmed in it. So then\n\u003eyou're back where you started, except that your soft-fork is now a\n\u003ede-facto hard-fork, because you have to undo the new, stricter rule\n\u003ethat the miners introduced to head off your shenannigans.\n\u003e\n\u003eWhere they're interesting is where you can do something meaningful by\n\u003eforcing some transactions through on a once-off basis. For example, if\n\u003ethe Chinese government identified an address belonging to Uighur\n\u003eseparatists and leaned on Chinese miners to prevent anything from that\n\u003eaddress confirming, it might be interesting for users to say, \"If\n\u003ethese utxos are not spent by block X, your block is invalid\".\n\u003e\n\u003eThey might also be interesting for feature upgrades in a world where\n\u003emining is radically decentralized and upgrades are fighting against\n\u003einertia rather than opposition, but sadly that's not the world we\n\u003ecurrently live in.",
"sig": "112d5158b62d998cf9721fc0d0218d14db7f88f0834ac3693b0cb77b7d8ed109c277ba05e278b8628b62ab6b9f0cbce5dd0d9aa3f96ada6c18234aad132c4a2e"
}