< luke-jr>
gmaxwell: BIP148's patch is only larger for safety and unit tests. it's much smaller than BIP91 without those.
< luke-jr>
given the short time period and risk of splitting up enforcement too much, I currently favour just deployment of BIP148 as-is. not perfect, but I think it's the least-risky all things considered
< gmaxwell>
luke-jr: well it does things like preferential peering, for example.
< luke-jr>
right, that's what I mean (partly)
< luke-jr>
fortunately, not ALL users need that, only some
< luke-jr>
the banning-old-nodes part is probably a bigger deal, but the same applies there
< gmaxwell>
as-is has the now-we-have-three-forks problem
< luke-jr>
essentially it's uasfsegwit 0.3 vs 1.0
< luke-jr>
gmaxwell: less likely than if 30% run BIP148-adapted-to-BIP91, 30% run BIP148-as-is, and 40% run non-BIP148
< luke-jr>
no?
< luke-jr>
at least if it's simply BIP148 or non-BIP148, *users* will be on one or the other
< gmaxwell>
luke-jr: no, because presumably there are foolish people running btc1.
< luke-jr>
not that many?
< gmaxwell>
no, but we can't tell for sure.
< luke-jr>
seems the binary choice (plus btc1) is only *at worst* equivalent to the trinary choice, and at best, an improvement
< luke-jr>
too many people disagree with the adjusted-BIP148 it seems, to reduce to a binary choice there
< luke-jr>
am I missing something still?
< praxeology>
gmaxwell: what do you want to do? just stick w/ the current release?
< btcdrak>
If pools have direct connected to eachother and are also on FIBRE, isnt that enough to mitigate the problems without trying to deploy something in <24 hours?
< praxeology>
btcdrak: the worst case scenario is that someone will make a non-segwit signalling block (very likely) and then half of the miners will accept it (not actually enforcing BIP 91) and the other half will reject it
< praxeology>
which would then potentially result in the longest valid chain (as appearing to current bitcoin core clients) to swap back and forth between the chain w/ the non-segwit-signal chain and the all segwit-signal chain
< btcdrak>
I've asked several pools and based on what they say at least, much more than 51% of the hashrate is running BIP91 enforcement code either btc1 or segsignal. They understand they must enforce the rule.
< btcdrak>
I agree this situation is ideal. If BIP91 had the same activation date as BIP148 it could have piggypacked and there would be significant node enforcement. But in 24 hours, I dont see how we can make this better at all. Asking exchanges et al to run a quick untested patch (by Core's standards) for what doesnt seem like an emergency (at least to me), seems irresponsible.
< btcdrak>
s/is idea/isn't ideal/
< praxeology>
btcdrak: I agree that bitcoincore.org / etc people should definitely not ask people to run BIP 91 enforcing software, or even recommend it. They might just want to create a BIP 91 or 148 release just to satisfy demand
< luke-jr>
btcdrak: without enforcement, you lose full node security
< praxeology>
But for exchanges, established businesses etc, i think they should just stick to 0.14.2 for now... and then if there actually is a lasting split, then wait for replay attack prevention to be tested and released
< praxeology>
luke-jr: what do you mean you lose full node security?
< praxeology>
you are still fully verifying the money supply
< luke-jr>
praxeology: full node security means you enforce ALL the rules
< praxeology>
all of your own rules
< luke-jr>
anything less than all, is effectively nothing
< sipa>
luke-jr: i disagree with that
< praxeology>
BIP91 rules are not/never were my rules. I only heard about it yesterday when I was checking up on BIP 148 status
< sipa>
(especially if you're not doing anything based on low confirmation count)
< luke-jr>
praxeology: yet if you don't enforce it, you lose security
< praxeology>
luke-jr: only for low confirmation count, only over about the next 2 weeks, and only if there is a near 50% split on bip 91 enforcement
< luke-jr>
sipa: if you're trusting miners, that's pSPV, not full node. or do you mean something else?
< sipa>
luke-jr: yes, you're trusting them for some rules
< luke-jr>
how is some any different from all, practically speaking?
< praxeology>
One only need enforce rules that oneself cares about
< praxeology>
if others enforce more rules, it does not matter to you
< luke-jr>
praxeology: it does, because if the unenforced rule is violated, the entire block is invalid, even if you were personally okay with it
< praxeology>
its only a short term problem w/ orphaning blocks
< sipa>
luke-jr: maybe you're ok with spv security for incoming payments, but still want to help make sure miners cannot inflate the currency supply
< luke-jr>
hm
< morcos>
My general view is that the more we think the miners are going to properly enforce BIP91, the more we want to make a patch/release that does so
< morcos>
B/c that means the more sure we are that it is the actual rules
< morcos>
If we think there might be all kinds of shenanigans, maybe we just want to stay clear of these rushed consenus chicken games
< bitcoin-git>
[bitcoin] jamesob opened pull request #10903: Add configuration files for a Docker-based development environment (master...docker) https://github.com/bitcoin/bitcoin/pull/10903
< gmaxwell>
btcdrak: as morcos says, -- we think non SW signaling blocks will be orphaned... not everyone can stop transacting for most of the weekend... to avoid losses they need to either wait an unreasonable amount of confirmations or enforce the rules that (in their best estimation) the network will enforce.