1 2017-07-21 00:11:26	0|gmaxwell|BIP-91 lock in is now guarenteed (short of a reorg...)
  2 2017-07-21 02:08:07	0|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.
  3 2017-07-21 02:10:21	0|bitcoin-git|[13bitcoin] 15brianmcmichael opened pull request #10889: Docs: Run windows build in a clean path (06master...06docswin) 02https://github.com/bitcoin/bitcoin/pull/10889
  4 2017-07-21 02:16:59	0|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..
  5 2017-07-21 02:17:07	0|luke-jr|BlueMatt: morcos ^
  6 2017-07-21 02:17:41	0|luke-jr|(note this would also help avoid the propagation/partitioning risk BIP91 currently has)
  7 2017-07-21 02:22:13	0|gmaxwell|I'd like to do something there, at a minimum we could put up a minimal patch.
  8 2017-07-21 02:23:46	0|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.
  9 2017-07-21 02:41:24	0|BlueMatt|its two days
 10 2017-07-21 02:41:35	0|BlueMatt|I'd rather make sure the network has consistent(ish) network rules
 11 2017-07-21 02:41:55	0|luke-jr|why observe when we can make sure it does?
 12 2017-07-21 02:42:32	0|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
 13 2017-07-21 02:42:50	0|BlueMatt|uhh...we cant? you arent getting every business and user who uses their wallet to upgrade in 2.5 days
 14 2017-07-21 02:43:20	0|sipa|BlueMatt: it only needs them to update by end of august
 15 2017-07-21 02:43:36	0|BlueMatt|miners decided to take the risk, let them take it, and dont pull everyone into it
 16 2017-07-21 02:43:52	0|BlueMatt|sipa: i belive the suggestion was to enable it on the now-locked bip91 activation block
 17 2017-07-21 02:43:57	0|luke-jr|BlueMatt: we can drastically improve the situation
 18 2017-07-21 02:44:08	0|BlueMatt|im not convinced thats an improvement
 19 2017-07-21 02:44:09	0|sipa|that's just way too fast
 20 2017-07-21 02:46:39	0|gmaxwell|BlueMatt: consistent rules are out the window already, guarenteed.
 21 2017-07-21 02:47:31	0|luke-jr|back in ~45 min
 22 2017-07-21 02:47:59	0|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
 23 2017-07-21 02:48:05	0|gmaxwell|BlueMatt: so by enforcing you can shield yourself from instability and potentially increase consistency.
 24 2017-07-21 02:48:20	0|gmaxwell|BlueMatt: going offline isn't an option for everyone.
 25 2017-07-21 02:49:02	0|BlueMatt|gmaxwell: i believe that will decrease consistency, not increase
 26 2017-07-21 02:49:35	0|BlueMatt|assuming miners are all enforcing 91, its true you will shield yourself from some instability
 27 2017-07-21 03:04:09	0|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.
 28 2017-07-21 03:04:30	0|gmaxwell|BlueMatt: imagine that there was a lot of false signaling, and at enforcement time half the hashrate doesn't enforce....
 29 2017-07-21 03:05:07	0|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!!"
 30 2017-07-21 03:05:47	0|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.
 31 2017-07-21 03:05:53	0|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
 32 2017-07-21 03:06:12	0|gmaxwell|Now if you have some major parties and users running this, the outcome is immediately stabilized: the enforcing parties won't stop.
 33 2017-07-21 03:06:19	0|gmaxwell|Even better only _some_ users see a big reorg.
 34 2017-07-21 03:06:44	0|BlueMatt|that assumes an outcome
 35 2017-07-21 03:07:00	0|gmaxwell|It creates it, and in doing so retroactively erases instability.
 36 2017-07-21 03:07:27	0|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"
 37 2017-07-21 03:07:32	0|BlueMatt|i dont believe it does
 38 2017-07-21 03:07:39	0|BlueMatt|simply because of the timelines involved
 39 2017-07-21 03:07:55	0|BlueMatt|fuck, getting gitian builders dont will take 6 hours and there's a huge chunk of your time already
 40 2017-07-21 03:08:00	0|gmaxwell|it wouldn't if not for the fact that that outcome is already in play.
 41 2017-07-21 03:08:33	0|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.
 42 2017-07-21 03:10:47	0|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
 43 2017-07-21 04:36:45	0|bitcoin-git|[13bitcoin] 15rohythakur opened pull request #10890: added version (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10890
 44 2017-07-21 09:07:58	0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #10891: [RPC] Make ImportAddress works with segwit scriptPubKey (06master...06importaddresswitness) 02https://github.com/bitcoin/bitcoin/pull/10891
 45 2017-07-21 09:32:16	0|bitcoin-git|[13bitcoin] 15NicolasDorier closed pull request #10891: [RPC] Make ImportAddress works with segwit scriptPubKey (06master...06importaddresswitness) 02https://github.com/bitcoin/bitcoin/pull/10891
 46 2017-07-21 10:02:53	0|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
 47 2017-07-21 10:03:22	0|morcos|that said, i'm not sure i'm going to be bothered to do it myself, it does feel extremely rushed
 48 2017-07-21 10:04:15	0|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
 49 2017-07-21 10:04:52	0|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
 50 2017-07-21 10:05:31	0|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
 51 2017-07-21 10:06:17	0|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
 52 2017-07-21 10:07:36	0|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?
 53 2017-07-21 10:08:38	0|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.
 54 2017-07-21 10:14:46	0|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
 55 2017-07-21 10:33:31	0|bitcoin-git|[13bitcoin] 15corebob opened pull request #10892: Replace traditional for with ranged for in block and transaction primitives (06master...0620170721-rangedfor-primitives) 02https://github.com/bitcoin/bitcoin/pull/10892
 56 2017-07-21 13:38:17	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6adc3a37324c...420238d3103a
 57 2017-07-21 13:38:18	0|bitcoin-git|13bitcoin/06master 1409eacee 15John Newbery: [wallet] fix comment for CWallet::Verify()
 58 2017-07-21 13:38:18	0|bitcoin-git|13bitcoin/06master 144a05715 15John Newbery: [wallet] [rpc] print wallet name in getwalletinfo
 59 2017-07-21 13:38:19	0|bitcoin-git|13bitcoin/06master 149508761 15John Newbery: [wallet] [rpc] Add listwallets RPC...
 60 2017-07-21 13:38:36	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10604: [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test (06master...06multiwallet_test) 02https://github.com/bitcoin/bitcoin/pull/10604
 61 2017-07-21 13:51:06	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #10893: [QA] Avoid running multiwallet.py twice (06master...062017/07/fix_mw_test) 02https://github.com/bitcoin/bitcoin/pull/10893
 62 2017-07-21 13:57:55	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #10894: Add CChain object for headers-only chain (06master...062017/07/hdr_chain) 02https://github.com/bitcoin/bitcoin/pull/10894
 63 2017-07-21 16:07:07	0|promag|jnewbery: will do https://github.com/bitcoin/bitcoin/pull/10885#discussion_r128787407
 64 2017-07-21 16:07:48	0|promag|instagibbs: said briefly comment :) but developer notes is clear about that.
 65 2017-07-21 16:34:00	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10895: [wallet] Fix wallet memory leaks in cases of unsuccessful CreateWalletFromFile calls (06master...06wallet-memory-leaks) 02https://github.com/bitcoin/bitcoin/pull/10895
 66 2017-07-21 17:28:50	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10896: Optimize compact reconstruction somewhat (06master...062017-07-faster-compact-reconstruction) 02https://github.com/bitcoin/bitcoin/pull/10896
 67 2017-07-21 17:31:26	0|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)?
 68 2017-07-21 17:32:58	0|Murch|gmaxwell: Same question.
 69 2017-07-21 17:33:35	0|Murch|In order to protect ourselves from reorgs, wouldn't we want to enforce BIP91 starting with BIP91 activation?
 70 2017-07-21 17:36:14	0|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
 71 2017-07-21 17:36:43	0|achow101|enforcing at bip 91 activation height means that we would be enforcing with the bip 91 clients
 72 2017-07-21 17:37:16	0|achow101|enforcing at the bip 148 activation time means that we would be enforcing with the bip148 clients.
 73 2017-07-21 17:37:49	0|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.
 74 2017-07-21 17:38:20	0|achow101|Murch: enforcing bit 1 signaling at the BIP 91 height would be the best to avoid reorgs.
 75 2017-07-21 17:39:29	0|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)?
 76 2017-07-21 17:49:33	0|morcos|Murch: The SegSignal patch is relatively small.  I think there are 13 commits, it probably makes sense to just squash the first 12.
 77 2017-07-21 17:50:07	0|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
 78 2017-07-21 17:53:28	0|gmaxwell|morcos: it also needs to stop requiring it.
 79 2017-07-21 17:55:23	0|achow101|Murch: a three line patch (for core) can be written which enforces bit 1 signaling at block 477120 (bip 91 activation height)(
 80 2017-07-21 17:57:04	0|Murch|achow101: Is anyone working on that 0:-)
 81 2017-07-21 17:59:54	0|achow101|me. maybe
 82 2017-07-21 18:00:40	0|Murch|achow101: Could you please keep me in the loop? We'd be very interested in that.
 83 2017-07-21 18:01:04	0|Murch|In case you happen to work on that.
 84 2017-07-21 18:01:35	0|sipa|Murch: that's good to know
 85 2017-07-21 18:03:22	0|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.
 86 2017-07-21 18:20:20	0|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.
 87 2017-07-21 18:27:16	0|achow101|Murch: it may be better to just run segsignal. The patch is small and easily reviewable and it has tests
 88 2017-07-21 18:28:05	0|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
 89 2017-07-21 18:28:05	0|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.
 90 2017-07-21 18:28:05	0|lejitz|Or, they can all get patched in two days, which is obviously preferable.
 91 2017-07-21 18:29:16	0|jonasschnelli|But indeed its not ideal that the current network situation *forces* users to run non-vanila Core.
 92 2017-07-21 18:29:28	0|gmaxwell|jonasschnelli: no it doesn't.
 93 2017-07-21 18:30:08	0|jonasschnelli|gmaxwell: what about accepting payment?
 94 2017-07-21 18:31:05	0|achow101|lejitz: that assumes that bip91 will be enforced from activation, but that is an assumption we cannot make
 95 2017-07-21 18:31:18	0|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.
 96 2017-07-21 18:32:19	0|lejitz|achow101: No, the patches enforcement is conditioned on BIP91 being enforced until the chosen enforcement time of the patch.
 97 2017-07-21 18:32:33	0|lejitz|patch's
 98 2017-07-21 18:32:36	0|sipa|lejitz: we can't observe whether bip91 is being enforced
 99 2017-07-21 18:32:44	0|sipa|or at least not in the short term
100 2017-07-21 18:32:49	0|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.
101 2017-07-21 18:33:17	0|achow101|lejitz: we can't assume that 91 will be enforced until the patch's activation.
102 2017-07-21 18:35:43	0|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.
103 2017-07-21 18:36:28	0|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.
104 2017-07-21 18:36:30	0|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...
105 2017-07-21 18:36:31	0|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
106 2017-07-21 18:36:58	0|sipa|ProfMac_lurking: ...?
107 2017-07-21 18:37:41	0|lejitz|@gmaxwell, but if the others are enforcing, then the non-signaling get reorged out.
108 2017-07-21 18:38:07	0|gmaxwell|lejitz: yes and? If.
109 2017-07-21 18:38:17	0|gmaxwell|I'm having a hard time figuring out what your point is.
110 2017-07-21 18:38:19	0|sipa|lejitz: it is a realistic chance that the eventual chain will not have bip91 enforcement, and won't have segwit activated
111 2017-07-21 18:39:03	0|ProfMac_lurking|sipa, seed an IPv6 node's address into the source code.
112 2017-07-21 18:39:12	0|sipa|ProfMac_lurking: yes, what about it?
113 2017-07-21 18:39:21	0|sipa|why?
114 2017-07-21 18:39:39	0|morcos|gmaxwell: I think the point is that we as a community could decide that BIP91 is the new rules of Bitcoin
115 2017-07-21 18:39:50	0|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)
116 2017-07-21 18:39:50	0|morcos|in which case running a BIP91 node makes it safe to accept payments
117 2017-07-21 18:40:10	0|gmaxwell|morcos: This is basically what I was advocating for a day ago.
118 2017-07-21 18:40:11	0|sipa|Murch: *safer
119 2017-07-21 18:40:12	0|morcos|your argument seems to be there isn't enough time to coordinate that
120 2017-07-21 18:40:19	0|sipa|eh
121 2017-07-21 18:40:20	0|morcos|me too!
122 2017-07-21 18:40:21	0|sipa|morcos: *safer
123 2017-07-21 18:40:51	0|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.
124 2017-07-21 18:40:51	0|sipa|morcos: lejitz is arguing (i think?) for starting bip91 enforcement at another time
125 2017-07-21 18:40:57	0|morcos|I think we should do something as a project
126 2017-07-21 18:40:59	0|gmaxwell|morcos: among other issues, we don't have time to manage a release however.
127 2017-07-21 18:41:03	0|sipa|ProfMac_lurking: use -addnode=IP
128 2017-07-21 18:41:11	0|morcos|yes, another time makes no sense
129 2017-07-21 18:41:13	0|sipa|no need to put it in the source code...
130 2017-07-21 18:41:16	0|morcos|gmaxwell: sure agreed
131 2017-07-21 18:41:36	0|morcos|but why don't we decide to release a BIP148 patch then
132 2017-07-21 18:41:50	0|morcos|at least that way this will all be over by aug 1 (this, being the uncertainty)
133 2017-07-21 18:41:55	0|lejitz|gmaxwell: I'm showing how to buy a little more time for a coordination.  Not a lot.  But some.
134 2017-07-21 18:42:10	0|gmaxwell|lejitz: I do not follow.
135 2017-07-21 18:42:14	0|morcos|i think its clear at this point that there is community consensus for segwit forced signaling
136 2017-07-21 18:42:17	0|BlueMatt|Murch: I'd just recommend changing your api to expose confirmations = confirmations / 6 or something
137 2017-07-21 18:42:17	0|ProfMac|I know about -addnode.  I want to crawl around in the code.
138 2017-07-21 18:42:35	0|BlueMatt|Murch: much simpler and you dont have to rely on any inconsistencies being resolved in the bip 91 direction
139 2017-07-21 18:42:48	0|sipa|lejitz: the worst forking will likely be right when bip91 activates...
140 2017-07-21 18:42:55	0|gmaxwell|BlueMatt: while that might also be a good idea, I don't think it's a replacement.
141 2017-07-21 18:43:03	0|BlueMatt|fair
142 2017-07-21 18:43:29	0|lejitz|gmaxwell: see my post to achow at ??:28 Pacific
143 2017-07-21 18:43:54	0|lejitz|11:28
144 2017-07-21 18:45:02	0|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.
145 2017-07-21 18:56:12	0|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
146 2017-07-21 18:56:12	0|lejitz|upgradees will want to be coordinated to enforce at the same time.  That's the problem I'm getting at.
147 2017-07-21 18:56:56	0|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.
148 2017-07-21 19:02:19	0|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!
149 2017-07-21 19:06:46	0|achow101|so how about merging #10444 into a separate branch and making a quick 0.14.3 release/tag?
150 2017-07-21 19:06:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/10444 | Implement BIP91 Reduced threshold Segwit MASF by jameshilliard · Pull Request #10444 · bitcoin/bitcoin · GitHub
151 2017-07-21 19:10:58	0|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
152 2017-07-21 19:13:07	0|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.
153 2017-07-21 19:13:33	0|morcos|Murch: sure.. but that's a tight timeline.  any release is better than no release
154 2017-07-21 19:14:20	0|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.
155 2017-07-21 19:15:24	0|morcos|yes.  same thing.  UASF at new height.   miners signalled readiness to lock in new consensus rules at earlier time than flag day.
156 2017-07-21 19:15:26	0|achow101|Murch: uhh. I calculate saturday 9 PM PDT activation
157 2017-07-21 19:15:29	0|sipa|Murch: i get around 9pm tomorrow PD
158 2017-07-21 19:15:45	0|gmaxwell|I would prefer to do the BIP148 based approach, but its a larger patch, unfortunately.
159 2017-07-21 19:15:46	0|morcos|how we implement in code now is a matter of time and effort
160 2017-07-21 19:18:40	0|Murch|achow101 229 blocks -> divide by 6 -> about 38 hours which made me think 2am Sunday morning. What am I missing?
161 2017-07-21 19:18:53	0|achow101|Murch: 8.7 minute block time, not 10
162 2017-07-21 19:18:59	0|achow101|because that's what it is roughly now
163 2017-07-21 19:18:59	0|sipa|Murch: hashrate is significantly above difficulty
164 2017-07-21 19:19:16	0|sipa|;;hashrate
165 2017-07-21 19:19:17	0|gribble|Error: "hashrate" is not a valid command.
166 2017-07-21 19:19:22	0|gribble|Error: "bc,hashrate" is not a valid command.
167 2017-07-21 19:19:22	0|sipa|;;bc,hashrate
168 2017-07-21 19:19:37	0|gribble|Stop, that hurts.
169 2017-07-21 19:19:50	0|sipa|;;fuck,you
170 2017-07-21 19:19:51	0|gribble|Error: "fuck,you" is not a valid command.
171 2017-07-21 19:20:20	0|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 ;)
172 2017-07-21 19:20:37	0|achow101|Murch: just don't sleep :p
173 2017-07-21 19:20:49	0|Murch|achow101: I've tried that, but my body objects
174 2017-07-21 19:20:58	0|gribble|6443072419.3
175 2017-07-21 19:20:58	0|sipa|;;calc 6443072419.2968798
176 2017-07-21 19:21:24	0|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. :)
177 2017-07-21 19:22:57	0|BlueMatt|anyone have an android alarm app that goes off based on block height?
178 2017-07-21 19:23:01	0|BlueMatt|(serious question)
179 2017-07-21 19:23:32	0|Murch|BlueMatt: Interesting question, if you do find one, I want to know, too.
180 2017-07-21 19:23:39	0|gmaxwell|BlueMatt: it's really easy to just make your computer play loud music...
181 2017-07-21 19:26:20	0|gmaxwell|while true; do if [ `./bitcoin-cli getblockcount` -gt 476892 ]; then echo alarm_goes_here ; fi ; sleep 10 ; done
182 2017-07-21 19:26:41	0|BlueMatt|eww, if its midnight I'll just get coffee and sit at my desk all evening
183 2017-07-21 19:27:06	0|achow101|BlueMatt: it should be between 9 and 10 PM PDT, so 12-1 AM EDT
184 2017-07-21 19:27:18	0|BlueMatt|yea, easier to stay up
185 2017-07-21 19:27:25	0|BlueMatt|cfields: you coming up to ny to party up here? :p
186 2017-07-21 19:28:22	0|cfields|BlueMatt: heh, i would, but I have a flight out on Sunday morning :(
187 2017-07-21 19:28:27	0|cfields|there's some shitty timing
188 2017-07-21 19:28:32	0|BlueMatt|lol, indeed
189 2017-07-21 19:28:42	0|Murch|achow101, gmaxwell, sipa: We could have a party as well. :p
190 2017-07-21 19:29:07	0|cfields|At least I'll be able to sleep on the flight. Definitely won't be sleeping Sat night
191 2017-07-21 19:33:23	0|BlueMatt|lol
192 2017-07-21 19:39:24	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #10895: [wallet] Fix wallet memory leaks in cases of unsuccessful CreateWalletFromFile calls (06master...06wallet-memory-leaks) 02https://github.com/bitcoin/bitcoin/pull/10895
193 2017-07-21 19:49:33	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10898: Fix invalid checks (NULL checks after dereference, redundant checks, etc.) (06master...06invalid-logic) 02https://github.com/bitcoin/bitcoin/pull/10898
194 2017-07-21 20:13:20	0|sturles|Re reorgs related to BIP91, will -walletnotify trigger if a transacttion changes status from confirmed to unconfirmed due to a reorg?
195 2017-07-21 20:13:32	0|sipa|no
196 2017-07-21 20:13:41	0|sturles|:-(
197 2017-07-21 20:13:56	0|sipa|i think
198 2017-07-21 20:26:46	0|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
199 2017-07-21 20:29:04	0|[\\\]|there are a lot of people that don't do anything but download and run
200 2017-07-21 20:29:10	0|[\\\]|defaults go a long way
201 2017-07-21 20:29:18	0|[\\\]|and expecting people to change that probably isn't reliable
202 2017-07-21 20:30:38	0|praxeology|yea, well, IIRC core is very conservative and patient... and they want a smooth upgrade that is is compatible with old clients
203 2017-07-21 20:31:47	0|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
204 2017-07-21 20:42:21	0|Murch|praxeology: "minority chain rule" with 97% hashrate support.
205 2017-07-21 20:42:44	0|Murch|And likely very high community support.
206 2017-07-21 20:43:18	0|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
207 2017-07-21 20:43:49	0|praxeology|They would only need to release something that enforces BIP 91 if  they are trying to enforce a minority chain
208 2017-07-21 20:44:45	0|sipa|praxeology: there are multiple effects in play
209 2017-07-21 20:44:49	0|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.
210 2017-07-21 20:45:28	0|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.
211 2017-07-21 20:46:07	0|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
212 2017-07-21 20:46:10	0|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.
213 2017-07-21 20:46:40	0|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
214 2017-07-21 20:46:59	0|praxeology|sipa: yes
215 2017-07-21 20:47:06	0|sipa|i'm still not sure what the best thing to do about is is, as we're on a very short timescale
216 2017-07-21 20:47:22	0|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.
217 2017-07-21 20:47:27	0|sipa|but the reason for having bip91 enforcement in the client is not to make a minority chain win
218 2017-07-21 20:47:46	0|sipa|it's to avoid spurious forks and unreliable confirmations during the activation
219 2017-07-21 20:48:26	0|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
220 2017-07-21 20:48:28	0|[\\\]|this is slightly off topic, but I'm asking anyway:  any reason to allow or not allow bitcoinuasf.org in #bitcoin ?
221 2017-07-21 20:49:04	0|sipa|praxeology: not want; expect
222 2017-07-21 20:52:29	0|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
223 2017-07-21 20:52:46	0|sipa|praxeology: that sounds reasonable to me
224 2017-07-21 20:53:00	0|praxeology|Like you have the Releases list
225 2017-07-21 20:53:10	0|praxeology|put another list to the side of it
226 2017-07-21 20:53:29	0|praxeology|Emergency BIP91 Release
227 2017-07-21 20:53:45	0|[\\\]|just as long as there is an info tip or link to what bip91 is
228 2017-07-21 20:53:51	0|[\\\]|set expectations for people
229 2017-07-21 20:55:03	0|praxeology|Its a release that requires SegWit to be activated.
230 2017-07-21 20:55:46	0|praxeology|does 91 require that every block signal for segwit, or just that at least 95% signal?
231 2017-07-21 20:58:04	0|Murch|praxeology: BIP91 requires every block to signal bit1.
232 2017-07-21 21:00:22	0|praxeology|Emergency "Stick to Guns" BIP 91 Release
233 2017-07-21 21:03:12	0|praxeology|I wish there was better communication from the miners, if we knew whether they were just signaling or actually running the rules
234 2017-07-21 21:15:28	0|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.
235 2017-07-21 21:28:14	0|bitcoin-git|[13bitcoin] 15brianmcmichael opened pull request #10899: Qt: Use _putenv_s instead of setenv on Windows builds (06master...06testfix) 02https://github.com/bitcoin/bitcoin/pull/10899
236 2017-07-21 22:34:41	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #10900: [0.14] Enforce segsignal activation height and rules (060.14...06early-uasf-bip91) 02https://github.com/bitcoin/bitcoin/pull/10900
237 2017-07-21 23:08:06	0|bitcoin-git|[13bitcoin] 15promag opened pull request #10901: Fix constness of ArgsManager methods (06master...062017-07-args-manager-constness) 02https://github.com/bitcoin/bitcoin/pull/10901