--- Day changed Wed May 17 2017 00:12 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/541199788c10...9390845c53e3 00:12 < bitcoin-git> bitcoin/master bc63d0e Pedro Branco: Add query options to listunspent rpc call 00:12 < bitcoin-git> bitcoin/master 9390845 Wladimir J. van der Laan: Merge #8952: Add query options to listunspent RPC call... 00:15 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:31 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 00:33 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 01:03 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 272 seconds] 01:05 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 01:07 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 01:13 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 01:21 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 245 seconds] 01:25 -!- tripleslash [~triplesla@173-165-23-217-Illinois.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 01:25 -!- tripleslash [~triplesla@173-165-23-217-Illinois.hfc.comcastbusiness.net] has quit [Changing host] 01:25 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 01:28 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:44 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] 01:45 < bitcoin-git> [bitcoin] fanquake closed pull request #9403: Don't ask for TX relay from feeler connections (master...NoRelayForFeelers) https://github.com/bitcoin/bitcoin/pull/9403 01:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:46 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9390845c53e3...08ac35a7e3ef 01:46 < bitcoin-git> bitcoin/master 0f1b26a Ryan Havar: Fix docs (there's no rpc command setpaytxfee) 01:46 < bitcoin-git> bitcoin/master 08ac35a Wladimir J. van der Laan: Merge #10413: Fix docs (there's no rpc command setpaytxfee)... 01:47 < bitcoin-git> [bitcoin] fanquake closed pull request #9704: Store downloaded blocks prior to shutdown. (master...StoreBlocksAtShutdown) https://github.com/bitcoin/bitcoin/pull/9704 01:47 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 01:49 < fanquake> wumpus I'm just closing a bunch of PRs that haven't garnered any discussion and/or have needed rebasing for some time. 01:50 < wumpus> fanquake: thanks! 01:50 < bitcoin-git> [bitcoin] fanquake closed pull request #8958: Improve logic for advertising blocks (master...BetterBroadcastLogic) https://github.com/bitcoin/bitcoin/pull/8958 01:51 -!- Aaronvan_ [~AaronvanW@5.79.76.38] has joined #bitcoin-core-dev 01:52 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/08ac35a7e3ef...0542978aae12 01:52 < bitcoin-git> bitcoin/master 2f84cf6 Wladimir J. van der Laan: tests: Correct testcase in script_tests.json for large number OP_EQUAL... 01:52 < bitcoin-git> bitcoin/master 0542978 Wladimir J. van der Laan: Merge #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL... 01:52 < bitcoin-git> [bitcoin] laanwj closed pull request #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL (master...2017_05_scriptnum_test) https://github.com/bitcoin/bitcoin/pull/10405 01:53 < wumpus> gmaxwell: any idea what caused the corruption? 01:54 < wumpus> darn it's in a log file, ideally it would regard CRC errors in the log simply as truncation 01:54 < gmaxwell> I think likely just many unclean power offs.. 01:54 < gmaxwell> I think it does at a lower sanity checking level. 01:54 < wumpus> there's nothing to be done if a corruption happens in a ldb, but in the log it would be fine to just roll back for our use case 01:54 < wumpus> right 01:55 < bitcoin-git> [bitcoin] fanquake closed pull request #9091: Optimize sending of getheaders when pindexLast is an ancestor of pindexBestHeader (master...OptimizeMoreGetheaders) https://github.com/bitcoin/bitcoin/pull/9091 02:06 < fanquake> wumpus got a utACK from cfields on #7522, did you want to merge it? 02:06 < gribble> https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub 02:06 < wumpus> ah yes let's merge it 02:07 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0542978aae12...d25449f85862 02:07 < bitcoin-git> bitcoin/master e98e3dd Luke Dashjr: Bugfix: Only use git for build info if the repository is actually the right one... 02:07 < bitcoin-git> bitcoin/master df63490 Luke Dashjr: Merge tag 'branch-0.13' into bugfix_gitdir 02:07 < bitcoin-git> bitcoin/master ed1fcdc Luke Dashjr: Bugfix: Detect genbuild.sh in repo correctly 02:11 < fanquake> wumpus Looks like #10319 is good to merge also. 02:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10319 | Remove unused argument from MarkBlockAsInFlight(...) by practicalswift · Pull Request #10319 · bitcoin/bitcoin · GitHub 02:12 < wumpus> fanquake: yep 02:13 < wumpus> fanquake: I wasn't sure there, because I'm fairly sure that argument was only added recently 02:13 < wumpus> then again if that function, nor any of its callees use the chain info, and there are no plans to, there's no use in passing it 02:14 < wumpus> maybe we should ask jtimon 02:14 < wumpus> not that I'd mind just merging it, but I don't want to sabotage anyone's work in progress 02:15 < wumpus> ok I see sdaftuar added it and now is ok with removing it 02:15 < fanquake> wumpus ok. I'll ping him in that PR. 02:16 < wumpus> fanquake: not necessary, I think 02:16 < wumpus> he's not involved with this one 02:16 < fanquake> wumpus All good then. #10388 should also be ok to merge. 02:16 < gribble> https://github.com/bitcoin/bitcoin/issues/10388 | Output line to debug.log when IsInitialBlockDownload latches to false by morcos · Pull Request #10388 · bitcoin/bitcoin · GitHub 02:17 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d25449f85862...32f671b14107 02:17 < bitcoin-git> bitcoin/master 6345f0b practicalswift: Remove unused argument from MarkBlockAsInFlight(...) 02:17 < bitcoin-git> bitcoin/master 32f671b Wladimir J. van der Laan: Merge #10319: Remove unused argument from MarkBlockAsInFlight(...)... 02:17 < bitcoin-git> [bitcoin] laanwj closed pull request #10319: Remove unused argument from MarkBlockAsInFlight(...) (master...remove-unused-argument) https://github.com/bitcoin/bitcoin/pull/10319 02:18 < wumpus> yep 02:18 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/32f671b14107...526e8390e6be 02:18 < bitcoin-git> bitcoin/master 65d484a Alex Morcos: Output line to debug.log when IsInitialBlockDownload latches to false 02:18 < bitcoin-git> bitcoin/master 526e839 Wladimir J. van der Laan: Merge #10388: Output line to debug.log when IsInitialBlockDownload latches to false... 02:19 < bitcoin-git> [bitcoin] laanwj closed pull request #10388: Output line to debug.log when IsInitialBlockDownload latches to false (master...printIBD) https://github.com/bitcoin/bitcoin/pull/10388 02:20 < bitcoin-git> [bitcoin] fanquake closed pull request #9325: Allow first cmpctblock/blocktxn received to be processed (rather than first requested) (master...ProcessFirstCmpct) https://github.com/bitcoin/bitcoin/pull/9325 02:23 < fanquake> Good amount of Boost code being removed pre 0.15. 02:32 < fanquake> Recent CVE (CVE-2017-8798) in miniupnpc. Committed fix: https://github.com/miniupnp/miniupnp/commit/f0f1f4b22d6a98536377a1bb07e7c20e4703d229 02:34 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 02:37 < fanquake> This has more information and references bitcoind 0.14.1 (linux) & bitcoind 0.13.2 (windows) https://github.com/tintinweb/pub/tree/master/pocs/cve-2017-8798 02:38 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Changing host] 02:38 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 02:39 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 260 seconds] 02:46 < bitcoin-git> [bitcoin] fanquake opened pull request #10414: [depends] miniupnpc 2.0.20170509 (master...depends-miniupnpc-2-0-20170509) https://github.com/bitcoin/bitcoin/pull/10414 03:02 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 03:40 < wumpus> fanquake: yes, another (possibly exploitable) miniupnpc vuln, happy we don't have enabled by default anymore, still yes we should bump the version 03:54 < bitcoin-git> [bitcoin] practicalswift opened pull request #10415: [fuzz] Speed up fuzzing by ~200x when using afl-fuzz (master...fast-afl-fuzzing) https://github.com/bitcoin/bitcoin/pull/10415 04:21 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:23 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:24 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:25 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:27 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:28 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:31 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:32 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:33 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:34 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:35 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:36 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:37 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:38 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:39 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:40 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:41 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:43 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:45 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:46 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:47 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:49 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:50 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:51 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:52 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:52 < SopaXorzTaker> Uhm, guys?.. 04:53 < SopaXorzTaker> we have a problem - P2SH addresses only depend on the security of RIPEMD-160 04:53 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 04:53 < wumpus> please, #bitcoin 04:54 < SopaXorzTaker> and that means that if a preimage attack is found, it'd be trivial to make a script that would verify and return, and spend any P2SH address 04:54 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Ping timeout: 246 seconds] 04:54 < wumpus> again, #bitcoin, this is not the place to discuss the protocol in general 04:54 < SopaXorzTaker> banned from #bitcoin for spreading bullsh*t 04:56 -!- cypherbit [~tiago@pD9FD6EAE.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 05:03 < cypherbit> join bitcoin 05:08 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 05:10 -!- cypherbit [~tiago@pD9FD6EAE.dip0.t-ipconnect.de] has quit [Quit: leaving] 06:06 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 06:12 < jtimon> paveljanik: morcos asked not to remove the argument, so probably just renaming the argument is the less disruptive thing 06:31 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:31 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 06:31 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 06:32 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:33 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 06:33 -!- cryptapus is now known as cryptapus_afk 06:35 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 06:35 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:37 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:39 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:39 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 06:40 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:40 < fanquake> jonasschnelli Your PR/Nightly build server is pretty fancy now. Good work. 06:40 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 06:40 < jonasschnelli> fanquake: heh. Yeah... UI matters. :) 06:42 < fanquake> I can remember when it was basically a file directory. A lot more useful information now! 06:43 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:44 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 06:46 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:47 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:48 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:50 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 06:51 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:52 -!- JackH [~laptop@85.219.170.195] has joined #bitcoin-core-dev 06:52 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:53 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:54 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:54 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 246 seconds] 06:55 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 06:58 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:01 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 07:11 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:14 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 07:14 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:17 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 07:19 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 07:19 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nkaqwqnwixawvpnl] has quit [Quit: Connection closed for inactivity] 07:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 07:31 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 07:36 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection] 07:37 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-core-dev 07:43 < timothy> hi, I know I should download Xcode etc, but apple.com is slow from here (like 4 hour to download it) so can someone give me MacOSX10.11.sdk.tar.gz? 07:46 < luke-jr> timothy: it's technically illegal to redistribute :/ probably better off just waiting 07:46 < luke-jr> timothy: btw, you're the Arch package maintainer, right? I had heard the packages were outdated (but that was a while ago..) 07:50 < midnightmagic> It's also not really worth much if you take a closed-source distribution package from some rando on IRC. :-) 08:01 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving] 08:03 < timothy> midnightmagic: not really, in gitian files there is the sha256sum of the tar 08:04 < timothy> b49f056b0a3d88cb4def52aa612dc23084eade8699f853f68b4a4456daa7ddb6 MacOSX10.11.sdk.tar.gz 08:04 < timothy> if it's the same for anybody 08:08 -!- molz_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 08:08 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 08:11 < morcos> paveljanik: it always took an argument, and i asked jtimon not to remove it, b/c i thought that in trying to avoid small outputs in the wallet we might want to call that function with a different argument 08:12 < jonasschnelli> sipa: Would support for Bech32 without hrp make sense in the ref. impl? 08:12 < morcos> i'm not positive thats how we'll end up doing it or when, so i don't feel strongly, but yeah probably easier just to rename for now 08:12 < jonasschnelli> sipa: it's a simple change and allow to reuse Bech32 for other stuff... 08:13 < jonasschnelli> (where size matters) 08:14 < gmaxwell> jonasschnelli: without the HRP you'll decode strings for one application as correct for another-- mooting the fancy protection. 08:15 < jonasschnelli> gmaxwell: A single magic 5bit value inside the Bech32 would save 1char (the separator)... 08:15 < jonasschnelli> But maybe I'm wrong. 08:16 < jonasschnelli> I don't say we should throw it away.. just maybe the ref. impl. could support enc/dec Bech32 without the hrp 08:17 < jonasschnelli> (working on a use case where size really matters) 08:21 < gmaxwell> can't you prefill the prefix? 08:22 < midnightmagic> timothy: pretty sure it's not, unless there's some new tarball-maker for that..? 08:29 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 268 seconds] 08:30 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 08:31 -!- adiabat [~adiabat@45.63.20.152] has quit [Remote host closed the connection] 08:33 < jonasschnelli> gmaxwell: avoiding the HRP would allow to use something like "t<14-chars-bech32>" (magic inside the Bech32 encoding) instead of "t1<14-chars-bech32"), would save one char. 08:33 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 08:35 -!- rgod [~rgod@12.20.48.10] has joined #bitcoin-core-dev 08:36 < jonasschnelli> But I guess I'm again micro-optimizing... so nm 08:37 -!- adiabat [~adiabat@45.63.20.152] has joined #bitcoin-core-dev 08:43 -!- rgod [~rgod@12.20.48.10] has quit [Remote host closed the connection] 08:49 < sipa> jonasschnelli: i would suggest you don't change the reference implementation, but just prefix a constant HRP before calling it 08:49 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:50 < jonasschnelli> sipa: Aha. Now I understand... yes. Much simpler. 09:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds] 09:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rwctbmeirxruchyp] has joined #bitcoin-core-dev 09:18 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds] 09:18 < wumpus> I created a new signing subkey (same master key) - hopefully this will just work, but anyhow giving a heads up here in case the verify-sigs script starts ringing alarm bells 09:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 09:20 < wumpus> you might have to refresh my key in any case 09:22 < gmaxwell> jonasschnelli: sorry, thats what I meant by prefill the prefix. 09:23 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 09:24 < jonasschnelli> gmaxwell. Thanks... Came to the conclusion that using the HRP (and conform to Bech32 in BIP0173) may be better then saving a single char. 09:24 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Excess Flood] 09:24 < jonasschnelli> wumpus: Thanks for the info 09:24 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 09:44 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 09:44 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:45 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Read error: Connection reset by peer] 09:46 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 09:51 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 09:52 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/526e8390e6be...ea1fd43bb9a3 09:52 < bitcoin-git> bitcoin/master d4668f3 Jimmy Song: [test] Add test for getmemoryinfo... 09:52 < bitcoin-git> bitcoin/master ea1fd43 Wladimir J. van der Laan: Merge #10257: [test] Add test for getmemoryinfo... 09:52 < bitcoin-git> [bitcoin] laanwj closed pull request #10257: [test] Add test for getmemoryinfo (master...test_getmemoryinfo) https://github.com/bitcoin/bitcoin/pull/10257 09:55 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 09:58 < paveljanik> jtimon, morcos: OK, will PR it later to prevent warning with your comments included for future reference. 09:58 < paveljanik> (or someone else can do it ;-) 10:11 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:13 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 10:14 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:16 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 10:28 < bitcoin-git> [bitcoin] achow101 opened pull request #10417: BIP 148 support (master...master-BIP148) https://github.com/bitcoin/bitcoin/pull/10417 10:31 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:43 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev 10:53 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining] 11:02 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 11:03 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 11:31 -!- btcdrak [uid229044@gateway/web/irccloud.com/x-gkcjolkaivstskuj] has joined #bitcoin-core-dev 11:33 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection] 11:35 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev 11:44 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 11:47 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 11:48 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 11:48 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 11:49 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection] 11:51 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev 11:58 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ea1fd43bb9a3...e61fc2d7cb4f 11:58 < bitcoin-git> bitcoin/master af5d48c fanquake: [depends] miniupnpc 2.0.20170509 11:58 < bitcoin-git> bitcoin/master e61fc2d Wladimir J. van der Laan: Merge #10414: [depends] miniupnpc 2.0.20170509... 11:59 < bitcoin-git> [bitcoin] laanwj closed pull request #10414: [depends] miniupnpc 2.0.20170509 (master...depends-miniupnpc-2-0-20170509) https://github.com/bitcoin/bitcoin/pull/10414 11:59 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8adf75e6a124267da1ae46be1eee50c52ce6082b 11:59 < bitcoin-git> bitcoin/0.13 8adf75e fanquake: [depends] miniupnpc 2.0.20170509... 12:12 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection] 12:27 -!- harrymm [~wayne@45.56.152.24] has joined #bitcoin-core-dev 12:42 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 12:43 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 12:43 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 12:58 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev 13:15 < bitcoin-git> [bitcoin] sipa pushed 16 new commits to master: https://github.com/bitcoin/bitcoin/compare/e61fc2d7cb4f...318ea50a1c2f 13:15 < bitcoin-git> bitcoin/master c0a273f Alex Morcos: Change file format for fee estimates.... 13:15 < bitcoin-git> bitcoin/master e5007ba Alex Morcos: Change parameters for fee estimation and estimates on all 3 time horizons.... 13:15 < bitcoin-git> bitcoin/master d3e30bc Alex Morcos: Refactor to update moving average on fly 13:16 < bitcoin-git> [bitcoin] sipa closed pull request #10199: Better fee estimates (master...smarterfee) https://github.com/bitcoin/bitcoin/pull/10199 13:23 < morcos> sipa: yikes! thanks, i think 13:25 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/318ea50a1c2f...bee35299716c 13:25 < bitcoin-git> bitcoin/master acc2e4b Suhas Daftuar: Bugfix: PrioritiseTransaction updates the mempool tx counter... 13:25 < bitcoin-git> bitcoin/master 6c2e25c Suhas Daftuar: [qa] Test prioritise_transaction / getblocktemplate interaction 13:25 < bitcoin-git> bitcoin/master bee3529 Pieter Wuille: Merge #10196: Bugfix: PrioritiseTransaction updates the mempool tx counter... 13:26 < bitcoin-git> [bitcoin] sipa closed pull request #10196: Bugfix: PrioritiseTransaction updates the mempool tx counter (master...2017-04-prioritise-transaction) https://github.com/bitcoin/bitcoin/pull/10196 13:29 -!- jcliff42_ [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev 13:32 -!- jcliff4__ [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev 13:32 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Ping timeout: 260 seconds] 13:33 -!- jcliff42_ [~jcliff42@4.16.87.162] has quit [Ping timeout: 260 seconds] 13:37 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 13:37 -!- berndj [~berndj@mail.azna.co.za] has quit [Remote host closed the connection] 13:38 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 13:45 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 13:48 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 13:50 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 13:51 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 13:52 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 246 seconds] 13:53 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 13:54 < achow101> would it be possible to ban wewillfindyou? He's derailing and possibly trolling #10417 13:54 < gribble> https://github.com/bitcoin/bitcoin/issues/10417 | BIP 148 support by achow101 · Pull Request #10417 · bitcoin/bitcoin · GitHub 13:54 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 13:56 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 13:57 < Chris_Stewart_5> luke-jr: My concern with implementing BIP148 is that BU (which is 40% of the hash rate) would unknowingly select segwit txs for creating a block. If they rebased onto 0.14.x GBT would not select segwit txs if it was not enabled 13:57 < sipa> achow101: done 13:57 < achow101> ty 13:57 < sipa> Chris_Stewart_5: signalling for BU != running BU 13:58 < achow101> Chris_Stewart_5: they shouldn't select segwit txs though since they are non-standard under current rules 13:59 < Chris_Stewart_5> achow101: P2SH(P2WPKH or P2WSH) would be wouldn't it? 13:59 < sipa> Chris_Stewart_5: no 14:00 < sipa> those still require a spend that violates the CLEANSTACK rule 14:00 < sipa> which has been in every release since 0.11 14:00 < achow101> the transactions creating the p2sh nested outputs themselves are find and can be mined. the spending transaction is not 14:00 < achow101> s/find/fine/ 14:01 -!- jcliff4__ [~jcliff42@4.16.87.162] has quit [Remote host closed the connection] 14:01 < luke-jr> (and mining those p2sh txs won't be a problem for the BU blocks) 14:10 < BlueMatt> luke-jr: this is absurd, do you seriously believe the vast, vast majority of bitcoin users (incl businesses) support bip 148? 14:10 < gmaxwell> he believes they support segwit, which is super clear at this point. 14:11 < BlueMatt> bip 148 != segwit, they are different proposed consensus changes, despite sharing many features 14:11 < luke-jr> BlueMatt: businesses exist to serve the users 14:11 < gmaxwell> yea, I'm not arguing that they're the same, just trying to clarify luke's position the way I understand it. 14:11 < luke-jr> BlueMatt: and so far, the businesses are taking a hardline position of "we will run Core only" 14:11 < gmaxwell> Chris_Stewart_5: No it won't. 14:12 < luke-jr> which is half the reason we need to merge it in Core 14:12 < luke-jr> if businesses weren't being stupid about this, I'd prefer BIP148 activate without Core. but reality is what it is 14:12 < BlueMatt> businesses are also users of the system, especially the many that do not expose bitcoin to their users, and there is clearly not vast, broad support for bip 148 in that community even *if* core merges it 14:14 < luke-jr> the only "opposition" (besides trolls) I see to BIP148, is the mistaken belief that it won't or can't work 14:14 < gmaxwell> it's very disruptive if it isn't an overwhelming success. 14:14 < sipa> it can only work if everyone adopts it 14:14 < sipa> it is not our job to push for that 14:15 < luke-jr> gmaxwell: which is why it's important to ensure it's an overwhelming success. 14:15 < BlueMatt> it is not bitcoin core's job to merge something *until* that exists, irrespective of whether individual contributors are pushing for it 14:15 < luke-jr> BlueMatt: until what exists? 14:16 < BlueMatt> ovherwhelming support across the ecosystem 14:16 < luke-jr> that pretty much exists to the extent it can without Core merging it. 14:16 < luke-jr> businesses will run whatever Core releases, and won't run what Core won't release. 14:16 < luke-jr> it sucks, but that's how it is right now 14:17 < sipa> and they do that, hopefully because they believe we're making sane choices of what is included in a release 14:17 < BlueMatt> luke-jr: ok, please go email every business you can find an email for and ask them if they support bip 148 activation on date X 14:17 < BlueMatt> plus as many polls as you can possibly create at physical meetups 14:17 < BlueMatt> and then get back to me 14:18 < luke-jr> sipa: missing the point. it creates chicken-and-egg 14:19 < BlueMatt> not entirely, the chicken-and-egg problem can be solved by active outreach 14:19 < gmaxwell> BlueMatt: hopefully not your intent, but you did just make it sound like only business mattter. 14:19 < BlueMatt> something that I have yet to see literally any of 14:19 < BlueMatt> gmaxwell: fair, yes, that tis not at all my intent, hence the mention of physical meetups 14:19 < luke-jr> BlueMatt: no, because the businesses will NEVER run BIP148 until Core merges it 14:20 < BlueMatt> businesses do matter, but, indeed, only as much as every other group 14:20 < BlueMatt> luke-jr: we did it with segwit and got back overwhelmingly positive response! 14:20 < BlueMatt> prior to the parameters being merged 14:20 < luke-jr> besides half the businesses supporting Classic back then.. 14:20 < BlueMatt> we got back 0 negative responses 14:21 < BlueMatt> 0 14:21 < BlueMatt> on top of people doing physical outreach and talking to various groups at meetups, plus discussions with long-time bitcoin holders and investors 14:21 < gmaxwell> BlueMatt: no, not true, we got a response from one webwallet vendor saying they prefer it be delayed a few months. 14:21 < gmaxwell> BlueMatt: the was the only negative response.. And I got more than a 50% response rate. 14:22 < BlueMatt> yes, sorry, we got one "please delay, because I'm worried about other people" response, though not worried about themselves, and only a request for delay, not a request for "no" 14:22 < BlueMatt> well, ok, mostly you got, but ok :) 14:22 < gmaxwell> no, actually it was a "we would be put at a competative disadvantage because other people integrated segwit support already and we haven't started" not "other people". 14:23 < BlueMatt> oh, somehow i misrecalled, sorry 14:24 < luke-jr> ok.. so because we don't have business consensus in advance, Core should take a hardline position that puts users at more risk? 14:24 < sipa> luke-jr: i personally don't believe BIP148 will happen 14:24 < luke-jr> sipa: it will, even if it is a minority chain splitting off 14:25 < BlueMatt> business + broad user study 14:25 < sipa> i expect that a number of people will run it, it won't activate, they'll be forked off, and they'll revert to running non-BIP148 code within hours 14:25 < sipa> if core merges bip148 as a default option, it will just make people run other software instead, and the same will happen 14:26 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 14:26 < luke-jr> people who are making a conscious decision on what software to run, are switching to BIP148 nodes or at least uacomments 14:26 < sipa> this is my expectation, and i certainly may be wrong 14:26 < BlueMatt> luke-jr: do you not agree that we should be, above all, absolutely and strictly requiring consensus for any consensus rule changes? 14:26 < luke-jr> BlueMatt: not for softforks, no. otherwise Segwit should never have been merged. 14:27 < BlueMatt> bip 148 has many of the upgrade properties of a hf 14:27 < luke-jr> Segwit is absolutely contentious. But it has sufficient support to merge as a softfork. 14:27 < BlueMatt> from that perspective bip 148 is closer to a hf than a sf, by far 14:27 < sipa> luke-jr: and bip148 obviously does not 14:27 < BlueMatt> segwit contention is overstated, in my experience 14:27 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 240 seconds] 14:27 < sipa> luke-jr: i don't understand why we're even discussing this 14:27 < luke-jr> I don't agree. BIP 148 only needs a majority to avoid a split. 14:27 < Anduck> maybe core should publish two versions. 14:27 < luke-jr> Anduck: there's an interesting idea 14:27 < BlueMatt> Anduck: we do *not* ship code with a massive face cannon built in 14:28 < BlueMatt> you're welcome to, however :p 14:28 < BlueMatt> luke-jr: then you're talking about a masf again..why not tell miners to just 51% attack and turn on segwit in the current signaling, then? 14:28 < BlueMatt> but, yea, I'm with sipa, this is fucking stupid 14:28 < Anduck> it's indeed tough. SF-SW itself can be seen as "bad" because it relies on miners.. it's all very hard 14:28 < luke-jr> BlueMatt: telling miners is very different from economically forcing their hand 14:29 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 255 seconds] 14:29 < luke-jr> especially when the miners are already hostile and attacking the network 14:29 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 14:30 < BlueMatt> Anduck: no, its safety is somewhat redundant - if the vast, vast majority of nodes upgrade you're fine, if, otoh, the vast majority of miners upgrade, you're also fine. as things normalize (no one's gonna put money into segwit until nodes + miners are enfocing it) it'll become useable, but the fork and coin-loss risk is mitigated somewhat thanks to redundant protections there 14:30 < BlueMatt> this it not true for bip 148, just as it is not true for a hf 14:30 -!- sdf_0010 [~steven@173.239.11.108] has joined #bitcoin-core-dev 14:30 < BlueMatt> luke-jr: great, so go talk to the exchanges and merchants where miners sell their coins and tell them to switch 14:30 < BlueMatt> I'm happy to help intro you to folks if you dont know most of them 14:31 < Anduck> BlueMatt: yeah, that's true 14:31 < luke-jr> BlueMatt: another dev has already tried this, and found they will only if Core releases it.. 14:31 < BlueMatt> well then they're expecting us to do the job of figuring out what the community's consensus on bitcoin's consensus rules is, and it is clearly not bip 148 14:32 < BlueMatt> so sounds like you got a "no" 14:32 < luke-jr> it's not clearly "yes", but it's certainly far from clearly "no" 14:33 < luke-jr> the community seems very much in favour of it, with a positive trent 14:33 < luke-jr> trend* 14:33 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-core-dev [] 14:33 < BlueMatt> if they're, otoh, expecting "Core" to decide consensus rules for the bitcoin ecosystem, then they can also clearly fuck off 14:33 < BlueMatt> that is not the same as consensus? 14:33 < luke-jr> Segwit doesn't have consensus. 14:33 < BlueMatt> if you could honestly tell me that everyone supported bip 148, including those who support it if we merge it, then fine, but you cant 14:33 < BlueMatt> and if you're claiming you can, please pull your head out of your ass 14:34 < luke-jr> I'd say it seems pretty similar to segwit itself. 14:34 < BlueMatt> you think bip 148 has the same level of support as segwit?! 14:34 < BlueMatt> i refer you to my previous comment about bodily orifices 14:34 < luke-jr> maybe slightly less, but it seems to be pretty close 14:35 < BlueMatt> (and the differences between SFs and uasfs) 14:36 < Anduck> well, it's obvious that community wants segwit. now the big question is just how to deploy it 14:36 < Anduck> apparently masf is not working because some small part of community can keep it not happening 14:38 < BlueMatt> well activation method is a key part of any consensus rule change proposal 14:39 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 255 seconds] 14:42 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 14:43 < gmaxwell> My view: Community and industry overwhelmingly want segwit. Given that 14:43 < gmaxwell> BIP148 is also something they would want but IF and only IF most everyone 14:43 < gmaxwell> else wants it. (because it's disruptive if partial). So there is a symmerty 14:43 < gmaxwell> breaking problem. Either ~everyone or ~no one should want it. 14:44 < gmaxwell> So if a sufficiently high profile group said they would do it, they'd 14:44 < gmaxwell> probably break the symmetry. But we really don't want it to be us 14:44 < gmaxwell> in particular because it would feed the FUD that core controls this 14:44 < gmaxwell> or that (when really the whole thing would work because the support 14:44 < gmaxwell> for segwit is already overwhelming). Unfortunately, everyone else 14:44 < gmaxwell> who would be a potential symmetry breaker has a starting disadvantage: 14:44 < gmaxwell> they're not known and trusted for pruducing software and BIP148 14:44 < gmaxwell> needs software. We could ship BIP148 switchable and defaulted to 14:44 < gmaxwell> off but this raises a concern why not some other change: I would 14:44 < gmaxwell> point out that the ONLY argument against BIP148 given what we know 14:44 < gmaxwell> is that other people might not run it and the people who do run it 14:44 < gmaxwell> may be disrupted.. this doesn't hold for 12345MB blocks or whatever, 14:44 < gmaxwell> as there are solid issues there indpendant of the level of 14:44 < gmaxwell> popular support. 14:44 < gmaxwell> I've heard directly from people trying to push for BIP148 that they 14:44 < gmaxwell> felt undermined by the project's lack of implementation of the 14:44 < gmaxwell> mechenism. 14:45 < BlueMatt> I'm happy to ship code with an #ifdef NEVER_DEFINED_BIP148_IMPL_FLAG, but, otherwise, yes, totally agree with the above 14:46 -!- jcliff42 [~jcliff42@4.16.87.162] has joined #bitcoin-core-dev 14:47 < sdf_0010> what is the reason for core not including BIP148 or similar as a switch defaulting to off? 14:48 < BlueMatt> sdf_0010: we dont ship software with a -maybeblowmyfaceoff=true option 14:48 < BlueMatt> sorry, we just dont 14:49 -!- jcliff42 [~jcliff42@4.16.87.162] has quit [Remote host closed the connection] 14:49 < luke-jr> but not enforcing BIP 148 is more "blow my face off" than enforcing it :/ 14:50 < luke-jr> (also, I'm pretty sure I can find such a flag.. but not the point :p) 14:50 < sdf_0010> it's hard to even take BlueMatt seriously if he is going to use such ridiculous language 14:51 < Anduck> BlueMatt: bip148 version "flavor" could be handed by core anyway. just with proper warnings everywhere, and good reasoning why core is making it 14:51 < achow101> gmaxwell: BlueMatt could you guys give me the list of emails of businesses? I would be happy to ask them if they would support BIP 148 14:51 < sdf_0010> we don't because 'i say so' isn't really a compelling point nor is the statement that this will blow off a users face. what are you going to walk over to every user running this on their system and take a shutgun to their face? 14:52 < Anduck> ... 14:52 < BlueMatt> Anduck: see my comment above. if the goal is to have some level of code review and assurance that it is a reasonable set of code changes, then I think we should merge it behind an ifdef flag that is never define and not defineable from configure/make. that way we can say its there, its been vetted, but its not active and not available for people unless they're gonna interpret it as consensus 14:52 < gmaxwell> sdf_0010: he's right, and I agree in general without agreeing in this case. 14:53 < BlueMatt> just like we merged the segwit code without activation flags on 14:53 < gmaxwell> sdf_0010: We will not ship software that we know will screw people over. It is unethical and unprofessional to do so. Our duty of care is to ship things we have validated and believe in. 14:53 < BlueMatt> there was no way to turn it on on mainnet (afair), but the code was all there 14:54 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 14:54 < sdf_0010> this requires people to explicitly set the configuration option that they want. I can already set flags now that would 'blow up my face' ,ie change the default listening to higher than needed 14:54 < gmaxwell> sdf_0010: Though in this case AFAIK it's a bit special in that it's FINE unless other people don't use it. So basically the only argument where it would be unsafe (and quite unsafe indeed) is if its support isn't overwhelming. Yet we believe support for the underlying feature is overwhelming. 14:54 < gmaxwell> sdf_0010: better example is you can set dbcache higher than the amount of ram you have, and you'll crash. 14:55 < BlueMatt> sdf_0010: do you believe we should have an option that sends your private keys to me for analysis? 14:55 < gmaxwell> or you can set your fee levels really stupidly high. 14:55 < gmaxwell> but thats about as close to a suicide button as I think we get. 14:55 < sdf_0010> BlueMatt, are you evne trying to engage me with in a genuine manner? 14:55 < gmaxwell> BlueMatt: but what say you to the point that other people would LOVE to act as that symmetry breaker, but they're hobbled because our community is the software folks? 14:56 < gmaxwell> sdf_0010: he is, don't be fragile. :) 14:56 < BlueMatt> sdf_0010: I was eggagerating slightly to highlight the type of issue here 14:56 < gmaxwell> sdf_0010: bluematt wants to do the right thing, it's not a personal dispute. Don't take it that way. 14:56 < sdf_0010> asking rhetoical questions and pretending they are equivalent to my example is highly idiotic behavior or trollish 14:56 < BlueMatt> gmaxwell: i interpreted that to also be a "software credibility" issue, to which I'm happy to provide credibility by reviewing the code and even merging it behind ifdef comments 14:57 < gmaxwell> achow101: pm me an email address and I'll share the contact sheet I used for segwit outreach. 14:57 < sdf_0010> and i do believe he isn't stupid, but pretending my exmaple and his are equivilent is purely idiotic 14:57 < BlueMatt> sdf_0010: actually, I believe they are highly analygous 14:57 < sdf_0010> haha 14:57 < BlueMatt> sdf_0010: maybe a better comparison is a flag to run bitcoin core on testnet but have everything pretend to be mainnet 14:58 < BlueMatt> i assume you can picture the "how to install bitcoin core" guides where someone tells you to use that flag and then they'll tell you you've been paid 14:58 < BlueMatt> with valueless coins, but you are nonethewiser 14:58 -!- sdf_0010 [~steven@173.239.11.108] has left #bitcoin-core-dev ["Leaving"] 14:58 -!- sdf_0010 [~steven@173.239.11.108] has joined #bitcoin-core-dev 14:58 < BlueMatt> gmaxwell: if that is insufficient, then we should revisit the issue at that point, I believe 14:58 < gmaxwell> BlueMatt: so you would draw a line at ifdef vs a config option even if the config option was labeled with a big warning sign? You know we do have other dangerous options for deployment reasons, e.g. invalidateblock 14:58 < BlueMatt> i dunno, that line is fuzzy, I'd be ok with a configure option that prints a few sentences at you and then makes you wait and then type "yes" to continue :p 14:58 < sdf_0010> BlueMatt, that is a better example except the part where people 'pretend' because unless you really believe the people setting this config option are utterly unthinking beasts I don't see how thye would be 'pretending' anything by setting a behavior they explicitly want 14:59 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 14:59 < BlueMatt> sdf_0010: users are not unthinking, but they, the vast majority at least, do *not* have more than 30 seconds to consider the issues you consider fundamental for them 14:59 < gmaxwell> sdf_0010: part of the problem is that a partial adoption of BIP148 isn't just bad for the people who turned the option on, it's bad for everyone. 15:00 < BlueMatt> sdf_0010: if you're not modelling your users as drunk, you're probably doing it wrong, because the reality is most of your users dont know what the fuck is going on when they first install the software, they're installing it as a part of trying to figure that out, and your software shouldnt make it easy for them to needlessly harm themselves because someone on reddit told them to set flag X while your users are still figuring out wth 15:00 < BlueMatt> bitcoin even is 15:01 < luke-jr> gmaxwell: partial adoption is happening regardless though 15:01 < gmaxwell> like if BIP148 is (say) 99% everyone is happy, even people that didn't use BIP148. If BIP148 is 0% everyone is safe (if not happy). if BIP148 is 50% then the network is split and is a mess for BIP148 and non-148 users a like. 15:01 < gmaxwell> if it's (say) 5% then it's just bad for the BIP148 users. 15:02 < morcos> The fundamental underlying question is what is the goddamn hurry? If the community really supports a UASF for segwit, there will be ample time for that to become clear and us to design the best mechanism possible to roll it out. 15:02 < morcos> BIP148 is essentially hot off the press, and we're already trying to merge it 15:02 < gmaxwell> morcos: +1 15:02 < morcos> This is premature by at least 6 months, if not a year 15:02 < gmaxwell> morcos: we'll be 'we' you mean like luke. :P 15:03 < BlueMatt> yea, that too 15:03 < morcos> well, i just think it shouldn't even be a conversation at this point (about merging). Debating the overal merits makes sense 15:03 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 272 seconds] 15:04 < luke-jr> morcos: BIP148 is 2 months old, and IMO better than any hypothetical alternative; anything else will require a redeployment 15:04 < gmaxwell> yea, I think it's useful to talk through it.. thats how you get to maturity 6months henceforth, as you suggested. 15:04 < gmaxwell> luke-jr: as I've said before, you're really overvaluing the redeployment cost. 15:04 < gmaxwell> Yea, sure, it'll cause developer effort but thats what we signed up for. 15:04 < luke-jr> gmaxwell: I don't think I am. Consider how much additional work segwit required that we didn't anticipate. 15:04 < BlueMatt> yea, luckily the parameter space here is rather well-defined and somewhat limited, so its not a particularly extended discussion, I'd hope 15:05 < gmaxwell> luke-jr: segwit finished astonishingly quickly. 15:06 < luke-jr> what? it was several months later than planned 15:06 < Anduck> morcos: good point. i guess the main hurry comes from btc/usd and altcoin valuations 15:08 < gmaxwell> Anduck: yea, but like, load this page http://coinmarketcap.com/currencies/views/market-cap-by-total-supply/ and tell me that you think thats really a viable position to argue from. 15:08 < gmaxwell> luke-jr: no it was several months later than idiotic estimates. 15:09 < gmaxwell> If you reacall I was pointing out those estimates were absurd in january. 15:09 < gmaxwell> Did you not even listen to the example I gave you earlier about 4 byte ASNs in BGP? It took a _decade_. 15:10 < BlueMatt> *ahem* IPv6 *ahem* 15:10 < gmaxwell> (and FWIW, from a software implementation perspective, 4-byte was pretty similar to segwit support-- even the underlying mechenism would remind you a little of segwit) 15:10 < BlueMatt> did you....segregate the last 2 bytes :p 15:11 < gmaxwell> BlueMatt: well kinda, for 4-byte ASNs the traditional AS path gets placeholder ASNs in it, and then an extension field carries the real AS path data. 15:13 < luke-jr> AFAICT that analogy is about segwit, not BIP148 15:13 < gmaxwell> But the history there was: discussion in 2000. Initial proposal of the idea in 2001. RFC in 2007. Implemented in routers in 2011. First turned on the internet in 2012 (then, due to subtle design flaws, it partioned the internet and required hasty fixes. :) ) 15:13 < gmaxwell> luke-jr: sure but BIP148 is about segwit. 15:13 < gmaxwell> It's about getting segwit deployed faster. 15:13 < luke-jr> BIP148 is about segwit, but BIP148 itself is very simple 15:13 < gmaxwell> yea, BIP148 is very simple, I agree. 15:13 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 15:14 < gmaxwell> But the whole reason for BIP148 is because some people are not happy with how long segwit is taking to activate. I believe that the expectations there are unrealistic. 15:14 < luke-jr> then why didn't we set the timeout later? 15:14 < gmaxwell> even in protocols with far less demands than ours-- like BGP for example-- upgrades take a long time. 15:15 < gmaxwell> luke-jr: because we assumed we could just keep renewing it. 1 year is what BIP9 suggest and seems like a generally reasonable quanta. 15:15 < gmaxwell> No one thought through that for segwit (unlike most SF) it's a bit harder to just renew. Ooops. 15:15 < achow101> gmaxwell: but to keep renewing it requires everyone to upgrade yet again 15:15 < gmaxwell> if not for that I think we'd already have a renewal staged in master. 15:16 < gmaxwell> achow101: yea so? they're going to do that anyways... if you're running 3 year old software you're probably having a poor time from security issues or whatever. :) 15:16 < luke-jr> gmaxwell: I don't see a reason in this, to make BIP148 fail and split the chain. 15:16 < gmaxwell> it's perhaps an argument that the BIP9 timeout default should be more like 2 or three years. 15:17 < gmaxwell> luke-jr: no one has to run BIP148. 15:17 < luke-jr> gmaxwell: a non-trivial amount of the community will be doing so 15:17 * BlueMatt goes back to work 15:18 < Anduck> we see huge support (and compatibility) for segwit in the nodes network. bip-148 wouldn't disrupt them if it forces miners to activate SW. it's a leap of faith in any case. 15:18 * morcos hopes BlueMatt figures out his address problems 15:19 < BlueMatt> morcos: ugh, i started looking at other node behavior and then got distrcated by bullshit 15:23 < Anduck> i think having core-supported possibility to simply switch on bip148 (with all the warnings etc) would really give users the choice. it's a fact a ton of people will never run anything not from core project. passive users would simply not switch on it, but could easily do if they wanted to. they wouldn't understand the implications though, but that's never the point 15:23 < Anduck> so there's quite a big active community who would then switch on it, and maybe cause a disruption. but it's then up to the community if they choose to cause this disruption or not 15:24 < Anduck> and if all goes as planned, there won't be disruption and miners will bend. it's risky, but it's up to the users 15:26 < Anduck> having the option under core name simply helps people to trust the code / idea behind it to be valid. then the only thing for those people (who trust core) is to evaluate the risk of bip148 and whether they want to support it. still a big portion will not understand the risks sufficiently do choose anything 15:28 < Anduck> but this is all reality, i think. have to accept the community knowledge level and do kind of "compromise". power users/devs/companies will always be in charge of the protocol anyway, simply because 95% of users (community?) do not care 15:30 < Anduck> bgp is not comparable to bitcoin because there's no competitor. nobody gains anything if they get bgp replaced by something else 15:33 < Anduck> anyway, even while bip148 may be stupidly risky, there's no point in trying to slow it down. it happens if it happens. running bitcoin node will increasingly require more knowledge of what actual rules does the code follow. there's no point in trying to oppose this from realising 15:42 -!- lichtamberg_ [~Adium@2a02:8388:2040:c880:a846:96c1:cd76:1c83] has joined #bitcoin-core-dev 15:43 < lichtamberg_> As far as I can remember there was also a toggle option for the RBF feature.... And now you want to decide for the users what it's best? 15:43 < lichtamberg_> I cannot understand why there is such a strong stand against a toggle option... 15:43 < lichtamberg_> On one side you are asking for more community participation, and on the other side you are dismissing one of the biggest community movements which bitcoin ever had.. 15:43 < lichtamberg_> And you are also removing the possibility to switch to the correct chain, if BIP148 really gets much traction at the end. With the toggle option, people can switch more or less easily.. without => you are forcing the users to unofficial versions.. most people dont compile bitcoin themself 15:44 < Anduck> in a sense, it's irresponsible to give user an option to fail horribly. 15:45 < lichtamberg_> it's also irresponsible to remove the option if the community support is getting enough traction 15:45 < lichtamberg_> you are only thinking about the failing part… but look on reddit 15:46 < lichtamberg_> a not so small part of the community will go this way 15:47 < Anduck> well, let's forget bip148 for a while. the big question here is what role is core having. will core only support current rules and e.g. updates via masf, or will it offer riskier (hf, bip148-like uasf) options? where's the golden line between these? 15:47 < lichtamberg_> and as far as I know, this is the biggest community movement which we ever saw until now? 15:47 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 15:47 -!- cryptapus is now known as cryptapus_afk 15:48 < Anduck> like, should core offer the best and safest product available and have no comment in ANY kind of protocol updates? 15:49 < Anduck> i think it could be an option. drop all updates from core and have a different branch, maybe "core experimentals" project or something like that. updating protocol becomes tons of harder this way, but also clarifies the roles 15:51 < lichtamberg_> I dont know.. in only think, that if we put it on a general level, it will take much longer than the PR for BIP148 makes sense (because 1th august will be earlier than this decision) 15:53 -!- dermoth [~thomas@dsl-199-102-159-103.mtl.aei.ca] has quit [Ping timeout: 240 seconds] 15:55 < Anduck> e.g. core-currentrules would have masf support for segwit. core-experimentals could try to bend miners arms to do the masf, bip148-way, which could horribly fail too. 15:57 -!- dermoth [~thomas@dsl-66-36-136-163.mtl.aei.ca] has joined #bitcoin-core-dev 15:57 < Anduck> but anyway, the current system is quite good. these are just some ideas to clarify things for the future. there are tons of things to consider but maybe the process should be started soon as updating (and even maintaining) protocol becomes harder and harder in every level 15:58 < luke-jr> Anduck: in this case, it's not "no comment", it's actively anti-BIP148. 15:59 < Anduck> or pro-no-disruption-to-the-system ? 15:59 < Anduck> segwit masf was defined as only activated if miners choose so. it's disruption to change this now 16:00 < luke-jr> Anduck: nope, Core's current anti-BIP148 position increases the disruption 16:00 < Anduck> no matter how sane it would be if it wasn't so disruptive 16:00 < Anduck> luke-jr: well, that's an opinion only. there are tons of factors to consider --most of them are unknown. 16:01 < Anduck> which is why i am trying to push this "nobody knows for sure, so let community find it out, even if it's via try-and-error or some other suboptimal method" 16:02 < Anduck> what i mean by "noboy knows for sure" i mean the things which are simply not measurable in any way, or not analyzable objectively 16:03 -!- Squidicc [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 16:05 < lichtamberg_> I mean.. I also have to say following… If all core members would support BIP148, we could do it really easily.. and I think everyone knows this… But: since you are scared about the core brand, you are too risk averse from my point of view and just try to hide away from it… you are really shitting your pants right now.. sorry… :) 16:05 < Anduck> "If all core members would support BIP148, we could do it really easily" << i disagree. 16:06 < lichtamberg_> i disagree with your disagreement :D 16:06 < lichtamberg_> we have so much support for segwit 16:06 < lichtamberg_> there is such a big hype about UASF 16:06 < lichtamberg_> the only ones which are missing are: the miners (obviously) - and core 16:07 < Anduck> could be that you're right. could be that you're not. i think hype for bip148 is largely hype only. 16:07 < Anduck> reddit is only one small piece of the community. 16:07 < lichtamberg_> hard to measure that, but I dont think so 16:07 < Anduck> i don't see big companies supporting uasf either 16:07 -!- Squidicuz [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds] 16:08 < lichtamberg_> they are just scared to be the first one… first mover effect.. 16:08 < Anduck> anyway i think it should be nobodys job to even try to measure these things. just lay out the options, carefully mark what everything is and what implications whichever code has (as best as possibly one can, and as objectively as possible ofc) 16:09 < Anduck> big warnings. if people ignore it... well, that's simply too bad! worse would've been if people had no option to do the stupid thing, as there would then be party who ONLY offers the bad options 16:09 < Anduck> we've already seen signals about this phenomenon 16:09 < Anduck> not only in bitcoin scene, that is 16:10 < lichtamberg_> yeah i dont know.. i hope that some of the core members are still continueing to contribute to the current process.. at the moment they are cowardly silent unfortunately… (i dont know whats happening behind the doors) - but at the moment core is letting the community alone from my point of view 16:11 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 16:12 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 16:17 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 16:20 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 16:20 -!- harrymm [~wayne@45.56.152.24] has quit [Ping timeout: 240 seconds] 16:21 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 16:24 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 16:24 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Ping timeout: 240 seconds] 16:25 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev 16:27 -!- lichtamberg_ [~Adium@2a02:8388:2040:c880:a846:96c1:cd76:1c83] has quit [Quit: Leaving.] 16:40 -!- harrymm [~wayne@104.237.91.127] has joined #bitcoin-core-dev 16:49 -!- harrymm [~wayne@104.237.91.127] has quit [Remote host closed the connection] 16:53 -!- fengling [~fengling@223.223.187.140] has quit [Ping timeout: 252 seconds] 16:54 -!- fengling [~fengling@223.223.187.140] has joined #bitcoin-core-dev 17:00 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving] 17:00 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:03 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 260 seconds] 17:04 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 17:05 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev 17:12 -!- harrymm [~wayne@45.56.152.28] has joined #bitcoin-core-dev 17:12 -!- harrymm [~wayne@45.56.152.28] has quit [Max SendQ exceeded] 17:12 -!- harrymm [~wayne@45.56.152.28] has joined #bitcoin-core-dev 17:14 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bee35299716c...e317c0d19201 17:14 < bitcoin-git> bitcoin/master 9f7341b Gregory Sanders: Add witness data output to TxInError messages 17:14 < bitcoin-git> bitcoin/master 6e9e026 Gregory Sanders: Expand signrawtransaction.py to cover error witness checking 17:14 < bitcoin-git> bitcoin/master e317c0d Pieter Wuille: Merge #8384: Add witness data output to TxInError messages... 17:23 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e317c0d19201...c33652576ce2 17:23 < bitcoin-git> bitcoin/master 1b936f5 practicalswift: Replace boost::function with std::function (C++11) 17:23 < bitcoin-git> bitcoin/master c336525 Pieter Wuille: Merge #10395: Replace boost::function with std::function (C++11)... 17:23 < bitcoin-git> [bitcoin] sipa closed pull request #10395: Replace boost::function with std::function (C++11) (master...replace-boost-function) https://github.com/bitcoin/bitcoin/pull/10395 17:28 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 17:28 -!- kadoban_ [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 17:28 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 255 seconds] 17:28 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev 17:34 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 268 seconds] 17:36 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c33652576ce2...ae786098bc58 17:36 < bitcoin-git> bitcoin/master ad415bc Thomas Snider: [net] Added SetSocketNoDelay() utility function 17:36 < bitcoin-git> bitcoin/master ae78609 Pieter Wuille: Merge #10061: [net] Added SetSocketNoDelay() utility function... 17:37 < bitcoin-git> [bitcoin] sipa closed pull request #10061: [net] Added SetSocketNoDelay() utility function (master...tjps_nodelay) https://github.com/bitcoin/bitcoin/pull/10061 17:38 < bitcoin-git> [bitcoin] sipa closed pull request #8952: Add query options to listunspent RPC call (master...enhancement/improve-rpc-listunspent) https://github.com/bitcoin/bitcoin/pull/8952 17:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rwctbmeirxruchyp] has quit [Quit: Connection closed for inactivity] 17:44 -!- Aaronvan_ [~AaronvanW@5.79.76.38] has quit [Remote host closed the connection] 17:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:47 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 246 seconds] 17:47 -!- zooko [~chrome@2601:281:8000:9b7b:5430:f504:5a91:40e6] has joined #bitcoin-core-dev 17:48 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 17:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 17:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 17:52 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 17:56 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 18:05 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 18:12 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 18:17 -!- AaronvanW [~AaronvanW@5.79.76.38] has joined #bitcoin-core-dev 18:17 -!- AaronvanW [~AaronvanW@5.79.76.38] has quit [Changing host] 18:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 18:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 18:30 < bitcoin-git> [bitcoin] theuni closed pull request #10285: net: refactor the connection process. moving towards async connections. (master...connman-events6) https://github.com/bitcoin/bitcoin/pull/10285 18:34 -!- zooko [~chrome@2601:281:8000:9b7b:5430:f504:5a91:40e6] has quit [Ping timeout: 260 seconds] 18:37 -!- Squidicuz [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 18:38 -!- Squidicc [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds] 18:39 -!- Squidicc [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 18:39 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds] 18:41 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 18:42 -!- Squidicuz [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds] 18:42 -!- Squidicuz [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 18:45 -!- Squidicc [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds] 18:49 -!- Squidicuz [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer] 18:50 -!- Squidicuz [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 18:50 -!- bitcoinreminder_ [uid220256@gateway/web/irccloud.com/x-thqzpxqfzsabtels] has joined #bitcoin-core-dev 18:50 -!- Squidicuz [~squid@pool-108-26-156-99.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer] 18:54 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 18:57 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 19:00 -!- dermoth [~thomas@dsl-66-36-136-163.mtl.aei.ca] has quit [Read error: Connection reset by peer] 19:01 -!- dermoth [~thomas@dsl-66-36-136-163.mtl.aei.ca] has joined #bitcoin-core-dev 19:08 -!- zooko [~chrome@2601:281:8000:9b7b:5430:f504:5a91:40e6] has joined #bitcoin-core-dev 19:23 -!- kadoban_ is now known as kadoban 19:32 -!- cysm_ [cysm@gateway/shell/elitebnc/x-dmgzouirtsibiivg] has quit [Ping timeout: 255 seconds] 19:34 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 19:34 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 19:35 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 19:37 -!- cysm_ [cysm@gateway/shell/elitebnc/x-pzedjcczpwchzksr] has joined #bitcoin-core-dev 20:09 -!- spinza [~spin@196.212.164.26] has quit [Ping timeout: 240 seconds] 20:16 -!- zooko [~chrome@2601:281:8000:9b7b:5430:f504:5a91:40e6] has quit [Ping timeout: 246 seconds] 20:18 -!- zooko [~chrome@2601:281:8000:9b7b:5430:f504:5a91:40e6] has joined #bitcoin-core-dev 20:36 -!- dermoth [~thomas@dsl-66-36-136-163.mtl.aei.ca] has quit [Read error: Connection reset by peer] 20:54 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 20:56 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds] 20:57 -!- zooko [~chrome@2601:281:8000:9b7b:5430:f504:5a91:40e6] has quit [Ping timeout: 240 seconds] 21:05 -!- spinza [~spin@196.212.164.26] has joined #bitcoin-core-dev 21:17 -!- bitcoinreminder_ [uid220256@gateway/web/irccloud.com/x-thqzpxqfzsabtels] has quit [Remote host closed the connection] 21:18 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 21:50 < bitcoin-git> [bitcoin] laanwj closed pull request #10417: BIP 148 support (master...master-BIP148) https://github.com/bitcoin/bitcoin/pull/10417 21:57 -!- juscamarena_ [~justin@47.148.176.74] has quit [Remote host closed the connection] 22:01 -!- juscamarena_ [~justin@47.148.176.74] has joined #bitcoin-core-dev 22:25 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer] 22:25 < paveljanik> ... the first night when my IRC log buffer doesn't show the whole night communication... 22:25 < paveljanik> and more over it even rolled out my TODOs 8) 22:28 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 22:37 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 22:38 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev 22:44 * wumpus made some people really angry 22:46 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 22:49 -!- goksinen [~goksinen@208.103.81.26] has joined #bitcoin-core-dev 22:50 -!- goksinen [~goksinen@208.103.81.26] has quit [Read error: Connection reset by peer] 22:50 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 22:51 < jcorgan> it think we need CAPRs (Contributor Activated Pull Requests) :-) 22:54 < wumpus> heh 22:54 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 23:27 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 23:28 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hsigmstpdaglfukl] has joined #bitcoin-core-dev 23:30 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 23:51 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 23:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds]