--- Day changed Fri Jul 21 2017
00:00 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev     
00:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
00:11 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
00:11 -!- Squidicuz [~squid@pool-173-48-113-37.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again]     
00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:14 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
00:17 -!- jamesob [~jamesob@73.241.180.136] has joined #bitcoin-core-dev     
00:22 -!- jamesob [~jamesob@73.241.180.136] has quit [Ping timeout: 255 seconds]     
00:23 -!- djbooth007 [6eafbeec@gateway/web/freenode/ip.110.175.190.236] has quit [Ping timeout: 260 seconds]     
00:34 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Ping timeout: 246 seconds]     
00:45 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
00:47 -!- henrik_ [~Hen@62-243-108-58-static.dk.customer.tdc.net] has joined #bitcoin-core-dev     
00:48 -!- henrik_ [~Hen@62-243-108-58-static.dk.customer.tdc.net] has quit [Client Quit]     
00:58 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has joined #bitcoin-core-dev     
01:01 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
01:02 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has quit [Changing host]     
01:02 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
01:18 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]     
01:23 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
01:39 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has joined #bitcoin-core-dev     
01:51 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev     
01:54 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
01:58 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
02:07 < bitcoin-git> [bitcoin] NicolasDorier opened pull request #10891: [RPC] Make ImportAddress works with segwit scriptPubKey (master...importaddresswitness) https://github.com/bitcoin/bitcoin/pull/10891
02:08 -!- To7 [~theo@2604:2000:1382:b7:f090:fb65:368b:565] has quit [Ping timeout: 246 seconds]     
02:11 -!- ayy1337|2 [~kvirc@110.140.15.24] has quit [Ping timeout: 260 seconds]     
02:14 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
02:15 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
02:17 -!- aqquadro [~name@unaffiliated/aqquadro] has joined #bitcoin-core-dev     
02:19 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
02:23 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]     
02:31 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
02:32 < bitcoin-git> [bitcoin] NicolasDorier closed pull request #10891: [RPC] Make ImportAddress works with segwit scriptPubKey (master...importaddresswitness) https://github.com/bitcoin/bitcoin/pull/10891
02:36 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev     
02:49 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 246 seconds]     
02:49 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev     
02:51 -!- aqquadro [~name@unaffiliated/aqquadro] has quit [Ping timeout: 255 seconds]     
02:52 -!- derbumi [sid186430@gateway/web/irccloud.com/x-pcxfwxdoicyjcoyf] has joined #bitcoin-core-dev     
03:02 < 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
03:03 < morcos> that said, i'm not sure i'm going to be bothered to do it myself, it does feel extremely rushed 
03:04 < 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
03:04 < 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
03:05 < 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
03:06 < 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
03:07 < 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? 
03:08 < 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.
03:14 < 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
03:18 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 255 seconds]     
03:18 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 246 seconds]     
03:20 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
03:25 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 258 seconds]     
03:29 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:32 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has quit [Changing host]     
03:32 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
03:33 < 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
03:41 -!- riemann [~riemann@ip-222-88.ists.pl] has joined #bitcoin-core-dev     
03:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:51 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
04:09 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
04:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
04:44 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has joined #bitcoin-core-dev     
05:04 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
05:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
05:19 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
05:21 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
05:26 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds]     
05:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
05:27 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
05:28 -!- corebob [~corebob@2a02:fe0:c150:1a00:8958:6277:6ca3:b2cf] has quit [Quit: WeeChat 1.9]     
05:41 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
05:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:48 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
06:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
06:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
06:38 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/6adc3a37324c...420238d3103a
06:38 < bitcoin-git> bitcoin/master 09eacee John Newbery: [wallet] fix comment for CWallet::Verify()
06:38 < bitcoin-git> bitcoin/master 4a05715 John Newbery: [wallet] [rpc] print wallet name in getwalletinfo
06:38 < bitcoin-git> bitcoin/master 9508761 John Newbery: [wallet] [rpc] Add listwallets RPC...
06:38 < 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
06:47 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 246 seconds]     
06:50 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
06:51 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10893: [QA] Avoid running multiwallet.py twice (master...2017/07/fix_mw_test) https://github.com/bitcoin/bitcoin/pull/10893
06:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
06:57 -!- promag [~joao@2001:8a0:fe30:de01:2164:7e69:b586:9a64] has joined #bitcoin-core-dev     
06:57 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10894: Add CChain object for headers-only chain (master...2017/07/hdr_chain) https://github.com/bitcoin/bitcoin/pull/10894
07:00 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 260 seconds]     
07:02 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
07:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:12 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has quit [Changing host]     
07:12 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
07:13 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
07:23 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
07:23 -!- JackH [~laptop@46.231.18.66] has quit [Quit: Leaving]     
07:28 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds]     
07:28 -!- phog_ [~phog@93.90.2.128] has joined #bitcoin-core-dev     
08:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
08:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:14 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]     
08:21 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
08:23 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has quit [Changing host]     
08:23 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
08:23 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
08:25 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
08:27 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
08:30 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]     
08:36 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 240 seconds]     
08:46 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:49 -!- praxeology1 [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has joined #bitcoin-core-dev     
08:52 -!- praxeology [~praxeolog@unaffiliated/praxeology] has quit [Ping timeout: 260 seconds]     
08:54 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
09:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lcuyieiwfvopotkk] has joined #bitcoin-core-dev     
09:05 -!- jamesob_ [~james@tempo-automation.static.monkeybrains.net] has joined #bitcoin-core-dev     
09:07 < promag> jnewbery: will do https://github.com/bitcoin/bitcoin/pull/10885#discussion_r128787407
09:07 < promag> instagibbs: said briefly comment :) but developer notes is clear about that.
09:08 -!- promag [~joao@2001:8a0:fe30:de01:2164:7e69:b586:9a64] has quit [Quit: Leaving.]     
09:16 -!- praxeology1 [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has quit [Quit: Leaving.]     
09:18 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]     
09:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]     
09:24 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
09:27 -!- ProfMac_lurking [43c671dc@gateway/web/freenode/ip.67.198.113.220] has joined #bitcoin-core-dev     
09:30 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]     
09:33 < bitcoin-git> [bitcoin] practicalswift opened pull request #10895: [wallet] Fix wallet memory leaks in cases of unsuccessful CreateWalletFromFile calls (master...wallet-memory-leaks) https://github.com/bitcoin/bitcoin/pull/10895
10:14 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 255 seconds]     
10:18 -!- Deadhand [~deadhand@CPEf0f249a14e43-CMf0f249a14e40.cpe.net.cable.rogers.com] has quit [Ping timeout: 258 seconds]     
10:18 -!- Alina-malina [~Alina-mal@37.157.223.81] has joined #bitcoin-core-dev     
10:21 -!- Deadhand [~deadhand@CPEf0f249a14e43-CMf0f249a14e40.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev     
10:23 -!- Alina-malina [~Alina-mal@37.157.223.81] has quit [Changing host]     
10:23 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
10:26 -!- jamesob [~jamesob@73.241.180.136] has joined #bitcoin-core-dev     
10:28 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10896: Optimize compact reconstruction somewhat (master...2017-07-faster-compact-reconstruction) https://github.com/bitcoin/bitcoin/pull/10896
10:30 -!- jamesob [~jamesob@73.241.180.136] has quit [Ping timeout: 255 seconds]     
10:31 < 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)?
10:32 < Murch> gmaxwell: Same question.
10:33 < Murch> In order to protect ourselves from reorgs, wouldn't we want to enforce BIP91 starting with BIP91 activation?
10:36 < 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
10:36 < achow101> enforcing at bip 91 activation height means that we would be enforcing with the bip 91 clients
10:37 < achow101> enforcing at the bip 148 activation time means that we would be enforcing with the bip148 clients.
10:37 < 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.
10:38 < achow101> Murch: enforcing bit 1 signaling at the BIP 91 height would be the best to avoid reorgs.
10:39 < 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)?
10:49 < morcos> Murch: The SegSignal patch is relatively small.  I think there are 13 commits, it probably makes sense to just squash the first 12.
10:50 < 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
10:53 < gmaxwell> morcos: it also needs to stop requiring it.
10:54 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 268 seconds]     
10:55 < achow101> Murch: a three line patch (for core) can be written which enforces bit 1 signaling at block 477120 (bip 91 activation height)(
10:57 < Murch> achow101: Is anyone working on that 0:-)
10:59 < achow101> me. maybe
11:00 < Murch> achow101: Could you please keep me in the loop? We'd be very interested in that.
11:01 < Murch> In case you happen to work on that.
11:01 < sipa> Murch: that's good to know
11:03 < 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.
11:08 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:16 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:20 < 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.
11:24 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:27 < achow101> Murch: it may be better to just run segsignal. The patch is small and easily reviewable and it has tests
11:28 < 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
11:28 < 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. 
11:28 < lejitz> Or, they can all get patched in two days, which is obviously preferable.
11:29 < jonasschnelli> But indeed its not ideal that the current network situation *forces* users to run non-vanila Core.
11:29 < gmaxwell> jonasschnelli: no it doesn't.
11:30 < jonasschnelli> gmaxwell: what about accepting payment?
11:31 < achow101> lejitz: that assumes that bip91 will be enforced from activation, but that is an assumption we cannot make
11:31 < 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.
11:31 -!- darawk [~textual@76.79.73.19] has joined #bitcoin-core-dev     
11:32 < lejitz> achow101: No, the patches enforcement is conditioned on BIP91 being enforced until the chosen enforcement time of the patch.
11:32 < lejitz> patch's
11:32 < sipa> lejitz: we can't observe whether bip91 is being enforced
11:32 < sipa> or at least not in the short term
11:32 < 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.
11:33 < achow101> lejitz: we can't assume that 91 will be enforced until the patch's activation.
11:35 < 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.
11:36 < 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.
11:36 < 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...
11:36 < 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
11:36 < sipa> ProfMac_lurking: ...?
11:37 < lejitz> @gmaxwell, but if the others are enforcing, then the non-signaling get reorged out.
11:38 < gmaxwell> lejitz: yes and? If.
11:38 < gmaxwell> I'm having a hard time figuring out what your point is.
11:38 < sipa> lejitz: it is a realistic chance that the eventual chain will not have bip91 enforcement, and won't have segwit activated
11:39 < ProfMac_lurking> sipa, seed an IPv6 node's address into the source code.
11:39 < sipa> ProfMac_lurking: yes, what about it?
11:39 < sipa> why?
11:39 < morcos> gmaxwell: I think the point is that we as a community could decide that BIP91 is the new rules of Bitcoin
11:39 < 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)
11:39 < morcos> in which case running a BIP91 node makes it safe to accept payments
11:40 < gmaxwell> morcos: This is basically what I was advocating for a day ago.
11:40 < sipa> Murch: *safer
11:40 < morcos> your argument seems to be there isn't enough time to coordinate that 
11:40 < sipa> eh     
11:40 < morcos> me too!
11:40 < sipa> morcos: *safer
11:40 < sipa> morcos: lejitz is arguing (i think?) for starting bip91 enforcement at another time
11:40 < 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.
11:40 < morcos> I think we should do something as a project
11:40 < gmaxwell> morcos: among other issues, we don't have time to manage a release however.
11:41 < sipa> ProfMac_lurking: use -addnode=IP
11:41 -!- ProfMac_lurking is now known as ProfMac     
11:41 < morcos> yes, another time makes no sense
11:41 < sipa> no need to put it in the source code...
11:41 < morcos> gmaxwell: sure agreed
11:41 < morcos> but why don't we decide to release a BIP148 patch then
11:41 < morcos> at least that way this will all be over by aug 1 (this, being the uncertainty)
11:41 < lejitz> gmaxwell: I'm showing how to buy a little more time for a coordination.  Not a lot.  But some.
11:42 < gmaxwell> lejitz: I do not follow.
11:42 < morcos> i think its clear at this point that there is community consensus for segwit forced signaling
11:42 < BlueMatt> Murch: I'd just recommend changing your api to expose confirmations = confirmations / 6 or something
11:42 < ProfMac> I know about -addnode.  I want to crawl around in the code.
11:42 < BlueMatt> Murch: much simpler and you dont have to rely on any inconsistencies being resolved in the bip 91 direction
11:42 < sipa> lejitz: the worst forking will likely be right when bip91 activates... 
11:42 < gmaxwell> BlueMatt: while that might also be a good idea, I don't think it's a replacement.
11:43 < BlueMatt> fair
11:43 < lejitz> gmaxwell: see my post to achow at ??:28 Pacific
11:43 < lejitz> 11:28
11:45 < 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.
11:51 -!- ayy1337|2 [~kvirc@110.140.15.24] has joined #bitcoin-core-dev     
11:52 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
11:53 -!- cdecker is now known as cdecker|afk     
11:56 < 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
11:56 < lejitz> upgradees will want to be coordinated to enforce at the same time.  That's the problem I'm getting at.
11:56 < 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.
11:58 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
12:02 < 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!
12:06 < achow101> so how about merging #10444 into a separate branch and making a quick 0.14.3 release/tag?
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/10444 | Implement BIP91 Reduced threshold Segwit MASF by jameshilliard · Pull Request #10444 · bitcoin/bitcoin · GitHub
12:10 < 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
12:11 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
12:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
12:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
12:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:13 < 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.
12:13 < morcos> Murch: sure.. but that's a tight timeline.  any release is better than no release
12:14 < 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.
12:14 -!- Aaronvan_ is now known as AaronvanW     
12:15 < morcos> yes.  same thing.  UASF at new height.   miners signalled readiness to lock in new consensus rules at earlier time than flag day.
12:15 < achow101> Murch: uhh. I calculate saturday 9 PM PDT activation
12:15 < sipa> Murch: i get around 9pm tomorrow PD
12:15 < gmaxwell> I would prefer to do the BIP148 based approach, but its a larger patch, unfortunately. 
12:15 < morcos> how we implement in code now is a matter of time and effort
12:15 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
12:18 < Murch> achow101 229 blocks -> divide by 6 -> about 38 hours which made me think 2am Sunday morning. What am I missing?
12:18 < achow101> Murch: 8.7 minute block time, not 10
12:18 < achow101> because that's what it is roughly now
12:18 < sipa> Murch: hashrate is significantly above difficulty
12:19 < sipa> ;;hashrate
12:19 < gribble> Error: "hashrate" is not a valid command.
12:19 < sipa> ;;bc,hashrate
12:19 < gribble> Error: "bc,hashrate" is not a valid command.
12:19 < gribble> Stop, that hurts.
12:19 < sipa> ;;fuck,you
12:19 < gribble> Error: "fuck,you" is not a valid command.
12:20 < 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 ;)
12:20 < achow101> Murch: just don't sleep :p
12:20 < Murch> achow101: I've tried that, but my body objects
12:20 < sipa> ;;calc 6443072419.2968798
12:20 < gribble> 6443072419.3
12:21 < 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. :)
12:22  * Murch shakes fist, damn deployments without community support *tongue in cheek*
12:22 < BlueMatt> anyone have an android alarm app that goes off based on block height?
12:23 < BlueMatt> (serious question)
12:23 < Murch> BlueMatt: Interesting question, if you do find one, I want to know, too.
12:23 < gmaxwell> BlueMatt: it's really easy to just make your computer play loud music...
12:25 -!- DrOlmer2 [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev     
12:26 < gmaxwell> while true; do if [ `./bitcoin-cli getblockcount` -gt 476892 ]; then echo alarm_goes_here ; fi ; sleep 10 ; done
12:26 < BlueMatt> eww, if its midnight I'll just get coffee and sit at my desk all evening
12:27 < achow101> BlueMatt: it should be between 9 and 10 PM PDT, so 12-1 AM EDT
12:27 < BlueMatt> yea, easier to stay up
12:27 < BlueMatt> cfields: you coming up to ny to party up here? :p
12:27 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
12:27 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
12:28 < cfields> BlueMatt: heh, i would, but I have a flight out on Sunday morning :(
12:28 < cfields> there's some shitty timing
12:28 < BlueMatt> lol, indeed
12:28 < Murch> achow101, gmaxwell, sipa: We could have a party as well. :p
12:29 -!- eck [~eck@fsf/member/eck] has quit [Quit: poop]     
12:29 < cfields> At least I'll be able to sleep on the flight. Definitely won't be sleeping Sat night
12:29 -!- drapetomano [c87f2e33@gateway/web/freenode/ip.200.127.46.51] has joined #bitcoin-core-dev     
12:31 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 260 seconds]     
12:32 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
12:33 < BlueMatt> lol     
12:39 < bitcoin-git> [bitcoin] practicalswift closed pull request #10895: [wallet] Fix wallet memory leaks in cases of unsuccessful CreateWalletFromFile calls (master...wallet-memory-leaks) https://github.com/bitcoin/bitcoin/pull/10895
12:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
12:41 -!- ProfMac [43c671dc@gateway/web/freenode/ip.67.198.113.220] has quit [Ping timeout: 260 seconds]     
12:48 -!- drapetomano [c87f2e33@gateway/web/freenode/ip.200.127.46.51] has quit [Quit: Page closed]     
12:49 < 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
12:49 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
12:50 -!- praxeology [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has joined #bitcoin-core-dev     
12:50 -!- praxeology [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has quit [Changing host]     
12:50 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
12:58 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
13:04 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
13:10 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
13:13 < sturles> Re reorgs related to BIP91, will -walletnotify trigger if a transacttion changes status from confirmed to unconfirmed due to a reorg?
13:13 < sipa> no     
13:13 < sturles> :-(     
13:13 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
13:13 < sipa> i think
13:14 -!- tiagotrs [~tiago@p5DC46191.dip0.t-ipconnect.de] has quit [Changing host]     
13:14 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
13:15 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
13:26 < 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
13:29 < [\\\]> there are a lot of people that don't do anything but download and run
13:29 < [\\\]> defaults go a long way
13:29 < [\\\]> and expecting people to change that probably isn't reliable
13:30 < praxeology> yea, well, IIRC core is very conservative and patient... and they want a smooth upgrade that is is compatible with old clients
13:31 < 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
13:39 -!- Cory [~Cory@unaffiliated/cory] has quit []     
13:42 < Murch> praxeology: "minority chain rule" with 97% hashrate support.
13:42 < Murch> And likely very high community support.
13:43 < 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
13:43 < praxeology> They would only need to release something that enforces BIP 91 if  they are trying to enforce a minority chain
13:44 < sipa> praxeology: there are multiple effects in play
13:44 < 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.
13:45 < 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.
13:46 < 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
13:46 < 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.
13:46 < 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
13:46 < praxeology> sipa: yes
13:47 < sipa> i'm still not sure what the best thing to do about is is, as we're on a very short timescale
13:47 < 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.
13:47 < sipa> but the reason for having bip91 enforcement in the client is not to make a minority chain win
13:47 < sipa> it's to avoid spurious forks and unreliable confirmations during the activation
13:48 < 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
13:48 < [\\\]> this is slightly off topic, but I'm asking anyway:  any reason to allow or not allow bitcoinuasf.org in #bitcoin ?
13:49 < sipa> praxeology: not want; expect
13:52 < 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
13:52 < sipa> praxeology: that sounds reasonable to me
13:52 < praxeology> Like you have the Releases list
13:53 < praxeology> put another list to the side of it
13:53 < praxeology> Emergency BIP91 Release
13:53 < [\\\]> just as long as there is an info tip or link to what bip91 is
13:53 < [\\\]> set expectations for people
13:55 < praxeology> Its a release that requires SegWit to be activated.
13:55 < praxeology> does 91 require that every block signal for segwit, or just that at least 95% signal?
13:58 < Murch> praxeology: BIP91 requires every block to signal bit1.
14:00 < praxeology> Emergency "Stick to Guns" BIP 91 Release
14:03 < praxeology> I wish there was better communication from the miners, if we knew whether they were just signaling or actually running the rules
14:08 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
14:09 -!- Dizzle [~dizzle@108.171.182.16] has quit [Ping timeout: 248 seconds]     
14:09 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
14:15 < 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.
14:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
14:16 -!- DrOlmer2 [~DrOlmer@unaffiliated/drolmer] has quit [Ping timeout: 248 seconds]     
14:17 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
14:25 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 276 seconds]     
14:28 < 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
14:29 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
14:34 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
14:41 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev     
14:43 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev     
14:54 -!- shufflepuff [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
14:55 -!- shufflepuff [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Client Quit]     
14:57 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:01 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds]     
15:06 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
15:12 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
15:19 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
15:20 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
15:24 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
15:34 < 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
15:41 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has quit [Ping timeout: 260 seconds]     
15:42 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev     
15:49 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]     
16:01 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:08 < 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
16:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
16:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
16:28 -!- roidster [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
16:53 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
17:06 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
17:15 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 268 seconds]     
17:15 -!- eck [~eck@fsf/member/eck] has quit [Quit: poop]     
17:17 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has joined #bitcoin-core-dev     
17:17 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
17:24 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
17:25 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
17:28 -!- jamesob_ [~james@tempo-automation.static.monkeybrains.net] has quit [Ping timeout: 248 seconds]     
17:30 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
17:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
17:52 -!- deep-book-gk_ [~1wm_su@77.234.41.151] has joined #bitcoin-core-dev     
17:53 -!- deep-book-gk_ [~1wm_su@77.234.41.151] has left #bitcoin-core-dev []     
18:03 -!- altoz [~Jimmy@2605:6000:1017:40c6:54bb:2fc6:541a:2537] has joined #bitcoin-core-dev     
18:06 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
18:07 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
18:09 -!- roidster [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has quit [Ping timeout: 240 seconds]     
18:11 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
18:19 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
18:24 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds]     
18:44 -!- roidster [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
18:44 -!- darawk [~textual@76.79.73.19] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:47 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
19:08 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev     
19:11 < luke-jr> gmaxwell: BIP148's patch is only larger for safety and unit tests. it's much smaller than BIP91 without those.
19:13 < 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
19:13 < gmaxwell> luke-jr: well it does things like preferential peering, for example.
19:13 < luke-jr> right, that's what I mean (partly)
19:14 < luke-jr> fortunately, not ALL users need that, only some
19:14 < luke-jr> the banning-old-nodes part is probably a bigger deal, but the same applies there
19:15 < gmaxwell> as-is has the now-we-have-three-forks problem
19:15 < luke-jr> essentially it's uasfsegwit 0.3 vs 1.0
19:16 < luke-jr> gmaxwell: less likely than if 30% run BIP148-adapted-to-BIP91, 30% run BIP148-as-is, and 40% run non-BIP148
19:16 < luke-jr> no?     
19:16 < luke-jr> at least if it's simply BIP148 or non-BIP148, *users* will be on one or the other
19:17 < gmaxwell> luke-jr: no, because presumably there are foolish people running btc1.
19:17 < luke-jr> not that many?
19:18 < gmaxwell> no, but we can't tell for sure.
19:20 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.]     
19:20 < luke-jr> seems the binary choice (plus btc1) is only *at worst* equivalent to the trinary choice, and at best, an improvement
19:20 < luke-jr> too many people disagree with the adjusted-BIP148 it seems, to reduce to a binary choice there
19:25 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has quit [Quit: Page closed]     
19:26 < luke-jr> am I missing something still?
19:28 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 268 seconds]     
19:30 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
19:51 < praxeology> gmaxwell: what do you want to do? just stick w/ the current release?
20:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
20:02 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has joined #bitcoin-core-dev     
20:02 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has quit [Client Quit]     
20:13 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
20:14 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
20:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
20:14 < 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?
20:16 < 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
20:18 < 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
20:18 < 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.
20:20 < 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.
20:21 < btcdrak> s/is idea/isn't ideal/
20:23 < 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
20:24 -!- PRab [~chatzilla@c-68-56-234-28.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
20:24 < luke-jr> btcdrak: without enforcement, you lose full node security
20:25 < 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
20:25 < praxeology> luke-jr: what do you mean you lose full node security?
20:26 < praxeology> you are still fully verifying the money supply
20:26 < luke-jr> praxeology: full node security means you enforce ALL the rules
20:26 < praxeology> all of your own rules
20:26 < luke-jr> anything less than all, is effectively nothing
20:26 < sipa> luke-jr: i disagree with that
20:27 < praxeology> BIP91 rules are not/never were my rules.  I only heard about it yesterday when I was checking up on BIP 148 status
20:27 < sipa> (especially if you're not doing anything based on low confirmation count)
20:27 < luke-jr> praxeology: yet if you don't enforce it, you lose security
20:28 < 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
20:28 < luke-jr> sipa: if you're trusting miners, that's pSPV, not full node. or do you mean something else?
20:29 < sipa> luke-jr: yes, you're trusting them for some rules
20:29 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lcuyieiwfvopotkk] has quit [Quit: Connection closed for inactivity]     
20:30 < luke-jr> how is some any different from all, practically speaking?
20:30 < praxeology> One only need enforce rules that oneself cares about
20:30 < praxeology> if others enforce more rules, it does not matter to you
20:31 < 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
20:31 < praxeology> its only a short term problem w/ orphaning blocks
20:32 < 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
20:32 < luke-jr> hm     
20:34 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
20:40 < 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
20:40 < morcos> B/c that means the more sure we are that it is the actual rules
20:40 < morcos> If we think there might be all kinds of shenanigans, maybe we just want to stay clear of these rushed consenus chicken games
20:41 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:a94b:71fe:55c6:b5bb] has joined #bitcoin-core-dev     
21:14 -!- roidster [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.40/20160120202951]]     
21:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
21:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
21:33 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
21:35 -!- CubicEarth [~cubiceart@host-69-144-45-132.static.bresnan.net] has joined #bitcoin-core-dev     
21:49 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
21:54 -!- harrymm [~wayne@118-163-168-64.HINET-IP.hinet.net] has quit [Remote host closed the connection]     
21:57 -!- harrymm [~wayne@61-216-163-33.HINET-IP.hinet.net] has joined #bitcoin-core-dev     
22:20 -!- CubicEarth [~cubiceart@host-69-144-45-132.static.bresnan.net] has quit [Remote host closed the connection]     
22:31 < 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
22:37 < 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.
22:41 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
23:03 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
23:19 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:19 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:20 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:20 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:20 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:21 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:21 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:21 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:22 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:22 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:23 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:23 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:24 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:24 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:24 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:25 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:25 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:25 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:26 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:26 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
23:26 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:27 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:27 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:28 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:28 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:28 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
23:29 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
23:33 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
23:42 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has quit [Ping timeout: 248 seconds]     
23:43 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev     
23:47 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
23:47 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev     
23:51 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
23:54 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 246 seconds]     
23:55 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev