< gmaxwell>
BIP-91 lock in is now guarenteed (short of a reorg...)
< gmaxwell>
So with BIP-91 lock in I am of the belief that BIP-148 (esp if modified to start enforcing at the same height coordinated by 91) is a pure marginal mitigation in risk for the network now.
< luke-jr>
would anyone object to an emergency 0.14.3 with BIP148 modified to activate at the same height as BIP91? the downside is that there's only 1-2 days for people to upgrade to it, so we'd need to forego RCs (although most of the code has been tested in the UASF repo) and probably release today or tomorrow..
< luke-jr>
BlueMatt: morcos ^
< luke-jr>
(note this would also help avoid the propagation/partitioning risk BIP91 currently has)
< gmaxwell>
I'd like to do something there, at a minimum we could put up a minimal patch.
< gmaxwell>
I believe that if turns out that there was significant false bit-4 signaling the harm minimizing outcome will still be to enforce bit1 signaling; also doing so will protect you from seeing the reorgs this enforcement will create; so it's protective in both ways.
< BlueMatt>
its two days
< BlueMatt>
I'd rather make sure the network has consistent(ish) network rules
< luke-jr>
why observe when we can make sure it does?
< BlueMatt>
it somewhat frightens me that the network doesnt due to 148 nodes, though I'm skeptical there are many of those behind businesses, more users who can/will pause their actions based on activation, and are at least aware enough to have decided to run 148
< BlueMatt>
uhh...we cant? you arent getting every business and user who uses their wallet to upgrade in 2.5 days
< sipa>
BlueMatt: it only needs them to update by end of august
< BlueMatt>
miners decided to take the risk, let them take it, and dont pull everyone into it
< BlueMatt>
sipa: i belive the suggestion was to enable it on the now-locked bip91 activation block
< luke-jr>
BlueMatt: we can drastically improve the situation
< BlueMatt>
im not convinced thats an improvement
< sipa>
that's just way too fast
< gmaxwell>
BlueMatt: consistent rules are out the window already, guarenteed.
< luke-jr>
back in ~45 min
< BlueMatt>
gmaxwell: im more ok with miners having inconsistent rules and users having marginally consistent rules than users being split. ofc I'm hoping 148 users either dont use their wallet in the coming weeks or switch to another node
< gmaxwell>
BlueMatt: so by enforcing you can shield yourself from instability and potentially increase consistency.
< gmaxwell>
BlueMatt: going offline isn't an option for everyone.
< BlueMatt>
gmaxwell: i believe that will decrease consistency, not increase
< BlueMatt>
assuming miners are all enforcing 91, its true you will shield yourself from some instability
< gmaxwell>
BlueMatt: there are two main protective effects, assuming you can't go offline it protects you from seeing the network forking... the other is that it would damp enforcement instability.
< gmaxwell>
BlueMatt: imagine that there was a lot of false signaling, and at enforcement time half the hashrate doesn't enforce....
< gmaxwell>
You could imagine (say) slush going "oh crap! network is forked, we're getting orphaned, we're going to stop enforcing 91!" while at the same time antpool goes "oh crap, we're getting orphaned we need to start enforcing 91!!"
< gmaxwell>
this might take a frightningly large time to converge, and even if it converges fast it means that all users will see a very large reorg.
< BlueMatt>
gmaxwell: I agree with the first part, but given heavily inconsistent enforcement I'm far from convinced it wont just be that china is sleeping and europe is awake and 91 gets turned off :p
< gmaxwell>
Now if you have some major parties and users running this, the outcome is immediately stabilized: the enforcing parties won't stop.
< gmaxwell>
Even better only _some_ users see a big reorg.
< BlueMatt>
that assumes an outcome
< gmaxwell>
It creates it, and in doing so retroactively erases instability.
< BlueMatt>
and given lack of 100% clarity given the timelines involved, I dont think we should assume an outcome, especially given that we cant get upgrades in time for this to be "useful"
< BlueMatt>
i dont believe it does
< BlueMatt>
simply because of the timelines involved
< BlueMatt>
fuck, getting gitian builders dont will take 6 hours and there's a huge chunk of your time already
< gmaxwell>
it wouldn't if not for the fact that that outcome is already in play.
< gmaxwell>
who said anything about gitian even... just putting up an 'officially supported' patch would be protective, allow parties to shield themselves, and contribute to symmetry breaking.
< * gmaxwell>
dinner
< BlueMatt>
ugh, i need sleep sorry...I'm very much not convinced...I'm skeptical a few 148-but-sooner-activation nodes will meaningfully contribute to symmetry breaking, and even if they did, I'm skeptical that it outweighs the convergance risks as it introduces yet another set of consensus rules into play
< bitcoin-git>
[bitcoin] NicolasDorier opened pull request #10891: [RPC] Make ImportAddress works with segwit scriptPubKey (master...importaddresswitness) https://github.com/bitcoin/bitcoin/pull/10891
< bitcoin-git>
[bitcoin] NicolasDorier closed pull request #10891: [RPC] Make ImportAddress works with segwit scriptPubKey (master...importaddresswitness) https://github.com/bitcoin/bitcoin/pull/10891
< morcos>
luke-jr: gmaxwell: fwiw, I'm strongly in favor of releasing a BIP 91 patch of BIP 148 with the BIP 91 activation height
< morcos>
that said, i'm not sure i'm going to be bothered to do it myself, it does feel extremely rushed
< morcos>
the complete shitshow we are in now where the vast majority of the network is unable to properly enforce the rules that I think the community has come to consensus on shows why this is such a terrible way to go about rule changes
< morcos>
it wasn't clear to anyone that these NYA agreement guys would even get off the ground, we didn't know if they would change the rules or not, we didn't know if other people would agree
< morcos>
there should have been more time to all agree on the correct BIP 91 parameters, or the NYA guys should have used BIP 148
< morcos>
but that said, even if we can't rush it out in 2 days.. there are actually about 3 weeks where it matters, so it could still do a lot of good
< morcos>
its terrible that i bet between all of us here, we can't even agree on what the rules of bitcoin are 48 hours from now. if miners don't follow BIP 91, what do we do?
< morcos>
another alternative is to release a BIP 148 patch with the Aug 1st date. At least if they start being inconsistent, we can end the dustup on Aug 1st. Thats the other coordination point that is valid now.
< morcos>
It all comes down to this idea of following the most work chain, or following the most work valid chain. I for one am convinced that it is no longer valid not to signal bit 1 for segwit. Whether thats true in 48 hours, or Aug 1, i might be persuadable on
< bitcoin-git>
[bitcoin] corebob opened pull request #10892: Replace traditional for with ranged for in block and transaction primitives (master...20170721-rangedfor-primitives) https://github.com/bitcoin/bitcoin/pull/10892
< bitcoin-git>
[bitcoin] laanwj closed pull request #10604: [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test (master...multiwallet_test) https://github.com/bitcoin/bitcoin/pull/10604
< lejitz>
There seems to be a bit of a false dichotomy in that any mandate to start signaling bit 1 in Core must begin on either the BIP91 block height, or the BIP148 activation time. BIP91 feels rushed, while BIP148 leaves time for potential shenanigans or accidents. If more time is needed than BIP91 allows, why not just start enforcing bit 1 as soon as you can (even before Aug. 1 or after BIP91)?
< Murch>
gmaxwell: Same question.
< Murch>
In order to protect ourselves from reorgs, wouldn't we want to enforce BIP91 starting with BIP91 activation?
< achow101>
lejitz: enforcing bit 1 signaling at any other time than BIP 91 activation height or BIP 148 activation time means that there is potential for yet another fork
< achow101>
enforcing at bip 91 activation height means that we would be enforcing with the bip 91 clients
< achow101>
enforcing at the bip 148 activation time means that we would be enforcing with the bip148 clients.
< achow101>
the point is that we should be enforcing at a time or height which other clients are already enforcing, not at some other time or height.
< achow101>
Murch: enforcing bit 1 signaling at the BIP 91 height would be the best to avoid reorgs.
< Murch>
achow101: We're looking into what patch to run on our protection node to do so. Is SegSignal the way to go or is there an even smaller patch by now (since the bit4 signaling is already obsolete)?
< morcos>
Murch: The SegSignal patch is relatively small. I think there are 13 commits, it probably makes sense to just squash the first 12.
< morcos>
But yes there should be an even smaller patch, that just activates required bit1 at the height, but I don't know of one
< gmaxwell>
morcos: it also needs to stop requiring it.
< achow101>
Murch: a three line patch (for core) can be written which enforces bit 1 signaling at block 477120 (bip 91 activation height)(
< Murch>
achow101: Is anyone working on that 0:-)
< achow101>
me. maybe
< Murch>
achow101: Could you please keep me in the loop? We'd be very interested in that.
< Murch>
In case you happen to work on that.
< sipa>
Murch: that's good to know
< Murch>
sipa: Well. We're currently running vanilla Core, and we're worried about customer funds getting entangled in reorgs that would supposedly be impossible if BIP91 were actually properly enforced.
< jnewbery>
promag: it's a nit. Just a recommendation to be consistent with the surrounding code. You can take it or leave it - we certainly don't have consistent commenting across the codebase.
< achow101>
Murch: it may be better to just run segsignal. The patch is small and easily reviewable and it has tests
< lejitz>
achow101: If most of the econ nodes can upgrade before BIP91 activation, then it is not a problem. But if it is afterwards, I can't see any of them wanting to risk being forked off the network while waiting for others to upgrade (who wants to go first?). As long as no fork has already occurred, then it is not a problem to join in enforcement later, but nobody knows what happens in the meantime while
< lejitz>
everyone tries to coordinate. To solve this problem (assuming most econ nodes can't quickly upgrade before 91 activation), the patch can pick an arbitrary time/block height to start enforcing, so long as every block between BIP91 activation and the patches enforcement time has signaled bit 1. Everyone can take a few days to upgrade, knowing they will remain in consensus if there is a fork in the meantime.
< lejitz>
Or, they can all get patched in two days, which is obviously preferable.
< jonasschnelli>
But indeed its not ideal that the current network situation *forces* users to run non-vanila Core.
< gmaxwell>
jonasschnelli: no it doesn't.
< jonasschnelli>
gmaxwell: what about accepting payment?
< achow101>
lejitz: that assumes that bip91 will be enforced from activation, but that is an assumption we cannot make
< gmaxwell>
what about it? there is _NOTHING_ that can be done which will make it safe to accept payments around the 91 enforcement time, no code is safe. There are potentially better or worse options, sure, but if at all possible people should be increasing the number of confirms they require to dozens.
< lejitz>
achow101: No, the patches enforcement is conditioned on BIP91 being enforced until the chosen enforcement time of the patch.
< lejitz>
patch's
< sipa>
lejitz: we can't observe whether bip91 is being enforced
< sipa>
or at least not in the short term
< jonasschnelli>
Pausing payment is the best option. I guess it's not possible for all kinds of businesses and – if they continue accepting payments – they want to reduce risks.
< achow101>
lejitz: we can't assume that 91 will be enforced until the patch's activation.
< lejitz>
@sipa @achow101 Not enforced, complied with, meaning signaled bit 1. If every block since BIP91's activation (from a post activation perspective) signaled bit 1, then it's been complied with. The enforcement from the patch could be conditioned on that observation.
< gmaxwell>
lejitz: it's virtually guarentted that not every block will set bit 1. There are miners who are just unaware of this stuff going on, mistaken failovers to unupdated software etc.
< ProfMac_lurking>
can I pre seed an IPv6 address? Oh look, I have one handy, [fdbf:946a:5c97:1:80::e8] It is one of the globally unique not routable guys. I see something in tag v0.8.1 src/net.cpp #1144, but I remember something with a numerical hard coding somewhere...
< gribble>
https://github.com/bitcoin/bitcoin/issues/1144 | json_spirit_writer_template.h - comparison is always true due to limited range of data type warning · Issue #1144 · bitcoin/bitcoin · GitHub
< sipa>
ProfMac_lurking: ...?
< lejitz>
@gmaxwell, but if the others are enforcing, then the non-signaling get reorged out.
< gmaxwell>
lejitz: yes and? If.
< gmaxwell>
I'm having a hard time figuring out what your point is.
< sipa>
lejitz: it is a realistic chance that the eventual chain will not have bip91 enforcement, and won't have segwit activated
< ProfMac_lurking>
sipa, seed an IPv6 node's address into the source code.
< sipa>
ProfMac_lurking: yes, what about it?
< sipa>
why?
< morcos>
gmaxwell: I think the point is that we as a community could decide that BIP91 is the new rules of Bitcoin
< gmaxwell>
I wouldn't call it a _high_ chance, but it's not a negligible possiblity. If miners find 91 is getting their blocks orphaned, right now many will stop enforcing. And we know for a fact that virtually all signaling is false. (also emphasized by the existance of signaling patterns which no published patch will produce)
< morcos>
in which case running a BIP91 node makes it safe to accept payments
< gmaxwell>
morcos: This is basically what I was advocating for a day ago.
< sipa>
Murch: *safer
< morcos>
your argument seems to be there isn't enough time to coordinate that
< sipa>
eh
< morcos>
me too!
< sipa>
morcos: *safer
< sipa>
morcos: lejitz is arguing (i think?) for starting bip91 enforcement at another time
< ProfMac_lurking>
I want to do it. Just because I'm curious. Oh, and I think IPv6 the future and I want some experience ahead of the curve.
< morcos>
I think we should do something as a project
< gmaxwell>
morcos: among other issues, we don't have time to manage a release however.
< sipa>
ProfMac_lurking: use -addnode=IP
< morcos>
yes, another time makes no sense
< sipa>
no need to put it in the source code...
< morcos>
gmaxwell: sure agreed
< morcos>
but why don't we decide to release a BIP148 patch then
< morcos>
at least that way this will all be over by aug 1 (this, being the uncertainty)
< lejitz>
gmaxwell: I'm showing how to buy a little more time for a coordination. Not a lot. But some.
< gmaxwell>
lejitz: I do not follow.
< morcos>
i think its clear at this point that there is community consensus for segwit forced signaling
< BlueMatt>
Murch: I'd just recommend changing your api to expose confirmations = confirmations / 6 or something
< ProfMac>
I know about -addnode. I want to crawl around in the code.
< BlueMatt>
Murch: much simpler and you dont have to rely on any inconsistencies being resolved in the bip 91 direction
< sipa>
lejitz: the worst forking will likely be right when bip91 activates...
< gmaxwell>
BlueMatt: while that might also be a good idea, I don't think it's a replacement.
< BlueMatt>
fair
< lejitz>
gmaxwell: see my post to achow at ??:28 Pacific
< lejitz>
11:28
< gmaxwell>
if you draw a factor-matrix, where the options are you enforce 91 or not, and the other axis is 91 enforcement works or not. There is only one quadrant where there are no major reorgs which you see. And thats the you+network enforce one. So I think it is reasonable to push for the one option that doesn't contain a guarenteed bloodbath.
< lejitz>
gmaxwell: Clearly, having everyone enforce BIP91 is the way to go if it can be done in time. But if you can't get the econ nodes enforcing BIP91 before enforcement begins, then it is difficult to get people to begin enforcing at all, because they won't want to be the one to go first in the event that the a fork occurs right after they patch/upgrade. If upgrading must occur after BIP91 activates, then the
< lejitz>
upgradees will want to be coordinated to enforce at the same time. That's the problem I'm getting at.
< gmaxwell>
I think simply telling friendly miners that developers intend to support enforcing this period will help give them the confidence to stick with it, even if there is some churn.
< morcos>
gmaxwell: agree 100% . In fact I think they already have confidence to stick with it. But it certainly can't hurt to support them!
< achow101>
so how about merging #10444 into a separate branch and making a quick 0.14.3 release/tag?
< morcos>
achow101: I strongly agree with this. But unforutntely with it being the weekend and the short timeframe. I'll be hard to gauge enough support
< Murch>
morcos: Right now we're looking at an activation of BIP91 at Sunday morning at ~2am PDT (5am EDT). Likely if any reorgs happen then right at the start.
< morcos>
Murch: sure.. but that's a tight timeline. any release is better than no release
< Murch>
morcos: Yeah, I agree that a release would be good. Another option would be to update BIP148 to start at the activation height of BIP91 activation instead of August 1st.
< morcos>
yes. same thing. UASF at new height. miners signalled readiness to lock in new consensus rules at earlier time than flag day.
< gmaxwell>
I would prefer to do the BIP148 based approach, but its a larger patch, unfortunately.
< morcos>
how we implement in code now is a matter of time and effort
< Murch>
achow101 229 blocks -> divide by 6 -> about 38 hours which made me think 2am Sunday morning. What am I missing?
< achow101>
Murch: 8.7 minute block time, not 10
< achow101>
because that's what it is roughly now
< sipa>
Murch: hashrate is significantly above difficulty
< sipa>
;;hashrate
< gribble>
Error: "hashrate" is not a valid command.
< sipa>
;;bc,hashrate
< gribble>
Error: "bc,hashrate" is not a valid command.
< gribble>
Stop, that hurts.
< sipa>
;;fuck,you
< gribble>
Error: "fuck,you" is not a valid command.
< Murch>
sipa: Okay, I see. Anyway, it's in the middle of Saturday to Sunday night for much of the western world, not a great time to wake up and deal with customer escalations ;)
< achow101>
Murch: just don't sleep :p
< Murch>
achow101: I've tried that, but my body objects
< sipa>
;;calc 6443072419.2968798
< gribble>
6443072419.3
< gmaxwell>
Murch: don't worry, small amounts of forking will probably continue for days, so you'll get support requests at all times of day eventually. :)
< * Murch>
shakes fist, damn deployments without community support *tongue in cheek*
< BlueMatt>
anyone have an android alarm app that goes off based on block height?
< BlueMatt>
(serious question)
< Murch>
BlueMatt: Interesting question, if you do find one, I want to know, too.
< gmaxwell>
BlueMatt: it's really easy to just make your computer play loud music...
< gmaxwell>
while true; do if [ `./bitcoin-cli getblockcount` -gt 476892 ]; then echo alarm_goes_here ; fi ; sleep 10 ; done
< BlueMatt>
eww, if its midnight I'll just get coffee and sit at my desk all evening
< achow101>
BlueMatt: it should be between 9 and 10 PM PDT, so 12-1 AM EDT
< BlueMatt>
yea, easier to stay up
< BlueMatt>
cfields: you coming up to ny to party up here? :p
< cfields>
BlueMatt: heh, i would, but I have a flight out on Sunday morning :(
< cfields>
there's some shitty timing
< BlueMatt>
lol, indeed
< Murch>
achow101, gmaxwell, sipa: We could have a party as well. :p
< cfields>
At least I'll be able to sleep on the flight. Definitely won't be sleeping Sat night
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10898: Fix invalid checks (NULL checks after dereference, redundant checks, etc.) (master...invalid-logic) https://github.com/bitcoin/bitcoin/pull/10898
< sturles>
Re reorgs related to BIP91, will -walletnotify trigger if a transacttion changes status from confirmed to unconfirmed due to a reorg?
< sipa>
no
< sturles>
:-(
< sipa>
i think
< praxeology>
Maybe instead of making a core release that enforces 91 by default, make it optional and default off. And not worry so much about getting it released by when 91 starts enforcing that blocks signal for segwit
< [\\\]>
there are a lot of people that don't do anything but download and run
< [\\\]>
defaults go a long way
< [\\\]>
and expecting people to change that probably isn't reliable
< praxeology>
yea, well, IIRC core is very conservative and patient... and they want a smooth upgrade that is is compatible with old clients
< praxeology>
so releasing something that requires everyone to upgrade right away so that we can enforce a minority chain rule... seems contradictory to core's more conservativeness
< Murch>
praxeology: "minority chain rule" with 97% hashrate support.
< Murch>
And likely very high community support.
< praxeology>
Murch: if it is majority chain, then there is no reason for bitcoincore to release a client that enforces BIP 91... since its majority
< praxeology>
They would only need to release something that enforces BIP 91 if they are trying to enforce a minority chain
< sipa>
praxeology: there are multiple effects in play
< Murch>
praxeology: That's not correct. It looks likely that BIP91 will have a majority in mining support, however due to the quick rollout it has hardly any node infrastructure.
< Murch>
While in sentiment large parts of the community support segwit activation and a majority of that would probably be willing to go along with BIP91, the node count doesn't yet reflect that.
< sipa>
praxeology: a significant amount of hashrate may be spy mining, the amount actually enforcing bip91, even if they intend to, may be low and/or unmeasurable
< Murch>
Providing a patch to Core that includes enforcement of BIP91 would give many users the option to support a defacto activated softfork that they currently can only enforce by running third party software.
< sipa>
praxeology: which may mean that when bip91 activates, many forks are seen on the network, even if everyone totally intends the 91 chain to win
< praxeology>
sipa: yes
< sipa>
i'm still not sure what the best thing to do about is is, as we're on a very short timescale
< Murch>
…and at the same time protect yourselves from going along with blocks that would be later reorganized out of the longest chain because they are not signaling, which for many business usecases provides some level of backend headaches.
< sipa>
but the reason for having bip91 enforcement in the client is not to make a minority chain win
< sipa>
it's to avoid spurious forks and unreliable confirmations during the activation
< praxeology>
sipa: then it sounds to me like you have decided that you do want 91 to be enforced... for it to become the new bitcoin
< [\\\]>
this is slightly off topic, but I'm asking anyway: any reason to allow or not allow bitcoinuasf.org in #bitcoin ?
< sipa>
praxeology: not want; expect
< praxeology>
I think bitcoincore could create a build that enforces 91... just not sure how you would label it. Surely say something different or put it on a different page etc than the normal releases
< sipa>
praxeology: that sounds reasonable to me
< praxeology>
Like you have the Releases list
< praxeology>
put another list to the side of it
< praxeology>
Emergency BIP91 Release
< [\\\]>
just as long as there is an info tip or link to what bip91 is
< [\\\]>
set expectations for people
< praxeology>
Its a release that requires SegWit to be activated.
< praxeology>
does 91 require that every block signal for segwit, or just that at least 95% signal?
< Murch>
praxeology: BIP91 requires every block to signal bit1.
< praxeology>
Emergency "Stick to Guns" BIP 91 Release
< praxeology>
I wish there was better communication from the miners, if we knew whether they were just signaling or actually running the rules
< Eliel>
praxeology: the only way to achieve that would be to somehow interweave the signaling with the actual implementation so that it's extremely difficult to reliably signal without actually running the code.
< bitcoin-git>
[bitcoin] brianmcmichael opened pull request #10899: Qt: Use _putenv_s instead of setenv on Windows builds (master...testfix) https://github.com/bitcoin/bitcoin/pull/10899
< bitcoin-git>
[bitcoin] achow101 opened pull request #10900: [0.14] Enforce segsignal activation height and rules (0.14...early-uasf-bip91) https://github.com/bitcoin/bitcoin/pull/10900
< bitcoin-git>
[bitcoin] promag opened pull request #10901: Fix constness of ArgsManager methods (master...2017-07-args-manager-constness) https://github.com/bitcoin/bitcoin/pull/10901