rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2015-06-22 📝 Original message:On Mon, Jun 22, 2015 at 2:33 PM, Tier Nolan <tier.nolan at gmail.com> wrote: > The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than > the standard 1000. Given that the threshold is lower than is normal for > hard-forks, noise on the measurement could cause an activation even if less > than 75% of miners agree. It also means that the vote has to be sustained > for longer and inherently gives a longer notice period. > 9,000 of last 12,000 blocks is OK with me (I don't think scanning through the last 12,000 block headers every new block will cause performance problems, but I'd want to benchmark it to be absolutely sure). > Two weeks seems low for an upgrade warning. I guess there would be an > alert on the network. > Do old nodes detect an upgrade by version numbers? If that was headers > only, then they could detect that large blocks have activated. > Bitcoin Core will alert when automatically when 51% of blocks have a version it doesn't understand. It will also alert automatically if it detects a chain with more work that it doesn't consider valid for some reason. And 0.11 contains code that alerts if you're on a chain that is being mined really slowly. Have you considered a "fail" condition? For example, if 750 of the last > 1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the > miners. Alternatively, if the rule doesn't activate by 11th Jan 2017, then > it is disabled. > I like the fail-if-not-activated-by idea. Not so crazy about the vote idea (what if miners set bits 3 AND 4 ?). -- -- Gavin Andresen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/9cf73348/attachment.html>