{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-07\n📝 Original message:On Tue, Sep 29, 2015 at 06:31:28PM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e There is no consensus on using a soft fork to deploy this feature. It will\n\u003e \u003e result in the same problems as all the other soft forks - SPV wallets will\n\u003e \u003e become less reliable during the rollout period. I am against that, as it's\n\u003e \u003e entirely avoidable.\n\u003e \u003e Make it a hard fork and my objection will be dropped.\n\u003e I'm surprised to see this response-- [...]\n\u003e I am having a little difficulty making sense of this complaint. [...]\n\nI think I finally understand this objection.\n\nFor a hard fork, activated by a majority of nodes/hashpower upgrading\nto a new bitcoin release, the behaviour is:\n\n - upgraded bitcoin nodes: everything works fine\n\n - non-upgraded bitcoin nodes: total breakage. there will be a push\n   alert telling you to upgrade. anyone who doesn't will think they're\n   tracking \"bitcoin\" but will actually be tracking a new \"bitcoin-old\"\n   altcoin. most non-upgraded miners will presumably realise they're\n   wasting hashpower and stop doing this pretty quick; and remaining\n   miners will only create blocks very slowly due to sudden reduced\n   hashpower, without possibility of difficulty adjustment. users who\n   don't uprade will try to do transactions, but won't see them confirm\n   for hours or days due to lack of hashpower.\n\n - SPV nodes: they track the upgraded majority, everything works fine\n   even if they don't upgrade\n\nFor a soft fork, again activated by the majority of upgraded hashpower,\nthe behaviour is:\n\n - upgraded bitcoin nodes: everything works fine\n\n - non-upgraded bitcoin miners willing to mine newly unacceptable txs:\n   may produce orphaned blocks; may be able to be forced into producing\n   blocks that will be orphaned\n\n - other non-upgraded bitcoin nodes: everything works fine\n\n - SPV nodes: partial breakage -- may track invalid blocks for 1-2\n   confirmations until the set of \"non-upgraded bitcoin miners willing\n   to produce newly unacceptable txs\" becomes vanishingly few.\n\nIn the hard fork case, all non-upgraded nodes get a DoS attack, but\naren't likey to be hit by doublespends. That's inconvenient, but it's\nnot too bad.\n\nIn the soft fork case, if there's likely to be old nodes mining\npreviously invalid transactions, SPV clients become very unreliable,\nto the point of possibly seeing semi-regular double-spends with 1 or\n2 confirmation, until miners that aren't paying attention notice their\nblocks are getting orphaned and upgrade. That is pretty bad IMHO; and\nthere are a lot more *people* running SPV clients than bitcoin nodes,\nso its impact is potentially worse in both ways.\n\nComparing generic hard forks versus generic soft forks, the above says\nto me that a hard fork would be less harmful to users in general, and\nthus a better approach.\n\n*But* a soft fork that only forbids transactions that would previously\nnot have been mined anyway should be the best of both worlds, as it\nautomatically reduces the liklihood of old miners building newly invalid\nblocks to a vanishingly small probability; which means that upgraded\nbitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*\ncontinuing to work fine during the upgrade.\n\nAFAICS, that's what BIP65 achieves, as will similar OP_NOP* replacements\nlike BIP112.\n\nBut that only applies to a subset of potential soft forks, not every\nsoft fork.\n\nMaybe a good way to think about it is something like this.  Consensus\n(IsValid) is always less restrictive than (default) policy (previously\nIsStandard, not sure how to summarise it now, maybe it's just OP_NOP\nredefinition?).  So choosing a new consensus rule will be one of:\n\n  * even less restrictive than consensus (hard fork)\n\n  * more restrictive than consensus, but less restrictive than policy\n    (safe soft fork)\n\n  * more restrictive than IsStandard etc (damaging soft fork)\n\nHmm, in particular, following this line of thinking it's not clear to\nme that BIP68 is actually less restrictive than current policy? At\nleast, I can't see anything that prevents txs with nSequence set to\nsomething other than 0 or ~0 from being relayed?\n\nIf it's not, and nodes currently happily mine and relay transactions\nwith nSequence set without caring what it's set to, doesn't this mean\nBIP68 is of the \"damaging soft fork\" variety? That is, if it activated\nas a soft-fork with a majority of miners using it, but a minority of ~5%\nnot upgraded, then\n\n - someone could construct an tx with nSequence set to sometime in\n   the future, but not using OP_CSV\n\n - this tx would get relayed by old nodes (but not upgraded nodes\n   due to CheckLockTime)\n\n - non-upgraded miners would mine it into a block immediately, which\n   would then get orphaned by majority hashpower\n\n - before it got orphaned, non-upgraded nodes and SPV clients would\n   be misled and vulnerable to double spend attacks of txs with 0, 1 or\n   maybe 2 confirmations\n\n(BIP65 with OP_CLTV and BIP112 with OP_CSV don't have that problem as\nthey both redefine a non-standard opcode and would not get relayed or\nmined by old, non-upgraded nodes, and are thus \"safe soft forks\" per\nabove terminology. This is just BIP68)\n\nCan anyone confirm or refute the above?\n\nCheers,\naj"}