{"type":"rich","version":"1.0","author_name":"npub12ykxgdg6sh5ny0p54ufmfh70xgrptwktpyfj4ek6nnn8rdu59qjscvwd8g","author_url":"https://nostr.ae/npub12ykxgdg6sh5ny0p54ufmfh70xgrptwktpyfj4ek6nnn8rdu59qjscvwd8g","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-04-06\n📝 Original message:After some thought I managed to simplify the original uaversionbits proposal introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment by the timeout. This seems to be the simplest form combining optional flag day activation with BIP9. This brings the best of both worlds allowing user activated soft forks that can be activated early by the hash power.\n\nSpecification: https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki\nPrevious discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html\n\n\u003cpre\u003e\nBIP: ?\nTitle: Version bits extension with guaranteed lock-in\nAuthor: Shaolin Fry \u003cshaolinfry at protonmail.ch\u003e\nComments-Summary: No comments yet.\nComments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????\nStatus: Draft\nType: Informational\nCreated: 2017-02-01\nLicense: BSD-3-Clause\nCC0-1.0\n\u003c/pre\u003e\n\n==Abstract==\n\nThis document specifies an extension to BIP9 that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called \"soft forks\").\n\n==Motivation==\n\nBIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate.\n\nThis specification provides a way to optionally guarantee lock-in at the end of the BIP9 timeout, and therefore activation.\n\n==Specification==\n\nThis specification adds a new per-chain deployment parameter to the existing BIP9 specification as follows:\n\n# The '''lockinontimeout''' boolean if set to true, will transition state to LOCKED_IN at timeout if not already ACTIVE.\n\n===State transitions===\n\n\u003cimg src=\"bip-uaversionbits/states.png\" align=\"middle\"\u003e\u003c/img\u003e\n\nThe state transition workflow is exactly the same as in BIP9 with an additional rule: During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeout''' is reached.\n\ncase STARTED:\n// BIP9 specification follows\nif (GetMedianTimePast(block.parent) \u003e= timeout) {\nreturn (fLockInOnTimeout == true) ? THRESHOLD_LOCKED_IN : THRESHOLD_FAILED\n}\nint count = 0;\nwalk = block;\nfor (i = 0; i \u003c 2016; i++) {\nwalk = walk.parent;\nif (walk.nVersion \u0026 0xE0000000 == 0x20000000 \u0026\u0026 (walk.nVersion \u003e\u003e bit) \u0026 1 == 1) {\ncount++;\n}\n}\nif (count \u003e= threshold) {\nreturn LOCKED_IN;\n}\nreturn STARTED;\n\n=== Reference implementation ===\n\nhttps://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits\n\n==Deployments==\n\nA living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]].\n\n==Copyright==\n\nThis document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/f7781921/attachment-0001.html\u003e"}