12017-05-17T00:05:13  *** goksinen has joined #bitcoin-core-dev
  22017-05-17T00:12:14  *** goksinen has quit IRC
  32017-05-17T00:15:29  *** jcliff42 has quit IRC
  42017-05-17T00:15:29  *** arowser has joined #bitcoin-core-dev
  52017-05-17T00:20:39  *** twistedline_ has quit IRC
  62017-05-17T00:21:04  *** twistedline has joined #bitcoin-core-dev
  72017-05-17T00:23:20  *** cryptapus has joined #bitcoin-core-dev
  82017-05-17T00:23:20  *** cryptapus has joined #bitcoin-core-dev
  92017-05-17T00:23:33  *** cryptapus_afk has quit IRC
 102017-05-17T00:29:53  *** AaronvanW has quit IRC
 112017-05-17T00:30:27  *** AaronvanW has joined #bitcoin-core-dev
 122017-05-17T00:34:47  *** jcliff42 has joined #bitcoin-core-dev
 132017-05-17T00:35:16  *** AaronvanW has quit IRC
 142017-05-17T00:51:33  *** marcoagner has quit IRC
 152017-05-17T00:52:04  *** marcoagner has joined #bitcoin-core-dev
 162017-05-17T01:12:51  *** jcliff42 has quit IRC
 172017-05-17T01:27:39  *** Ylbam has quit IRC
 182017-05-17T01:29:37  *** PaulCape_ has quit IRC
 192017-05-17T01:31:42  *** goksinen has joined #bitcoin-core-dev
 202017-05-17T01:32:04  *** PaulCapestany has joined #bitcoin-core-dev
 212017-05-17T01:34:21  *** juscamarena_ has quit IRC
 222017-05-17T01:34:45  *** juscamarena_ has joined #bitcoin-core-dev
 232017-05-17T01:38:05  *** Dyaheon has quit IRC
 242017-05-17T01:40:23  *** Dyaheon has joined #bitcoin-core-dev
 252017-05-17T01:42:00  <achow101> what's everyone's thoughts on bip 148 and 149?
 262017-05-17T01:44:57  *** goksinen has quit IRC
 272017-05-17T01:45:26  *** goksinen has joined #bitcoin-core-dev
 282017-05-17T01:50:41  *** Alina-malina has quit IRC
 292017-05-17T01:51:07  *** justanotheruser has quit IRC
 302017-05-17T01:52:38  *** Alina-malina has joined #bitcoin-core-dev
 312017-05-17T01:52:51  <Chris_Stewart_5> So reading more about BIP8 I don't think it is necessarily a great idea to not have the possibility for a soft fork to fail
 322017-05-17T01:53:29  *** justanotheruser has joined #bitcoin-core-dev
 332017-05-17T01:53:51  *** jcliff42 has joined #bitcoin-core-dev
 342017-05-17T01:57:06  <Chris_Stewart_5> unless they fail somehow silently by not having nodes upgrade
 352017-05-17T01:57:16  *** jcliff42_ has joined #bitcoin-core-dev
 362017-05-17T02:00:22  *** jcliff42 has quit IRC
 372017-05-17T02:01:03  <Chris_Stewart_5> If I understand BIP148 correctly, it is advocating for oprhaning > 50% of the hash rates blocks?
 382017-05-17T02:01:07  <Chris_Stewart_5> "By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment. "
 392017-05-17T02:02:13  *** jcliff42_ has quit IRC
 402017-05-17T02:03:06  <sipa> Chris_Stewart_5: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
 412017-05-17T02:14:11  <bitcoin-git> [bitcoin] RHavar opened pull request #10413: Fix docs (there's no rpc command setpaytxfee) (master...patch-2) https://github.com/bitcoin/bitcoin/pull/10413
 422017-05-17T02:24:56  <Chris_Stewart_5> Would there be any harm in writing code to provide to miners to *avoid* selecting segwit txs to put in their blocks? That way miners that don't support segwit for whatever reason won't select them for their blocks? Or is that already the case?
 432017-05-17T02:25:23  <sipa> that's already the case
 442017-05-17T02:25:49  <sipa> if you connect miner software that doesn't support segwit to bitcoind, GBT will only include non-segwit txn
 452017-05-17T02:26:12  <sipa> (since 0.14)
 462017-05-17T02:31:53  *** jnewshoes has quit IRC
 472017-05-17T02:48:02  *** laurentmt has joined #bitcoin-core-dev
 482017-05-17T02:48:59  *** laurentmt has quit IRC
 492017-05-17T02:50:18  *** Alina-malina has quit IRC
 502017-05-17T02:53:10  *** Alina-malina has joined #bitcoin-core-dev
 512017-05-17T03:09:22  <luke-jr> Chris_Stewart_5: no, it's advocating for 100% of the hashrate to signal segwit
 522017-05-17T03:09:30  <luke-jr> very strongly advocating
 532017-05-17T03:10:57  *** LeMiner has joined #bitcoin-core-dev
 542017-05-17T03:10:58  *** LeMiner has joined #bitcoin-core-dev
 552017-05-17T03:14:17  *** justanotheruser has quit IRC
 562017-05-17T03:15:50  *** justanotheruser has joined #bitcoin-core-dev
 572017-05-17T03:39:09  *** goksinen has joined #bitcoin-core-dev
 582017-05-17T03:41:08  *** goksinen has quit IRC
 592017-05-17T03:43:28  *** Dyaheon has quit IRC
 602017-05-17T03:43:56  *** Giszmo has quit IRC
 612017-05-17T03:45:37  *** Dyaheon has joined #bitcoin-core-dev
 622017-05-17T03:47:36  *** ajd_ has quit IRC
 632017-05-17T03:51:22  *** Chris_Stewart_5 has quit IRC
 642017-05-17T03:52:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 652017-05-17T04:58:01  *** Squidicuz has quit IRC
 662017-05-17T05:21:43  *** goksinen has joined #bitcoin-core-dev
 672017-05-17T05:23:05  *** goksinen has quit IRC
 682017-05-17T05:27:21  *** goksinen has joined #bitcoin-core-dev
 692017-05-17T05:28:43  *** goksinen has quit IRC
 702017-05-17T05:29:23  *** goksinen has joined #bitcoin-core-dev
 712017-05-17T05:30:45  *** goksinen has quit IRC
 722017-05-17T05:39:24  *** Squidicuz has joined #bitcoin-core-dev
 732017-05-17T05:44:59  <gmaxwell> aww
 742017-05-17T05:45:01  <gmaxwell> 2017-05-17 05:43:33 Recovering log #177650
 752017-05-17T05:45:01  <gmaxwell> 2017-05-17 05:43:35 /home/gmaxwell/.bitcoin/blocks/index/177650.log: dropping 30275 bytes; Corruption: checksum mismatch
 762017-05-17T05:45:02  <gribble> https://github.com/bitcoin/bitcoin/issues/177650 | HTTP Error 404: Not Found
 772017-05-17T05:45:04  <gmaxwell> 2017-05-17 05:43:35 Corruption: checksum mismatch
 782017-05-17T05:45:05  <gmaxwell> saddness.
 792017-05-17T05:45:07  <gmaxwell> 2017-05-17 05:43:35 Database corrupted
 802017-05-17T06:00:08  *** dermoth has quit IRC
 812017-05-17T06:00:47  *** dermoth has joined #bitcoin-core-dev
 822017-05-17T06:05:23  <gmaxwell> also telling me to reindex chainstate on a blocks index corruption isn't so helpful.
 832017-05-17T06:11:46  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/95546c859b71...b45a52aeff0a
 842017-05-17T06:11:46  <bitcoin-git> bitcoin/master 1530bfc Suhas Daftuar: Add logging to FinalizeNode()
 852017-05-17T06:11:47  <bitcoin-git> bitcoin/master b45a52a Wladimir J. van der Laan: Merge #10404: doc: Add logging to FinalizeNode()...
 862017-05-17T06:12:19  <bitcoin-git> [bitcoin] laanwj closed pull request #10404: doc: Add logging to FinalizeNode() (master...2017-05-log-finalize-node) https://github.com/bitcoin/bitcoin/pull/10404
 872017-05-17T06:13:10  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b45a52aeff0a...541199788c10
 882017-05-17T06:13:11  <bitcoin-git> bitcoin/master fac79e4 MarcoFalke: qa: Warn when specified test is not found
 892017-05-17T06:13:11  <bitcoin-git> bitcoin/master 5411997 Wladimir J. van der Laan: Merge #10374: qa: Warn when specified test is not found...
 902017-05-17T06:13:15  *** Ylbam has joined #bitcoin-core-dev
 912017-05-17T06:13:41  <bitcoin-git> [bitcoin] laanwj closed pull request #10374: qa: Warn when specified test is not found (master...Mf1705-qaWarnTestNotFound) https://github.com/bitcoin/bitcoin/pull/10374
 922017-05-17T06:22:04  <paveljanik> jtimon, ping
 932017-05-17T06:23:20  <paveljanik> jtimon, GetDustThreshold's dustRelayFee is shadowing global ::dustRelayFee, but is always called with it as an argument. Do you prefer removing it and use ::dustRelayFee instead or renaming the argument name to prevent shadowing warnings?
 942017-05-17T06:24:04  <paveljanik> The same applies to IsDust
 952017-05-17T06:42:40  *** marcoagner has quit IRC
 962017-05-17T06:54:54  *** marcoagner has joined #bitcoin-core-dev
 972017-05-17T06:57:40  *** BashCo has quit IRC
 982017-05-17T07:12:38  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/541199788c10...9390845c53e3
 992017-05-17T07:12:39  <bitcoin-git> bitcoin/master bc63d0e Pedro Branco: Add query options to listunspent rpc call
1002017-05-17T07:12:39  <bitcoin-git> bitcoin/master 9390845 Wladimir J. van der Laan: Merge #8952: Add query options to listunspent RPC call...
1012017-05-17T07:15:38  *** BashCo has joined #bitcoin-core-dev
1022017-05-17T07:31:10  *** goksinen has joined #bitcoin-core-dev
1032017-05-17T07:33:39  *** goksinen has quit IRC
1042017-05-17T08:03:05  *** tripleslash has quit IRC
1052017-05-17T08:05:17  *** jannes has joined #bitcoin-core-dev
1062017-05-17T08:07:01  *** tripleslash has joined #bitcoin-core-dev
1072017-05-17T08:13:48  *** vicenteH has joined #bitcoin-core-dev
1082017-05-17T08:21:35  *** tripleslash has quit IRC
1092017-05-17T08:25:48  *** tripleslash has joined #bitcoin-core-dev
1102017-05-17T08:25:58  *** tripleslash has joined #bitcoin-core-dev
1112017-05-17T08:28:04  *** timothy has joined #bitcoin-core-dev
1122017-05-17T08:44:14  *** jtimon has quit IRC
1132017-05-17T08:45:52  <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
1142017-05-17T08:46:08  *** Guyver2 has joined #bitcoin-core-dev
1152017-05-17T08:46:52  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9390845c53e3...08ac35a7e3ef
1162017-05-17T08:46:52  <bitcoin-git> bitcoin/master 0f1b26a Ryan Havar: Fix docs (there's no rpc command setpaytxfee)
1172017-05-17T08:46:53  <bitcoin-git> bitcoin/master 08ac35a Wladimir J. van der Laan: Merge #10413: Fix docs (there's no rpc command setpaytxfee)...
1182017-05-17T08:47:28  <bitcoin-git> [bitcoin] fanquake closed pull request #9704: Store downloaded blocks prior to shutdown. (master...StoreBlocksAtShutdown) https://github.com/bitcoin/bitcoin/pull/9704
1192017-05-17T08:47:38  *** fanquake has joined #bitcoin-core-dev
1202017-05-17T08:49:42  <fanquake> wumpus I'm just closing a bunch of PRs that haven't garnered any discussion and/or have needed rebasing for some time.
1212017-05-17T08:50:00  <wumpus> fanquake: thanks!
1222017-05-17T08:50:58  <bitcoin-git> [bitcoin] fanquake closed pull request #8958: Improve logic for advertising blocks (master...BetterBroadcastLogic) https://github.com/bitcoin/bitcoin/pull/8958
1232017-05-17T08:51:15  *** Aaronvan_ has joined #bitcoin-core-dev
1242017-05-17T08:52:24  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/08ac35a7e3ef...0542978aae12
1252017-05-17T08:52:24  <bitcoin-git> bitcoin/master 2f84cf6 Wladimir J. van der Laan: tests: Correct testcase in script_tests.json for large number OP_EQUAL...
1262017-05-17T08:52:24  <bitcoin-git> bitcoin/master 0542978 Wladimir J. van der Laan: Merge #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL...
1272017-05-17T08:52:57  <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
1282017-05-17T08:53:05  <wumpus> gmaxwell: any idea what caused the corruption?
1292017-05-17T08:54:00  <wumpus> darn it's in a log file, ideally it would regard CRC errors in the log simply as truncation
1302017-05-17T08:54:08  <gmaxwell> I think likely just many unclean power offs..
1312017-05-17T08:54:24  <gmaxwell> I think it does at a lower sanity checking level.
1322017-05-17T08:54:47  <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
1332017-05-17T08:54:53  <wumpus> right
1342017-05-17T08:55:29  <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
1352017-05-17T09:06:03  <fanquake> wumpus got a utACK from cfields on #7522, did you want to merge it?
1362017-05-17T09:06:04  <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
1372017-05-17T09:06:53  <wumpus> ah yes let's merge it
1382017-05-17T09:07:21  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0542978aae12...d25449f85862
1392017-05-17T09:07:22  <bitcoin-git> bitcoin/master e98e3dd Luke Dashjr: Bugfix: Only use git for build info if the repository is actually the right one...
1402017-05-17T09:07:22  <bitcoin-git> bitcoin/master df63490 Luke Dashjr: Merge tag 'branch-0.13' into bugfix_gitdir
1412017-05-17T09:07:23  <bitcoin-git> bitcoin/master ed1fcdc Luke Dashjr: Bugfix: Detect genbuild.sh in repo correctly
1422017-05-17T09:11:20  <fanquake> wumpus Looks like #10319 is good to merge also.
1432017-05-17T09:11:22  <gribble> https://github.com/bitcoin/bitcoin/issues/10319 | Remove unused argument from MarkBlockAsInFlight(...) by practicalswift · Pull Request #10319 · bitcoin/bitcoin · GitHub
1442017-05-17T09:12:19  <wumpus> fanquake: yep
1452017-05-17T09:13:00  <wumpus> fanquake: I wasn't sure there, because I'm fairly sure that argument was only added recently
1462017-05-17T09:13:46  <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
1472017-05-17T09:14:17  <wumpus> maybe we should ask jtimon
1482017-05-17T09:14:38  <wumpus> not that I'd mind just merging it, but I don't want to sabotage anyone's work in progress
1492017-05-17T09:15:54  <wumpus> ok I see sdaftuar added it and now is ok with removing it
1502017-05-17T09:15:58  <fanquake> wumpus ok. I'll ping him in that PR.
1512017-05-17T09:16:17  <wumpus> fanquake: not necessary, I think
1522017-05-17T09:16:25  <wumpus> he's not involved with this one
1532017-05-17T09:16:45  <fanquake> wumpus All good then. #10388 should also be ok to merge.
1542017-05-17T09:16:47  <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
1552017-05-17T09:17:00  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d25449f85862...32f671b14107
1562017-05-17T09:17:01  <bitcoin-git> bitcoin/master 6345f0b practicalswift: Remove unused argument from MarkBlockAsInFlight(...)
1572017-05-17T09:17:01  <bitcoin-git> bitcoin/master 32f671b Wladimir J. van der Laan: Merge #10319: Remove unused argument from MarkBlockAsInFlight(...)...
1582017-05-17T09:17:25  <bitcoin-git> [bitcoin] laanwj closed pull request #10319: Remove unused argument from MarkBlockAsInFlight(...) (master...remove-unused-argument) https://github.com/bitcoin/bitcoin/pull/10319
1592017-05-17T09:18:29  <wumpus> yep
1602017-05-17T09:18:46  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/32f671b14107...526e8390e6be
1612017-05-17T09:18:46  <bitcoin-git> bitcoin/master 65d484a Alex Morcos: Output line to debug.log when IsInitialBlockDownload latches to false
1622017-05-17T09:18:47  <bitcoin-git> bitcoin/master 526e839 Wladimir J. van der Laan: Merge #10388: Output line to debug.log when IsInitialBlockDownload latches to false...
1632017-05-17T09:19:21  <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
1642017-05-17T09:20:57  <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
1652017-05-17T09:23:18  <fanquake> Good amount of Boost code being removed pre 0.15.
1662017-05-17T09:32:39  <fanquake> Recent CVE (CVE-2017-8798) in miniupnpc. Committed fix: https://github.com/miniupnp/miniupnp/commit/f0f1f4b22d6a98536377a1bb07e7c20e4703d229
1672017-05-17T09:34:06  *** goksinen has joined #bitcoin-core-dev
1682017-05-17T09:37:53  <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
1692017-05-17T09:38:04  *** Alina-malina has quit IRC
1702017-05-17T09:38:04  *** Alina-malina has joined #bitcoin-core-dev
1712017-05-17T09:39:13  *** goksinen has quit IRC
1722017-05-17T09:46:39  <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
1732017-05-17T10:02:02  *** riemann has joined #bitcoin-core-dev
1742017-05-17T10:40:32  <wumpus> fanquake: yes, another (possibly exploitable) miniupnpc vuln, happy we don't have enabled by default anymore, still yes we should bump the version
1752017-05-17T10:54:53  <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
1762017-05-17T11:21:59  *** goksinen has joined #bitcoin-core-dev
1772017-05-17T11:24:10  *** goksinen has joined #bitcoin-core-dev
1782017-05-17T11:27:33  *** goksinen has joined #bitcoin-core-dev
1792017-05-17T11:28:55  *** goksinen has quit IRC
1802017-05-17T11:31:01  *** goksinen has joined #bitcoin-core-dev
1812017-05-17T11:32:23  *** goksinen has quit IRC
1822017-05-17T11:33:29  *** goksinen has joined #bitcoin-core-dev
1832017-05-17T11:34:50  *** goksinen has quit IRC
1842017-05-17T11:35:34  *** goksinen has joined #bitcoin-core-dev
1852017-05-17T11:36:29  *** goksinen has quit IRC
1862017-05-17T11:37:32  *** goksinen has joined #bitcoin-core-dev
1872017-05-17T11:38:54  *** goksinen has quit IRC
1882017-05-17T11:39:35  *** goksinen has joined #bitcoin-core-dev
1892017-05-17T11:40:57  *** goksinen has quit IRC
1902017-05-17T11:41:53  *** goksinen has joined #bitcoin-core-dev
1912017-05-17T11:43:14  *** goksinen has quit IRC
1922017-05-17T11:45:10  *** goksinen has joined #bitcoin-core-dev
1932017-05-17T11:46:33  *** goksinen has quit IRC
1942017-05-17T11:47:54  *** goksinen has joined #bitcoin-core-dev
1952017-05-17T11:49:17  *** goksinen has quit IRC
1962017-05-17T11:50:04  *** goksinen has joined #bitcoin-core-dev
1972017-05-17T11:52:19  *** goksinen has joined #bitcoin-core-dev
1982017-05-17T11:52:59  <SopaXorzTaker> Uhm, guys?..
1992017-05-17T11:53:16  <SopaXorzTaker> we have a problem - P2SH addresses only depend on the security of RIPEMD-160
2002017-05-17T11:53:41  *** goksinen has quit IRC
2012017-05-17T11:53:57  <wumpus> please, #bitcoin
2022017-05-17T11:54:10  <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
2032017-05-17T11:54:10  *** riemann has quit IRC
2042017-05-17T11:54:24  <wumpus> again, #bitcoin, this is not the place to discuss the protocol in general
2052017-05-17T11:54:26  <SopaXorzTaker> banned from #bitcoin for spreading bullsh*t
2062017-05-17T11:56:44  *** cypherbit has joined #bitcoin-core-dev
2072017-05-17T12:03:24  <cypherbit> join bitcoin
2082017-05-17T12:08:02  *** riemann has joined #bitcoin-core-dev
2092017-05-17T12:10:02  *** cypherbit has quit IRC
2102017-05-17T13:06:32  *** jtimon has joined #bitcoin-core-dev
2112017-05-17T13:12:28  <jtimon> paveljanik: morcos asked not to remove the argument, so probably just renaming the argument is the less disruptive thing
2122017-05-17T13:31:02  *** goksinen has joined #bitcoin-core-dev
2132017-05-17T13:31:13  *** moli_ has joined #bitcoin-core-dev
2142017-05-17T13:31:57  *** cryptapus has quit IRC
2152017-05-17T13:32:23  *** goksinen has quit IRC
2162017-05-17T13:33:18  *** cryptapus has joined #bitcoin-core-dev
2172017-05-17T13:33:19  *** cryptapus is now known as cryptapus_afk
2182017-05-17T13:35:05  *** mol has quit IRC
2192017-05-17T13:35:52  *** goksinen has joined #bitcoin-core-dev
2202017-05-17T13:37:13  *** goksinen has quit IRC
2212017-05-17T13:39:09  *** goksinen has joined #bitcoin-core-dev
2222017-05-17T13:39:31  *** cryptapus_afk has quit IRC
2232017-05-17T13:40:30  *** goksinen has quit IRC
2242017-05-17T13:40:42  <fanquake> jonasschnelli Your PR/Nightly build server is pretty fancy now. Good work.
2252017-05-17T13:40:45  *** cryptapus_afk has joined #bitcoin-core-dev
2262017-05-17T13:40:54  <jonasschnelli> fanquake: heh. Yeah... UI matters. :)
2272017-05-17T13:42:22  <fanquake> I can remember when it was basically a file directory. A lot more useful information now!
2282017-05-17T13:43:02  *** goksinen has joined #bitcoin-core-dev
2292017-05-17T13:44:46  *** cryptapus_afk has quit IRC
2302017-05-17T13:46:59  *** goksinen has quit IRC
2312017-05-17T13:47:37  *** goksinen has joined #bitcoin-core-dev
2322017-05-17T13:48:58  *** goksinen has quit IRC
2332017-05-17T13:50:14  *** goksinen has joined #bitcoin-core-dev
2342017-05-17T13:50:23  *** d_t has joined #bitcoin-core-dev
2352017-05-17T13:51:36  *** goksinen has quit IRC
2362017-05-17T13:52:13  *** JackH has joined #bitcoin-core-dev
2372017-05-17T13:52:30  *** goksinen has joined #bitcoin-core-dev
2382017-05-17T13:54:26  *** goksinen has joined #bitcoin-core-dev
2392017-05-17T13:54:41  *** d_t has quit IRC
2402017-05-17T13:55:48  *** goksinen has quit IRC
2412017-05-17T13:58:17  *** mol has joined #bitcoin-core-dev
2422017-05-17T14:01:00  *** moli_ has quit IRC
2432017-05-17T14:11:56  *** molz_ has joined #bitcoin-core-dev
2442017-05-17T14:14:01  *** Giszmo has joined #bitcoin-core-dev
2452017-05-17T14:14:55  *** mol has quit IRC
2462017-05-17T14:17:52  *** laurentmt has joined #bitcoin-core-dev
2472017-05-17T14:19:03  *** goksinen has joined #bitcoin-core-dev
2482017-05-17T14:19:40  *** Ylbam has quit IRC
2492017-05-17T14:20:28  *** laurentmt has quit IRC
2502017-05-17T14:31:50  *** fanquake has quit IRC
2512017-05-17T14:36:02  *** d9b4bef9 has quit IRC
2522017-05-17T14:37:08  *** d9b4bef9 has joined #bitcoin-core-dev
2532017-05-17T14:43:28  <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?
2542017-05-17T14:46:05  <luke-jr> timothy: it's technically illegal to redistribute :/  probably better off just waiting
2552017-05-17T14:46:41  <luke-jr> timothy: btw, you're the Arch package maintainer, right? I had heard the packages were outdated (but that was a while ago..)
2562017-05-17T14:50:36  <midnightmagic> It's also not really worth much if you take a closed-source distribution package from some rando on IRC. :-)
2572017-05-17T15:01:31  *** riemann has quit IRC
2582017-05-17T15:03:47  <timothy> midnightmagic: not really, in gitian files there is the sha256sum of the tar
2592017-05-17T15:04:20  <timothy>  b49f056b0a3d88cb4def52aa612dc23084eade8699f853f68b4a4456daa7ddb6 MacOSX10.11.sdk.tar.gz
2602017-05-17T15:04:47  <timothy> if it's the same for anybody
2612017-05-17T15:08:25  *** molz_ has quit IRC
2622017-05-17T15:08:52  *** molz_ has joined #bitcoin-core-dev
2632017-05-17T15:11:47  <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
2642017-05-17T15:12:20  <jonasschnelli> sipa: Would support for Bech32 without hrp make sense in the ref. impl?
2652017-05-17T15:12:22  <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
2662017-05-17T15:12:52  <jonasschnelli> sipa: it's a simple change and allow to reuse Bech32 for other stuff...
2672017-05-17T15:13:03  <jonasschnelli> (where size matters)
2682017-05-17T15:14:13  <gmaxwell> jonasschnelli: without the HRP you'll decode strings for one application as correct for another-- mooting the fancy protection.
2692017-05-17T15:15:21  <jonasschnelli> gmaxwell: A single magic 5bit value inside the Bech32 would save 1char (the separator)...
2702017-05-17T15:15:29  <jonasschnelli> But maybe I'm wrong.
2712017-05-17T15:16:35  <jonasschnelli> I don't say we should throw it away.. just maybe the ref. impl. could support enc/dec Bech32 without the hrp
2722017-05-17T15:17:09  <jonasschnelli> (working on a use case where size really matters)
2732017-05-17T15:21:01  <gmaxwell> can't you prefill the prefix?
2742017-05-17T15:22:12  <midnightmagic> timothy: pretty sure it's not, unless there's some new tarball-maker for that..?
2752017-05-17T15:29:26  *** Dyaheon has quit IRC
2762017-05-17T15:30:52  *** Dyaheon has joined #bitcoin-core-dev
2772017-05-17T15:31:02  *** adiabat has quit IRC
2782017-05-17T15:33:31  <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.
2792017-05-17T15:33:43  *** talmai has joined #bitcoin-core-dev
2802017-05-17T15:35:28  *** rgod has joined #bitcoin-core-dev
2812017-05-17T15:36:41  <jonasschnelli> But I guess I'm again micro-optimizing... so nm
2822017-05-17T15:37:40  *** adiabat has joined #bitcoin-core-dev
2832017-05-17T15:43:43  *** rgod has quit IRC
2842017-05-17T15:49:20  <sipa> jonasschnelli: i would suggest you don't change the reference implementation, but just prefix a constant HRP before calling it
2852017-05-17T15:49:21  *** abpa has joined #bitcoin-core-dev
2862017-05-17T15:50:03  <jonasschnelli> sipa: Aha. Now I understand... yes. Much simpler.
2872017-05-17T16:11:41  *** BashCo has quit IRC
2882017-05-17T16:17:19  *** Ylbam has joined #bitcoin-core-dev
2892017-05-17T16:18:09  *** molz_ has quit IRC
2902017-05-17T16:18:17  <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
2912017-05-17T16:19:35  *** Guyver2 has quit IRC
2922017-05-17T16:20:26  <wumpus> you might have to refresh my key in any case
2932017-05-17T16:22:01  <gmaxwell> jonasschnelli: sorry, thats what I meant by prefill the prefix.
2942017-05-17T16:23:26  *** moli_ has joined #bitcoin-core-dev
2952017-05-17T16:24:29  <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.
2962017-05-17T16:24:33  *** jnewbery has quit IRC
2972017-05-17T16:24:38  <jonasschnelli> wumpus: Thanks for the info
2982017-05-17T16:24:46  *** jnewbery has joined #bitcoin-core-dev
2992017-05-17T16:44:27  *** d_t has joined #bitcoin-core-dev
3002017-05-17T16:44:59  *** BashCo has joined #bitcoin-core-dev
3012017-05-17T16:45:47  *** d_t has quit IRC
3022017-05-17T16:46:09  *** d_t has joined #bitcoin-core-dev
3032017-05-17T16:51:46  *** goksinen has quit IRC
3042017-05-17T16:52:23  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/526e8390e6be...ea1fd43bb9a3
3052017-05-17T16:52:23  <bitcoin-git> bitcoin/master d4668f3 Jimmy Song: [test] Add test for getmemoryinfo...
3062017-05-17T16:52:24  <bitcoin-git> bitcoin/master ea1fd43 Wladimir J. van der Laan: Merge #10257: [test] Add test for getmemoryinfo...
3072017-05-17T16:52:52  <bitcoin-git> [bitcoin] laanwj closed pull request #10257: [test] Add test for getmemoryinfo (master...test_getmemoryinfo) https://github.com/bitcoin/bitcoin/pull/10257
3082017-05-17T16:55:43  *** timothy has quit IRC
3092017-05-17T16:58:13  <paveljanik> jtimon, morcos: OK, will PR it later to prevent warning with your comments included for future reference.
3102017-05-17T16:58:23  <paveljanik> (or someone else can do it ;-)
3112017-05-17T17:11:58  *** goksinen has joined #bitcoin-core-dev
3122017-05-17T17:14:42  *** goksinen has joined #bitcoin-core-dev
3132017-05-17T17:16:10  *** goksinen has quit IRC
3142017-05-17T17:28:10  <bitcoin-git> [bitcoin] achow101 opened pull request #10417: BIP 148 support (master...master-BIP148) https://github.com/bitcoin/bitcoin/pull/10417
3152017-05-17T17:31:01  *** goksinen has joined #bitcoin-core-dev
3162017-05-17T17:43:37  *** jcliff42 has joined #bitcoin-core-dev
3172017-05-17T17:53:02  *** talmai has quit IRC
3182017-05-17T18:02:11  *** goksinen has quit IRC
3192017-05-17T18:03:25  *** goksinen has joined #bitcoin-core-dev
3202017-05-17T18:31:53  *** btcdrak has joined #bitcoin-core-dev
3212017-05-17T18:33:13  *** jcliff42 has quit IRC
3222017-05-17T18:35:30  *** jcliff42 has joined #bitcoin-core-dev
3232017-05-17T18:44:57  *** Dyaheon has quit IRC
3242017-05-17T18:47:53  *** talmai has joined #bitcoin-core-dev
3252017-05-17T18:48:38  *** Dyaheon has joined #bitcoin-core-dev
3262017-05-17T18:48:49  *** talmai has quit IRC
3272017-05-17T18:49:37  *** jcliff42 has quit IRC
3282017-05-17T18:51:06  *** jcliff42 has joined #bitcoin-core-dev
3292017-05-17T18:58:53  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ea1fd43bb9a3...e61fc2d7cb4f
3302017-05-17T18:58:53  <bitcoin-git> bitcoin/master af5d48c fanquake: [depends] miniupnpc 2.0.20170509
3312017-05-17T18:58:54  <bitcoin-git> bitcoin/master e61fc2d Wladimir J. van der Laan: Merge #10414: [depends] miniupnpc 2.0.20170509...
3322017-05-17T18:59:29  <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
3332017-05-17T18:59:50  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8adf75e6a124267da1ae46be1eee50c52ce6082b
3342017-05-17T18:59:50  <bitcoin-git> bitcoin/0.13 8adf75e fanquake: [depends] miniupnpc 2.0.20170509...
3352017-05-17T19:12:01  *** jcliff42 has quit IRC
3362017-05-17T19:27:14  *** harrymm has joined #bitcoin-core-dev
3372017-05-17T19:42:12  *** mol has joined #bitcoin-core-dev
3382017-05-17T19:43:01  *** jannes has quit IRC
3392017-05-17T19:43:33  *** moli_ has quit IRC
3402017-05-17T19:58:14  *** jcliff42 has joined #bitcoin-core-dev
3412017-05-17T20:15:33  <bitcoin-git> [bitcoin] sipa pushed 16 new commits to master: https://github.com/bitcoin/bitcoin/compare/e61fc2d7cb4f...318ea50a1c2f
3422017-05-17T20:15:34  <bitcoin-git> bitcoin/master c0a273f Alex Morcos: Change file format for fee estimates....
3432017-05-17T20:15:34  <bitcoin-git> bitcoin/master e5007ba Alex Morcos: Change parameters for fee estimation and estimates on all 3 time horizons....
3442017-05-17T20:15:35  <bitcoin-git> bitcoin/master d3e30bc Alex Morcos: Refactor to update moving average on fly
3452017-05-17T20:16:01  <bitcoin-git> [bitcoin] sipa closed pull request #10199: Better fee estimates (master...smarterfee) https://github.com/bitcoin/bitcoin/pull/10199
3462017-05-17T20:23:22  <morcos> sipa:  yikes!  thanks, i think
3472017-05-17T20:25:49  <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/318ea50a1c2f...bee35299716c
3482017-05-17T20:25:50  <bitcoin-git> bitcoin/master acc2e4b Suhas Daftuar: Bugfix: PrioritiseTransaction updates the mempool tx counter...
3492017-05-17T20:25:50  <bitcoin-git> bitcoin/master 6c2e25c Suhas Daftuar: [qa] Test prioritise_transaction / getblocktemplate interaction
3502017-05-17T20:25:51  <bitcoin-git> bitcoin/master bee3529 Pieter Wuille: Merge #10196: Bugfix: PrioritiseTransaction updates the mempool tx counter...
3512017-05-17T20:26:14  <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
3522017-05-17T20:29:25  *** jcliff42_ has joined #bitcoin-core-dev
3532017-05-17T20:32:45  *** jcliff4__ has joined #bitcoin-core-dev
3542017-05-17T20:32:59  *** jcliff42 has quit IRC
3552017-05-17T20:33:43  *** jcliff42_ has quit IRC
3562017-05-17T20:37:37  *** goksinen has quit IRC
3572017-05-17T20:37:55  *** berndj has quit IRC
3582017-05-17T20:38:42  *** berndj has joined #bitcoin-core-dev
3592017-05-17T20:45:54  *** goksinen has joined #bitcoin-core-dev
3602017-05-17T20:48:22  *** goksinen has quit IRC
3612017-05-17T20:50:01  *** goksinen has joined #bitcoin-core-dev
3622017-05-17T20:51:33  *** goksinen has quit IRC
3632017-05-17T20:52:35  *** Dyaheon has quit IRC
3642017-05-17T20:53:46  *** Dyaheon has joined #bitcoin-core-dev
3652017-05-17T20:54:13  <achow101> would it be possible to ban wewillfindyou? He's derailing and possibly trolling #10417
3662017-05-17T20:54:15  <gribble> https://github.com/bitcoin/bitcoin/issues/10417 | BIP 148 support by achow101 · Pull Request #10417 · bitcoin/bitcoin · GitHub
3672017-05-17T20:54:41  *** goksinen has joined #bitcoin-core-dev
3682017-05-17T20:56:38  *** goksinen has quit IRC
3692017-05-17T20:57:09  <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
3702017-05-17T20:57:11  <sipa> achow101: done
3712017-05-17T20:57:37  <achow101> ty
3722017-05-17T20:57:41  <sipa> Chris_Stewart_5: signalling for BU != running BU
3732017-05-17T20:58:12  <achow101> Chris_Stewart_5: they shouldn't select segwit txs though since they are non-standard under current rules
3742017-05-17T20:59:34  <Chris_Stewart_5> achow101: P2SH(P2WPKH or P2WSH) would be wouldn't it?
3752017-05-17T20:59:47  <sipa> Chris_Stewart_5: no
3762017-05-17T21:00:00  <sipa> those still require a spend that violates the CLEANSTACK rule
3772017-05-17T21:00:09  <sipa> which has been in every release since 0.11
3782017-05-17T21:00:41  <achow101> the transactions creating the p2sh nested outputs themselves are find and can be mined. the spending transaction is not
3792017-05-17T21:00:50  <achow101> s/find/fine/
3802017-05-17T21:01:08  *** jcliff4__ has quit IRC
3812017-05-17T21:01:48  <luke-jr> (and mining those p2sh txs won't be a problem for the BU blocks)
3822017-05-17T21:10:34  <BlueMatt> luke-jr: this is absurd, do you seriously believe the vast, vast majority of bitcoin users (incl businesses) support bip 148?
3832017-05-17T21:10:58  <gmaxwell> he believes they support segwit, which is super clear at this point.
3842017-05-17T21:11:25  <BlueMatt> bip 148 != segwit, they are different proposed consensus changes, despite sharing many features
3852017-05-17T21:11:27  <luke-jr> BlueMatt: businesses exist to serve the users
3862017-05-17T21:11:45  <gmaxwell> yea, I'm not arguing that they're the same, just trying to clarify luke's position the way I understand it.
3872017-05-17T21:11:53  <luke-jr> BlueMatt: and so far, the businesses are taking a hardline position of "we will run Core only"
3882017-05-17T21:11:55  <gmaxwell> Chris_Stewart_5: No it won't.
3892017-05-17T21:12:00  <luke-jr> which is half the reason we need to merge it in Core
3902017-05-17T21:12:35  <luke-jr> if businesses weren't being stupid about this, I'd prefer BIP148 activate without Core. but reality is what it is
3912017-05-17T21:12:40  <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
3922017-05-17T21:14:19  <luke-jr> the only "opposition" (besides trolls) I see to BIP148, is the mistaken belief that it won't or can't work
3932017-05-17T21:14:38  <gmaxwell> it's very disruptive if it isn't an overwhelming success.
3942017-05-17T21:14:47  <sipa> it can only work if everyone adopts it
3952017-05-17T21:14:54  <sipa> it is not our job to push for that
3962017-05-17T21:15:17  <luke-jr> gmaxwell: which is why it's important to ensure it's an overwhelming success.
3972017-05-17T21:15:21  <BlueMatt> it is not bitcoin core's job to merge something *until* that exists, irrespective of whether individual contributors are pushing for it
3982017-05-17T21:15:52  <luke-jr> BlueMatt: until what exists?
3992017-05-17T21:16:04  <BlueMatt> ovherwhelming support across the ecosystem
4002017-05-17T21:16:16  <luke-jr> that pretty much exists to the extent it can without Core merging it.
4012017-05-17T21:16:25  <luke-jr> businesses will run whatever Core releases, and won't run what Core won't release.
4022017-05-17T21:16:29  <luke-jr> it sucks, but that's how it is right now
4032017-05-17T21:17:10  <sipa> and they do that, hopefully because they believe we're making sane choices of what is included in a release
4042017-05-17T21:17:11  <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
4052017-05-17T21:17:24  <BlueMatt> plus as many polls as you can possibly create at physical meetups
4062017-05-17T21:17:27  <BlueMatt> and then get back to me
4072017-05-17T21:18:53  <luke-jr> sipa: missing the point. it creates chicken-and-egg
4082017-05-17T21:19:22  <BlueMatt> not entirely, the chicken-and-egg problem can be solved by active outreach
4092017-05-17T21:19:23  <gmaxwell> BlueMatt: hopefully not your intent, but you did just make it sound like only business mattter.
4102017-05-17T21:19:29  <BlueMatt> something that I have yet to see literally any of
4112017-05-17T21:19:43  <BlueMatt> gmaxwell: fair, yes, that tis not at all my intent, hence the mention of physical meetups
4122017-05-17T21:19:54  <luke-jr> BlueMatt: no, because the businesses will NEVER run BIP148 until Core merges it
4132017-05-17T21:20:00  <BlueMatt> businesses do matter, but, indeed, only as much as every other group
4142017-05-17T21:20:10  <BlueMatt> luke-jr: we did it with segwit and got back overwhelmingly positive response!
4152017-05-17T21:20:30  <BlueMatt> prior to the parameters being merged
4162017-05-17T21:20:35  <luke-jr> besides half the businesses supporting Classic back then..
4172017-05-17T21:20:54  <BlueMatt> we got back 0 negative responses
4182017-05-17T21:21:00  <BlueMatt> 0
4192017-05-17T21:21:28  <BlueMatt> on top of people doing physical outreach and talking to various groups at meetups, plus discussions with long-time bitcoin holders and investors
4202017-05-17T21:21:35  <gmaxwell> BlueMatt: no, not true, we got a response from one webwallet vendor saying they prefer it be delayed a few months.
4212017-05-17T21:21:52  <gmaxwell> BlueMatt: the was the only negative response.. And I got more than a 50% response rate.
4222017-05-17T21:22:05  <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"
4232017-05-17T21:22:24  <BlueMatt> well, ok, mostly you got, but ok :)
4242017-05-17T21:22:56  <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".
4252017-05-17T21:23:08  <BlueMatt> oh, somehow i misrecalled, sorry
4262017-05-17T21:24:36  <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?
4272017-05-17T21:24:49  <sipa> luke-jr: i personally don't believe BIP148 will happen
4282017-05-17T21:24:58  <luke-jr> sipa: it will, even if it is a minority chain splitting off
4292017-05-17T21:25:06  <BlueMatt> business + broad user study
4302017-05-17T21:25:12  <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
4312017-05-17T21:25:45  <sipa> if core merges bip148 as a default option, it will just make people run other software instead, and the same will happen
4322017-05-17T21:26:05  *** molz_ has joined #bitcoin-core-dev
4332017-05-17T21:26:13  <luke-jr> people who are making a conscious decision on what software to run, are switching to BIP148 nodes or at least uacomments
4342017-05-17T21:26:16  <sipa> this is my expectation, and i certainly may be wrong
4352017-05-17T21:26:23  <BlueMatt> luke-jr: do you not agree that we should be, above all, absolutely and strictly requiring consensus for any consensus rule changes?
4362017-05-17T21:26:42  <luke-jr> BlueMatt: not for softforks, no. otherwise Segwit should never have been merged.
4372017-05-17T21:27:02  <BlueMatt> bip 148 has many of the upgrade properties of a hf
4382017-05-17T21:27:05  <luke-jr> Segwit is absolutely contentious. But it has sufficient support to merge as a softfork.
4392017-05-17T21:27:10  <BlueMatt> from that perspective bip 148 is closer to a hf than a sf, by far
4402017-05-17T21:27:31  <sipa> luke-jr: and bip148 obviously does not
4412017-05-17T21:27:32  <BlueMatt> segwit contention is overstated, in my experience
4422017-05-17T21:27:33  *** kadoban has quit IRC
4432017-05-17T21:27:39  <sipa> luke-jr: i don't understand why we're even discussing this
4442017-05-17T21:27:40  <luke-jr> I don't agree. BIP 148 only needs a majority to avoid a split.
4452017-05-17T21:27:43  <Anduck> maybe core should publish two versions.
4462017-05-17T21:27:54  <luke-jr> Anduck: there's an interesting idea
4472017-05-17T21:27:55  <BlueMatt> Anduck: we do *not* ship code with a massive face cannon built in
4482017-05-17T21:28:10  <BlueMatt> you're welcome to, however :p
4492017-05-17T21:28:32  <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?
4502017-05-17T21:28:44  <BlueMatt> but, yea, I'm with sipa, this is fucking stupid
4512017-05-17T21:28:47  <Anduck> it's indeed tough. SF-SW itself can be seen as "bad" because it relies on miners.. it's all very hard
4522017-05-17T21:28:52  <luke-jr> BlueMatt: telling miners is very different from economically forcing their hand
4532017-05-17T21:29:01  *** mol has quit IRC
4542017-05-17T21:29:39  <luke-jr> especially when the miners are already hostile and attacking the network
4552017-05-17T21:29:40  *** kadoban has joined #bitcoin-core-dev
4562017-05-17T21:30:13  <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
4572017-05-17T21:30:23  <BlueMatt> this it not true for bip 148, just as it is not true for a hf
4582017-05-17T21:30:29  *** sdf_0010 has joined #bitcoin-core-dev
4592017-05-17T21:30:43  <BlueMatt> luke-jr: great, so go talk to the exchanges and merchants where miners sell their coins and tell them to switch
4602017-05-17T21:30:50  <BlueMatt> I'm happy to help intro you to folks if you dont know most of them
4612017-05-17T21:31:05  <Anduck> BlueMatt: yeah, that's true
4622017-05-17T21:31:29  <luke-jr> BlueMatt: another dev has already tried this, and found they will only if Core releases it..
4632017-05-17T21:31:59  <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
4642017-05-17T21:32:07  <BlueMatt> so sounds like you got a "no"
4652017-05-17T21:32:30  <luke-jr> it's not clearly "yes", but it's certainly far from clearly "no"
4662017-05-17T21:33:00  <luke-jr> the community seems very much in favour of it, with a positive trent
4672017-05-17T21:33:02  <luke-jr> trend*
4682017-05-17T21:33:03  *** sipa has left #bitcoin-core-dev
4692017-05-17T21:33:10  <BlueMatt> if they're, otoh, expecting "Core" to decide consensus rules for the bitcoin ecosystem, then they can also clearly fuck off
4702017-05-17T21:33:17  <BlueMatt> that is not the same as consensus?
4712017-05-17T21:33:24  <luke-jr> Segwit doesn't have consensus.
4722017-05-17T21:33:42  <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
4732017-05-17T21:33:50  <BlueMatt> and if you're claiming you can, please pull your head out of your ass
4742017-05-17T21:34:23  <luke-jr> I'd say it seems pretty similar to segwit itself.
4752017-05-17T21:34:36  <BlueMatt> you think bip 148 has the same level of support as segwit?!
4762017-05-17T21:34:53  <BlueMatt> i refer you to my previous comment about bodily orifices
4772017-05-17T21:34:54  <luke-jr> maybe slightly less, but it seems to be pretty close
4782017-05-17T21:35:11  <BlueMatt> (and the differences between SFs and uasfs)
4792017-05-17T21:36:23  <Anduck> well, it's obvious that community wants segwit. now the big question is just how to deploy it
4802017-05-17T21:36:47  <Anduck> apparently masf is not working because some small part of community can keep it not happening
4812017-05-17T21:38:49  <BlueMatt> well activation method is a key part of any consensus rule change proposal
4822017-05-17T21:39:49  *** kadoban has quit IRC
4832017-05-17T21:42:51  *** kadoban has joined #bitcoin-core-dev
4842017-05-17T21:43:51  <gmaxwell> My view: Community and industry overwhelmingly want segwit. Given that
4852017-05-17T21:43:52  <gmaxwell> BIP148 is also something they would want but IF and only IF most everyone
4862017-05-17T21:43:54  <gmaxwell> else wants it. (because it's disruptive if partial).  So there is a symmerty
4872017-05-17T21:43:57  <gmaxwell> breaking problem.  Either ~everyone or ~no one should want it.
4882017-05-17T21:44:00  <gmaxwell> So if a sufficiently high profile group said they would do it, they'd
4892017-05-17T21:44:02  <gmaxwell> probably break the symmetry.  But we really don't want it to be us
4902017-05-17T21:44:05  <gmaxwell> in particular because it would feed the FUD that core controls this
4912017-05-17T21:44:08  <gmaxwell> or that (when really the whole thing would work because the support
4922017-05-17T21:44:10  <gmaxwell> for segwit is already overwhelming).  Unfortunately, everyone else
4932017-05-17T21:44:12  <gmaxwell> who would be a potential symmetry breaker has a starting disadvantage:
4942017-05-17T21:44:15  <gmaxwell> they're not known and trusted for pruducing software and BIP148
4952017-05-17T21:44:17  <gmaxwell> needs software.   We could ship BIP148 switchable and defaulted to
4962017-05-17T21:44:20  <gmaxwell> off but this raises a concern why not some other change: I would
4972017-05-17T21:44:22  <gmaxwell> point out that the ONLY argument against BIP148 given what we know
4982017-05-17T21:44:25  <gmaxwell> is that other people might not run it and the people who do run it
4992017-05-17T21:44:27  <gmaxwell> may be disrupted.. this doesn't hold for 12345MB blocks or whatever,
5002017-05-17T21:44:30  <gmaxwell> as there are solid issues there indpendant of the level of
5012017-05-17T21:44:32  <gmaxwell> popular support.
5022017-05-17T21:44:35  <gmaxwell> I've heard directly from people trying to push for BIP148 that they
5032017-05-17T21:44:37  <gmaxwell> felt undermined by the project's lack of implementation of the
5042017-05-17T21:44:40  <gmaxwell> mechenism.
5052017-05-17T21:45:43  <BlueMatt> I'm happy to ship code with an #ifdef NEVER_DEFINED_BIP148_IMPL_FLAG, but, otherwise, yes, totally agree with the above
5062017-05-17T21:46:08  *** jcliff42 has joined #bitcoin-core-dev
5072017-05-17T21:47:35  <sdf_0010> what is the reason for core not including BIP148 or similar as a switch defaulting to off?
5082017-05-17T21:48:30  <BlueMatt> sdf_0010: we dont ship software with a -maybeblowmyfaceoff=true option
5092017-05-17T21:48:35  <BlueMatt> sorry, we just dont
5102017-05-17T21:49:02  *** jcliff42 has quit IRC
5112017-05-17T21:49:40  <luke-jr> but not enforcing BIP 148 is more "blow my face off" than enforcing it :/
5122017-05-17T21:50:19  <luke-jr> (also, I'm pretty sure I can find such a flag.. but not the point :p)
5132017-05-17T21:50:22  <sdf_0010> it's hard to even take BlueMatt seriously if he is going to use such ridiculous language
5142017-05-17T21:51:02  <Anduck> BlueMatt: bip148 version "flavor" could be handed by core anyway. just with proper warnings everywhere, and good reasoning why core is making it
5152017-05-17T21:51:09  <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
5162017-05-17T21:51:29  <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?
5172017-05-17T21:52:49  <Anduck> ...
5182017-05-17T21:52:53  <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
5192017-05-17T21:52:56  <gmaxwell> sdf_0010: he's right, and I agree in general without agreeing in this case.
5202017-05-17T21:53:15  <BlueMatt> just like we merged the segwit code without activation flags on
5212017-05-17T21:53:29  <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.
5222017-05-17T21:53:31  <BlueMatt> there was no way to turn it on on mainnet (afair), but the code was all there
5232017-05-17T21:54:28  *** goksinen has joined #bitcoin-core-dev
5242017-05-17T21:54:31  <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
5252017-05-17T21:54:37  <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.
5262017-05-17T21:54:57  <gmaxwell> sdf_0010: better example is you can set dbcache higher than the amount of ram you have, and you'll crash.
5272017-05-17T21:55:07  <BlueMatt> sdf_0010: do you believe we should have an option that sends your private keys to me for analysis?
5282017-05-17T21:55:15  <gmaxwell> or you can set your fee levels really stupidly high.
5292017-05-17T21:55:30  <gmaxwell> but thats about as close to a suicide button as I think we get.
5302017-05-17T21:55:44  <sdf_0010> BlueMatt, are you evne trying to engage me with  in a genuine manner?
5312017-05-17T21:55:59  <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?
5322017-05-17T21:56:16  <gmaxwell> sdf_0010: he is, don't be fragile. :)
5332017-05-17T21:56:38  <BlueMatt> sdf_0010: I was eggagerating slightly to highlight the type of issue here
5342017-05-17T21:56:41  <gmaxwell> sdf_0010: bluematt wants to do the right thing, it's not a personal dispute. Don't take it that way.
5352017-05-17T21:56:43  <sdf_0010> asking rhetoical questions and pretending they are equivalent to my example is highly idiotic behavior or trollish
5362017-05-17T21:56:58  <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
5372017-05-17T21:57:08  <gmaxwell> achow101: pm me an email address and I'll share the contact sheet I used for segwit outreach.
5382017-05-17T21:57:09  <sdf_0010> and i do believe he isn't stupid, but pretending my exmaple and his are equivilent is purely idiotic
5392017-05-17T21:57:23  <BlueMatt> sdf_0010: actually, I believe they are highly analygous
5402017-05-17T21:57:28  <sdf_0010> haha
5412017-05-17T21:57:42  <BlueMatt> sdf_0010: maybe a better comparison is a flag to run bitcoin core on testnet but have everything pretend to be mainnet
5422017-05-17T21:58:04  <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
5432017-05-17T21:58:10  <BlueMatt> with valueless coins, but you are nonethewiser
5442017-05-17T21:58:11  *** sdf_0010 has left #bitcoin-core-dev
5452017-05-17T21:58:15  *** sdf_0010 has joined #bitcoin-core-dev
5462017-05-17T21:58:21  <BlueMatt> gmaxwell: if that is insufficient, then we should revisit the issue at that point, I believe
5472017-05-17T21:58:25  <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
5482017-05-17T21:58:59  <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
5492017-05-17T21:58:59  <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
5502017-05-17T21:59:27  *** goksinen has quit IRC
5512017-05-17T21:59:51  <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
5522017-05-17T21:59:56  <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.
5532017-05-17T22:00:43  <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
5542017-05-17T22:00:44  <BlueMatt> bitcoin even is
5552017-05-17T22:01:21  <luke-jr> gmaxwell: partial adoption is happening regardless though
5562017-05-17T22:01:25  <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.
5572017-05-17T22:01:53  <gmaxwell> if it's (say) 5% then it's just bad for the BIP148 users.
5582017-05-17T22:02:18  <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.
5592017-05-17T22:02:35  <morcos> BIP148 is essentially hot off the press, and we're already trying to merge it
5602017-05-17T22:02:42  <gmaxwell> morcos: +1
5612017-05-17T22:02:44  <morcos> This is premature by at least 6 months, if not a year
5622017-05-17T22:02:51  <gmaxwell> morcos: we'll be 'we' you mean like luke. :P
5632017-05-17T22:03:28  <BlueMatt> yea, that too
5642017-05-17T22:03:31  <morcos> well, i just think it shouldn't even be a conversation at this point (about merging).  Debating the overal merits makes sense
5652017-05-17T22:03:31  *** kadoban has quit IRC
5662017-05-17T22:04:01  <luke-jr> morcos: BIP148 is 2 months old, and IMO better than any hypothetical alternative; anything else will require a redeployment
5672017-05-17T22:04:02  <gmaxwell> yea, I think it's useful to talk through it.. thats how you get to maturity 6months henceforth, as you suggested.
5682017-05-17T22:04:22  <gmaxwell> luke-jr: as I've said before, you're really overvaluing the redeployment cost.
5692017-05-17T22:04:32  <gmaxwell> Yea, sure, it'll cause developer effort but thats what we signed up for.
5702017-05-17T22:04:41  <luke-jr> gmaxwell: I don't think I am. Consider how much additional work segwit required that we didn't anticipate.
5712017-05-17T22:04:45  <BlueMatt> yea, luckily the parameter space here is rather well-defined and somewhat limited, so its not a particularly extended discussion, I'd hope
5722017-05-17T22:05:22  <gmaxwell> luke-jr: segwit finished astonishingly quickly.
5732017-05-17T22:06:02  <luke-jr> what? it was several months later than planned
5742017-05-17T22:06:05  <Anduck> morcos: good point. i guess the main hurry comes from btc/usd and altcoin valuations
5752017-05-17T22:08:28  <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.
5762017-05-17T22:08:45  <gmaxwell> luke-jr: no it was several months later than idiotic estimates.
5772017-05-17T22:09:05  <gmaxwell> If you reacall I was pointing out those estimates were absurd in january.
5782017-05-17T22:09:40  <gmaxwell> Did you not even listen to the example I gave you earlier about 4 byte ASNs in BGP?  It took a _decade_.
5792017-05-17T22:10:04  <BlueMatt> *ahem* IPv6 *ahem*
5802017-05-17T22:10:26  <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)
5812017-05-17T22:10:49  <BlueMatt> did you....segregate the last 2 bytes :p
5822017-05-17T22:11:26  <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.
5832017-05-17T22:13:08  <luke-jr> AFAICT that analogy is about segwit, not BIP148
5842017-05-17T22:13:18  <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. :) )
5852017-05-17T22:13:23  <gmaxwell> luke-jr: sure but BIP148 is about segwit.
5862017-05-17T22:13:32  <gmaxwell> It's about getting segwit deployed faster.
5872017-05-17T22:13:33  <luke-jr> BIP148 is about segwit, but BIP148 itself is very simple
5882017-05-17T22:13:44  <gmaxwell> yea, BIP148 is very simple, I agree.
5892017-05-17T22:13:48  *** kadoban has joined #bitcoin-core-dev
5902017-05-17T22:14:10  <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.
5912017-05-17T22:14:28  <luke-jr> then why didn't we set the timeout later?
5922017-05-17T22:14:41  <gmaxwell> even in protocols with far less demands than ours-- like BGP for example-- upgrades take a long time.
5932017-05-17T22:15:09  <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.
5942017-05-17T22:15:29  <gmaxwell> No one thought through that for segwit (unlike most SF) it's a bit harder to just renew. Ooops.
5952017-05-17T22:15:39  <achow101> gmaxwell: but to keep renewing it requires everyone to upgrade yet again
5962017-05-17T22:15:40  <gmaxwell> if not for that I think we'd already have a renewal staged in master.
5972017-05-17T22:16: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. :)
5982017-05-17T22:16:31  <luke-jr> gmaxwell: I don't see a reason in this, to make BIP148 fail and split the chain.
5992017-05-17T22:16:36  <gmaxwell> it's perhaps an argument that the BIP9 timeout default should be more like 2 or three years.
6002017-05-17T22:17:24  <gmaxwell> luke-jr: no one has to run BIP148.
6012017-05-17T22:17:43  <luke-jr> gmaxwell: a non-trivial amount of the community will be doing so
6022017-05-17T22:17:58  * BlueMatt goes back to work
6032017-05-17T22:18:47  <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.
6042017-05-17T22:18:50  * morcos hopes BlueMatt figures out his address problems
6052017-05-17T22:19:07  <BlueMatt> morcos: ugh, i started looking at other node behavior and then got distrcated by bullshit
6062017-05-17T22:23:15  <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
6072017-05-17T22:23:56  <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
6082017-05-17T22:24:47  <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
6092017-05-17T22:26:15  <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
6102017-05-17T22:28:20  <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
6112017-05-17T22:30:44  <Anduck> bgp is not comparable to bitcoin because there's no competitor. nobody gains anything if they get bgp replaced by something else
6122017-05-17T22:33:23  <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
6132017-05-17T22:42:33  *** lichtamberg_ has joined #bitcoin-core-dev
6142017-05-17T22:43:02  <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?
6152017-05-17T22:43:02  <lichtamberg_> I cannot understand why there is such a strong stand against a toggle option...
6162017-05-17T22:43:02  <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..
6172017-05-17T22:43:35  <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
6182017-05-17T22:44:22  <Anduck> in a sense, it's irresponsible to give user an option to fail horribly.
6192017-05-17T22:45:07  <lichtamberg_> it's also irresponsible to remove the option if the community support is getting enough traction
6202017-05-17T22:45:56  <lichtamberg_> you are only thinking about the failing part… but look on reddit
6212017-05-17T22:46:06  <lichtamberg_> a not so small part of the community will go this way
6222017-05-17T22:47:21  <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?
6232017-05-17T22:47:22  <lichtamberg_> and as far as I know, this is the biggest community movement which we ever saw until now?
6242017-05-17T22:47:37  *** cryptapus has joined #bitcoin-core-dev
6252017-05-17T22:47:43  *** cryptapus is now known as cryptapus_afk
6262017-05-17T22:48:32  <Anduck> like, should core offer the best and safest product available and have no comment in ANY kind of protocol updates?
6272017-05-17T22:49:16  <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
6282017-05-17T22:51:01  <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)
6292017-05-17T22:53:27  *** dermoth has quit IRC
6302017-05-17T22:55:57  <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.
6312017-05-17T22:57:26  *** dermoth has joined #bitcoin-core-dev
6322017-05-17T22:57:31  <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
6332017-05-17T22:58:27  <luke-jr> Anduck: in this case, it's not "no comment", it's actively anti-BIP148.
6342017-05-17T22:59:22  <Anduck> or pro-no-disruption-to-the-system ?
6352017-05-17T22:59:43  <Anduck> segwit masf was defined as only activated if miners choose so. it's disruption to change this now
6362017-05-17T23:00:25  <luke-jr> Anduck: nope, Core's current anti-BIP148 position increases the disruption
6372017-05-17T23:00:32  <Anduck> no matter how sane it would be if it wasn't so disruptive
6382017-05-17T23:00:50  <Anduck> luke-jr: well, that's an opinion only. there are tons of factors to consider --most of them are unknown.
6392017-05-17T23:01:38  <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"
6402017-05-17T23:02:16  <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
6412017-05-17T23:03:47  *** Squidicc has joined #bitcoin-core-dev
6422017-05-17T23:05:16  <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… :)
6432017-05-17T23:05:36  <Anduck> "If all core members would support BIP148, we could do it really easily" << i disagree.
6442017-05-17T23:06:12  <lichtamberg_> i disagree with your disagreement :D
6452017-05-17T23:06:29  <lichtamberg_> we have so much support for segwit
6462017-05-17T23:06:35  <lichtamberg_> there is such a big hype about UASF
6472017-05-17T23:06:56  <lichtamberg_> the only ones which are missing are: the miners (obviously) - and core
6482017-05-17T23:07:02  <Anduck> could be that you're right. could be that you're not. i think hype for bip148 is largely hype only.
6492017-05-17T23:07:24  <Anduck> reddit is only one small piece of the community.
6502017-05-17T23:07:25  <lichtamberg_> hard to measure that, but I dont think so
6512017-05-17T23:07:30  <Anduck> i don't see big companies supporting uasf either
6522017-05-17T23:07:39  *** Squidicuz has quit IRC
6532017-05-17T23:08:11  <lichtamberg_> they are just scared to be the first one… first mover effect..
6542017-05-17T23:08:22  <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)
6552017-05-17T23:09:10  <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
6562017-05-17T23:09:19  <Anduck> we've already seen signals about this phenomenon
6572017-05-17T23:09:41  <Anduck> not only in bitcoin scene, that is
6582017-05-17T23:10:59  <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
6592017-05-17T23:11:48  *** chjj has quit IRC
6602017-05-17T23:12:50  *** goksinen has joined #bitcoin-core-dev
6612017-05-17T23:17:31  *** goksinen has quit IRC
6622017-05-17T23:20:02  *** goksinen has joined #bitcoin-core-dev
6632017-05-17T23:20:52  *** harrymm has quit IRC
6642017-05-17T23:21:32  *** goksinen has quit IRC
6652017-05-17T23:24:31  *** chjj has joined #bitcoin-core-dev
6662017-05-17T23:24:39  *** wangchun has quit IRC
6672017-05-17T23:25:56  *** wangchun has joined #bitcoin-core-dev
6682017-05-17T23:27:47  *** lichtamberg_ has quit IRC
6692017-05-17T23:40:37  *** harrymm has joined #bitcoin-core-dev
6702017-05-17T23:49:05  *** harrymm has quit IRC
6712017-05-17T23:53:12  *** fengling has quit IRC
6722017-05-17T23:54:32  *** fengling has joined #bitcoin-core-dev