📅 Original date posted:2017-02-26
📝 Original message:You've made many salient points, Shaolin, though I have a few questions:
1) How well does this model work under adversarial conditions? Fair point
about signaling not being reliable, though it seems more vague in terms of
safety given that you can't actually know what percentage of hashrate that
is /not/ signaling for the soft fork has taken the necessary precautions to
avoid mining an invalid block and potentially causing a hard fork. It's
probably safe to say that if a flag-day soft fork is activated, there will
be at least a few parties who will attempt to trigger a chain fork by
crafting transactions that are valid via non-fork rules but invalid via the
soft fork rules.
2) If the flag day soft fork is activated with only a minority of hashrate
support + safely opted-out hashrate, isn't it possible for the rest of
miners to coordinate orphaning any soft fork compatible blocks to kill the
soft fork chain? This would be a major difference from a miner-activated
soft fork, correct? Unless perhaps many miners colluded to signal soft fork
support while not actually supporting it...
3) In terms of complexity for mining pool operators, how well does this
model scale if there are N soft forks and the pool doesn't want to opt-in
to any of them? Couldn't this result in those pool operators having to run
not just one border node, but a multitude of "chained" border nodes if the
soft forks are spread across different software implementations?
It seems to me that this type of user-driven approach would preferably be
coupled with assurances from major Bitcoin wallets / exchanges / payment
processors that they will not honor coins from a chain fork that results
from invalid spends of outputs encumbered by soft fork rules. Though on the
other hand, I don't see such an assurance being possible given that
exchanges have an incentive to take the first mover advantage in listing a
new coin.
- Jameson
On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Some thoughts about the activation mechanism for soft forks. In the past
> we used IsSuperMajority and currently use BIP9 as soft fork activation
> methods, where a supermajority of hashrate triggers nodes to begin
> enforcing new rules. Hashrate based activation is convenient because it is
> the simplest and most straightforward process. While convenient there are a
> number limitations with this method.
>
> Firstly, it requires trusting the hash power will validate after
> activation. The BIP66 soft fork was a case where 95% of the hashrate was
> signaling readiness but in reality about half was not actually validating
> the upgraded rules and mined upon an invalid block by mistake[1].
>
> Secondly, miner signalling has a natural veto which allows a small
> percentage of hashrate to veto node activation of the upgrade for everyone.
> To date, soft forks have taken advantage of the relatively centralised
> mining landscape where there are relatively few mining pools building valid
> blocks; as we move towards more hashrate decentralization, it's likely that
> we will suffer more and more from "upgrade inertia" which will veto most
> upgrades.
>
> Upgrade inertia in inevitable for widely deployed software and can be seen
> for example, with Microsoft Windows. At the time of writing 5.72% of all
> Microsoft Windows installations are still running Windows XP, despite
> mainstream support ending in 2009 and being superseded by 4 software
> generations, Vista, 7, 8 and 10.
>
> Thirdly, the signaling methodology is widely misinterpreted to mean the
> hash power is voting on a proposal and it seems difficult to correct this
> misunderstanding in the wider community. The hash powers' role is to select
> valid transactions, and to extend the blockchain with valid blocks. Fully
> validating economic nodes ensure that blocks are valid. Nodes therefore
> define validity according to the software they run, but miners decide what
> already valid transactions gets included in the block chain.
>
> As such, soft forks rules are actually always enforced by the nodes, not
> the miners. Miners of course can opt-out by simply not including
> transactions that use the new soft fork feature, but they cannot produce
> blocks that are invalid to the soft fork. The P2SH soft fork is a good
> example of this, where non-upgraded miners would see P2SH as spendable
> without a signature and consider them valid. If such an transaction were to
> be included in a block, the block would be invalid and the miner would lose
> the block reward and fees.
>
> So-called "censorship" soft forks do not require nodes to opt in, because
> >51% of the hash power already have the ability to orphan blocks that
> contain transactions they have blacklisted. Since this is not a change in
> validity, nodes will accept the censored block chain automatically.
>
> The fourth problem with supermajority hash power signaling is it draws
> unnecessary attention to miners which can become unnecessarily political.
> Already misunderstood as a vote, miners may feel pressure to "make a
> decision" on behalf of the community: who is and isn't signalling becomes a
> huge public focus and may put pressures onto miners they are unprepared
> for. Some miners may not be in a position to upgrade, or may prefer not to
> participate in the soft fork which is their right. However, that miner may
> now become a lone reason that vetoes activation for everyone, where the
> soft fork is an opt-in feature! This situation seems to be against the
> voluntary nature of the Bitcoin system where participation at all levels is
> voluntary and kept honest by well balanced incentives.
>
> Since miners already have the protocol level right to select whatever
> transaction they prefer (and not mine those they don't), it would be better
> if a miner could chose to not participate in triggering activation of
> something they won't use, but, without being a veto to the process (and all
> the ire they may have to experience as a consequence).
>
> The alternative discussed here is "flag day activation" where nodes begin
> enforcement at a predetermined time in the future. This method needs a
> longer lead time than a hash power based activation trigger, but offers a
> number of advantages and perhaps provides a better tradeoff.
>
> Soft forks are still entirely optional to use post activation. For
> example, with P2SH, many participants in the Bitcoin ecosystem still do not
> use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time
> of writing. Miners are free to not mine P2SH transactions, however, the
> incentives are such that miners should still validate transactions so they
> don't accidentally include invalid transactions and cause their block to be
> rejected. As an additional safety measure for well designed soft forks,
> relay policy rules prevent non-standard and invalid transactions from being
> relayed and mined by default; a miner would have to purposefully mine an
> invalid transaction, which is against their own economic interest.
>
> Since the incentives of the Bitcoin system rely on self validation,
> economic nodes (miners and users) should always remain safe by ensuring
> their nodes either validate the current rules, or, they can place their
> network behind a full node that will filter out invalid transactions and
> blocks at the edge of their network (so called firewall or border nodes).
>
> A user activated soft fork is permissive. Miners do not have to produce
> new version blocks and non-upgraded miners' blocks will not be orphaned as
> was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66,
> BIP65-CLTV) which made it a compulsory upgrade for miners.
>
> BIP9 "versionbits" soft fork activation method is also permissive in so
> far as non-upgraded miners are not forced to upgrade after activation
> because their blocks wont be orphaned. A recent case was the "CSV" soft
> fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork
> allows non-upgraded miners to continue mining so long as they didn't
> produce invalid blocks.
>
> Miners always retain discretion on which transactions to mine. However,
> regardless of whether they actively include transactions using the new soft
> fork feature, or not, the incentive for hash power to upgrade in order to
> validate is strong: if they do not, they could be vulnerable to a rogue
> miner willing to waste 12.5BTC to create an invalid block, which may cause
> non-validating miners to build on an invalid chain similar to the BIP66
> incident. Validation has always had a strong requirement.
>
> A user activated soft fork is win-win because it adds an option that some
> people want that does not detract from other peoples' enjoyment. Even if
> only 10% of users ever wanted a feature, so long as the benefit outweighed
> the technical risks, it would not be rational to deny others the ability to
> opt-in.
>
> My suggestion is to have the best of both worlds. Since a user activated
> soft fork needs a relatively long lead time before activation, we can
> combine with BIP9 to give the option of a faster hash power coordinated
> activation or activation by flag day, whichever is the sooner. In both
> cases, we can leverage the warning systems in BIP9. The change is
> relatively simple, adding an activation-time parameter which will
> transition the BIP9 state to LOCKED_IN before the end of the BIP9
> deployment timeout.
>
> You can find the proposal here https://gist.github.com/shaolinfry/
> 0f7d1fd22743bb966da0c0b1682ea2ab
>
> References:
>
> [1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining
> [2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=
> 1472043312917&to=1488030912918
>
> _______________________________________________
> 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/20170226/82166427/attachment-0001.html>;
Jameson Lopp [ARCHIVE] /
npub1gh…akqmn
2023-06-07 17:56:48
in reply to nevent1q…flpn
Author Public Key
npub1ghgfr3aumwuxwnwghywxpaejxpf6k9pjcnyg9lfdnztlu5pwa0ksyakqmnPublished at
2023-06-07 17:56:48Event JSON
{
"id": "34c35f05960e14611dde44b0479974d7a5f9eb6489ce3cb646849a9fa6db4e57",
"pubkey": "45d091c7bcdbb8674dc8b91c60f7323053ab1432c4c882fd2d9897fe502eebed",
"created_at": 1686160608,
"kind": 1,
"tags": [
[
"e",
"3c71ca2d31e8afb8fd870a2daa236b9f0d6f296cb0d32dbc6599f82d75f0daa2",
"",
"root"
],
[
"e",
"f35f38dde1ea450f33fbc8e4190f67cf0ed3a80749c121f942675f77ed791d3a",
"",
"reply"
],
[
"p",
"512c64351a85e9323c34af13b4dfcf320615bacb09132ae6da9ce671b7942825"
]
],
"content": "📅 Original date posted:2017-02-26\n📝 Original message:You've made many salient points, Shaolin, though I have a few questions:\n\n1) How well does this model work under adversarial conditions? Fair point\nabout signaling not being reliable, though it seems more vague in terms of\nsafety given that you can't actually know what percentage of hashrate that\nis /not/ signaling for the soft fork has taken the necessary precautions to\navoid mining an invalid block and potentially causing a hard fork. It's\nprobably safe to say that if a flag-day soft fork is activated, there will\nbe at least a few parties who will attempt to trigger a chain fork by\ncrafting transactions that are valid via non-fork rules but invalid via the\nsoft fork rules.\n\n2) If the flag day soft fork is activated with only a minority of hashrate\nsupport + safely opted-out hashrate, isn't it possible for the rest of\nminers to coordinate orphaning any soft fork compatible blocks to kill the\nsoft fork chain? This would be a major difference from a miner-activated\nsoft fork, correct? Unless perhaps many miners colluded to signal soft fork\nsupport while not actually supporting it...\n\n3) In terms of complexity for mining pool operators, how well does this\nmodel scale if there are N soft forks and the pool doesn't want to opt-in\nto any of them? Couldn't this result in those pool operators having to run\nnot just one border node, but a multitude of \"chained\" border nodes if the\nsoft forks are spread across different software implementations?\n\nIt seems to me that this type of user-driven approach would preferably be\ncoupled with assurances from major Bitcoin wallets / exchanges / payment\nprocessors that they will not honor coins from a chain fork that results\nfrom invalid spends of outputs encumbered by soft fork rules. Though on the\nother hand, I don't see such an assurance being possible given that\nexchanges have an incentive to take the first mover advantage in listing a\nnew coin.\n\n- Jameson\n\nOn Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Some thoughts about the activation mechanism for soft forks. In the past\n\u003e we used IsSuperMajority and currently use BIP9 as soft fork activation\n\u003e methods, where a supermajority of hashrate triggers nodes to begin\n\u003e enforcing new rules. Hashrate based activation is convenient because it is\n\u003e the simplest and most straightforward process. While convenient there are a\n\u003e number limitations with this method.\n\u003e\n\u003e Firstly, it requires trusting the hash power will validate after\n\u003e activation. The BIP66 soft fork was a case where 95% of the hashrate was\n\u003e signaling readiness but in reality about half was not actually validating\n\u003e the upgraded rules and mined upon an invalid block by mistake[1].\n\u003e\n\u003e Secondly, miner signalling has a natural veto which allows a small\n\u003e percentage of hashrate to veto node activation of the upgrade for everyone.\n\u003e To date, soft forks have taken advantage of the relatively centralised\n\u003e mining landscape where there are relatively few mining pools building valid\n\u003e blocks; as we move towards more hashrate decentralization, it's likely that\n\u003e we will suffer more and more from \"upgrade inertia\" which will veto most\n\u003e upgrades.\n\u003e\n\u003e Upgrade inertia in inevitable for widely deployed software and can be seen\n\u003e for example, with Microsoft Windows. At the time of writing 5.72% of all\n\u003e Microsoft Windows installations are still running Windows XP, despite\n\u003e mainstream support ending in 2009 and being superseded by 4 software\n\u003e generations, Vista, 7, 8 and 10.\n\u003e\n\u003e Thirdly, the signaling methodology is widely misinterpreted to mean the\n\u003e hash power is voting on a proposal and it seems difficult to correct this\n\u003e misunderstanding in the wider community. The hash powers' role is to select\n\u003e valid transactions, and to extend the blockchain with valid blocks. Fully\n\u003e validating economic nodes ensure that blocks are valid. Nodes therefore\n\u003e define validity according to the software they run, but miners decide what\n\u003e already valid transactions gets included in the block chain.\n\u003e\n\u003e As such, soft forks rules are actually always enforced by the nodes, not\n\u003e the miners. Miners of course can opt-out by simply not including\n\u003e transactions that use the new soft fork feature, but they cannot produce\n\u003e blocks that are invalid to the soft fork. The P2SH soft fork is a good\n\u003e example of this, where non-upgraded miners would see P2SH as spendable\n\u003e without a signature and consider them valid. If such an transaction were to\n\u003e be included in a block, the block would be invalid and the miner would lose\n\u003e the block reward and fees.\n\u003e\n\u003e So-called \"censorship\" soft forks do not require nodes to opt in, because\n\u003e \u003e51% of the hash power already have the ability to orphan blocks that\n\u003e contain transactions they have blacklisted. Since this is not a change in\n\u003e validity, nodes will accept the censored block chain automatically.\n\u003e\n\u003e The fourth problem with supermajority hash power signaling is it draws\n\u003e unnecessary attention to miners which can become unnecessarily political.\n\u003e Already misunderstood as a vote, miners may feel pressure to \"make a\n\u003e decision\" on behalf of the community: who is and isn't signalling becomes a\n\u003e huge public focus and may put pressures onto miners they are unprepared\n\u003e for. Some miners may not be in a position to upgrade, or may prefer not to\n\u003e participate in the soft fork which is their right. However, that miner may\n\u003e now become a lone reason that vetoes activation for everyone, where the\n\u003e soft fork is an opt-in feature! This situation seems to be against the\n\u003e voluntary nature of the Bitcoin system where participation at all levels is\n\u003e voluntary and kept honest by well balanced incentives.\n\u003e\n\u003e Since miners already have the protocol level right to select whatever\n\u003e transaction they prefer (and not mine those they don't), it would be better\n\u003e if a miner could chose to not participate in triggering activation of\n\u003e something they won't use, but, without being a veto to the process (and all\n\u003e the ire they may have to experience as a consequence).\n\u003e\n\u003e The alternative discussed here is \"flag day activation\" where nodes begin\n\u003e enforcement at a predetermined time in the future. This method needs a\n\u003e longer lead time than a hash power based activation trigger, but offers a\n\u003e number of advantages and perhaps provides a better tradeoff.\n\u003e\n\u003e Soft forks are still entirely optional to use post activation. For\n\u003e example, with P2SH, many participants in the Bitcoin ecosystem still do not\n\u003e use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time\n\u003e of writing. Miners are free to not mine P2SH transactions, however, the\n\u003e incentives are such that miners should still validate transactions so they\n\u003e don't accidentally include invalid transactions and cause their block to be\n\u003e rejected. As an additional safety measure for well designed soft forks,\n\u003e relay policy rules prevent non-standard and invalid transactions from being\n\u003e relayed and mined by default; a miner would have to purposefully mine an\n\u003e invalid transaction, which is against their own economic interest.\n\u003e\n\u003e Since the incentives of the Bitcoin system rely on self validation,\n\u003e economic nodes (miners and users) should always remain safe by ensuring\n\u003e their nodes either validate the current rules, or, they can place their\n\u003e network behind a full node that will filter out invalid transactions and\n\u003e blocks at the edge of their network (so called firewall or border nodes).\n\u003e\n\u003e A user activated soft fork is permissive. Miners do not have to produce\n\u003e new version blocks and non-upgraded miners' blocks will not be orphaned as\n\u003e was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66,\n\u003e BIP65-CLTV) which made it a compulsory upgrade for miners.\n\u003e\n\u003e BIP9 \"versionbits\" soft fork activation method is also permissive in so\n\u003e far as non-upgraded miners are not forced to upgrade after activation\n\u003e because their blocks wont be orphaned. A recent case was the \"CSV\" soft\n\u003e fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork\n\u003e allows non-upgraded miners to continue mining so long as they didn't\n\u003e produce invalid blocks.\n\u003e\n\u003e Miners always retain discretion on which transactions to mine. However,\n\u003e regardless of whether they actively include transactions using the new soft\n\u003e fork feature, or not, the incentive for hash power to upgrade in order to\n\u003e validate is strong: if they do not, they could be vulnerable to a rogue\n\u003e miner willing to waste 12.5BTC to create an invalid block, which may cause\n\u003e non-validating miners to build on an invalid chain similar to the BIP66\n\u003e incident. Validation has always had a strong requirement.\n\u003e\n\u003e A user activated soft fork is win-win because it adds an option that some\n\u003e people want that does not detract from other peoples' enjoyment. Even if\n\u003e only 10% of users ever wanted a feature, so long as the benefit outweighed\n\u003e the technical risks, it would not be rational to deny others the ability to\n\u003e opt-in.\n\u003e\n\u003e My suggestion is to have the best of both worlds. Since a user activated\n\u003e soft fork needs a relatively long lead time before activation, we can\n\u003e combine with BIP9 to give the option of a faster hash power coordinated\n\u003e activation or activation by flag day, whichever is the sooner. In both\n\u003e cases, we can leverage the warning systems in BIP9. The change is\n\u003e relatively simple, adding an activation-time parameter which will\n\u003e transition the BIP9 state to LOCKED_IN before the end of the BIP9\n\u003e deployment timeout.\n\u003e\n\u003e You can find the proposal here https://gist.github.com/shaolinfry/\n\u003e 0f7d1fd22743bb966da0c0b1682ea2ab\n\u003e\n\u003e References:\n\u003e\n\u003e [1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining\n\u003e [2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=\n\u003e 1472043312917\u0026to=1488030912918\n\u003e\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\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170226/82166427/attachment-0001.html\u003e",
"sig": "fe6c357bfc22dd1767a08a5881438cf3549e4181a591f6f254c9575fac1b640982e8f03b30d2cbae3cdff367f6f946dd786a2ef458d6f4cf606a66148b2f5844"
}