1 2017-05-17 01:42:00	0|achow101|what's everyone's thoughts on bip 148 and 149?
  2 2017-05-17 01:52:51	0|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
  3 2017-05-17 01:57:06	0|Chris_Stewart_5|unless they fail somehow silently by not having nodes upgrade
  4 2017-05-17 02:01:04	0|Chris_Stewart_5|If I understand BIP148 correctly, it is advocating for oprhaning > 50% of the hash rates blocks?
  5 2017-05-17 02:01:07	0|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. "
  6 2017-05-17 02:03:07	0|sipa|Chris_Stewart_5: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
  7 2017-05-17 02:14:12	0|bitcoin-git|[13bitcoin] 15RHavar opened pull request #10413: Fix docs (there's no rpc command setpaytxfee) (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/10413
  8 2017-05-17 02:24:56	0|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?
  9 2017-05-17 02:25:23	0|sipa|that's already the case
 10 2017-05-17 02:25:49	0|sipa|if you connect miner software that doesn't support segwit to bitcoind, GBT will only include non-segwit txn
 11 2017-05-17 02:26:12	0|sipa|(since 0.14)
 12 2017-05-17 03:09:23	0|luke-jr|Chris_Stewart_5: no, it's advocating for 100% of the hashrate to signal segwit
 13 2017-05-17 03:09:30	0|luke-jr|very strongly advocating
 14 2017-05-17 05:44:59	0|gmaxwell|aww
 15 2017-05-17 05:45:01	0|gmaxwell|2017-05-17 05:43:33 Recovering log #177650
 16 2017-05-17 05:45:01	0|gmaxwell|2017-05-17 05:43:35 /home/gmaxwell/.bitcoin/blocks/index/177650.log: dropping 30275 bytes; Corruption: checksum mismatch
 17 2017-05-17 05:45:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/177650 | HTTP Error 404: Not Found
 18 2017-05-17 05:45:04	0|gmaxwell|2017-05-17 05:43:35 Corruption: checksum mismatch
 19 2017-05-17 05:45:05	0|gmaxwell|saddness.
 20 2017-05-17 05:45:07	0|gmaxwell|2017-05-17 05:43:35 Database corrupted
 21 2017-05-17 06:05:23	0|gmaxwell|also telling me to reindex chainstate on a blocks index corruption isn't so helpful.
 22 2017-05-17 06:11:46	0|bitcoin-git|13bitcoin/06master 141530bfc 15Suhas Daftuar: Add logging to FinalizeNode()
 23 2017-05-17 06:11:46	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/95546c859b71...b45a52aeff0a
 24 2017-05-17 06:11:47	0|bitcoin-git|13bitcoin/06master 14b45a52a 15Wladimir J. van der Laan: Merge #10404: doc: Add logging to FinalizeNode()...
 25 2017-05-17 06:12:19	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10404: doc: Add logging to FinalizeNode() (06master...062017-05-log-finalize-node) 02https://github.com/bitcoin/bitcoin/pull/10404
 26 2017-05-17 06:13:11	0|bitcoin-git|13bitcoin/06master 14fac79e4 15MarcoFalke: qa: Warn when specified test is not found
 27 2017-05-17 06:13:11	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b45a52aeff0a...541199788c10
 28 2017-05-17 06:13:12	0|bitcoin-git|13bitcoin/06master 145411997 15Wladimir J. van der Laan: Merge #10374: qa: Warn when specified test is not found...
 29 2017-05-17 06:13:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10374: qa: Warn when specified test is not found (06master...06Mf1705-qaWarnTestNotFound) 02https://github.com/bitcoin/bitcoin/pull/10374
 30 2017-05-17 06:22:04	0|paveljanik|jtimon, ping
 31 2017-05-17 06:23:20	0|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?
 32 2017-05-17 06:24:04	0|paveljanik|The same applies to IsDust
 33 2017-05-17 07:12:39	0|bitcoin-git|13bitcoin/06master 14bc63d0e 15Pedro Branco: Add query options to listunspent rpc call
 34 2017-05-17 07:12:39	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/541199788c10...9390845c53e3
 35 2017-05-17 07:12:40	0|bitcoin-git|13bitcoin/06master 149390845 15Wladimir J. van der Laan: Merge #8952: Add query options to listunspent RPC call...
 36 2017-05-17 08:45:53	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9403: Don't ask for TX relay from feeler connections (06master...06NoRelayForFeelers) 02https://github.com/bitcoin/bitcoin/pull/9403
 37 2017-05-17 08:46:52	0|bitcoin-git|13bitcoin/06master 140f1b26a 15Ryan Havar: Fix docs (there's no rpc command setpaytxfee)
 38 2017-05-17 08:46:52	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9390845c53e3...08ac35a7e3ef
 39 2017-05-17 08:46:53	0|bitcoin-git|13bitcoin/06master 1408ac35a 15Wladimir J. van der Laan: Merge #10413: Fix docs (there's no rpc command setpaytxfee)...
 40 2017-05-17 08:47:29	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9704: Store downloaded blocks prior to shutdown. (06master...06StoreBlocksAtShutdown) 02https://github.com/bitcoin/bitcoin/pull/9704
 41 2017-05-17 08:49:43	0|fanquake|wumpus I'm just closing a bunch of PRs that haven't garnered any discussion and/or have needed rebasing for some time.
 42 2017-05-17 08:50:01	0|wumpus|fanquake: thanks!
 43 2017-05-17 08:50:59	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #8958: Improve logic for advertising blocks (06master...06BetterBroadcastLogic) 02https://github.com/bitcoin/bitcoin/pull/8958
 44 2017-05-17 08:52:24	0|bitcoin-git|13bitcoin/06master 142f84cf6 15Wladimir J. van der Laan: tests: Correct testcase in script_tests.json for large number OP_EQUAL...
 45 2017-05-17 08:52:24	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/08ac35a7e3ef...0542978aae12
 46 2017-05-17 08:52:25	0|bitcoin-git|13bitcoin/06master 140542978 15Wladimir J. van der Laan: Merge #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL...
 47 2017-05-17 08:52:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL (06master...062017_05_scriptnum_test) 02https://github.com/bitcoin/bitcoin/pull/10405
 48 2017-05-17 08:53:06	0|wumpus|gmaxwell: any idea what caused the corruption?
 49 2017-05-17 08:54:00	0|wumpus|darn it's in a log file, ideally it would regard CRC errors in the log simply as truncation
 50 2017-05-17 08:54:09	0|gmaxwell|I think likely just many unclean power offs..
 51 2017-05-17 08:54:24	0|gmaxwell|I think it does at a lower sanity checking level.
 52 2017-05-17 08:54:48	0|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
 53 2017-05-17 08:54:53	0|wumpus|right
 54 2017-05-17 08:55:29	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9091: Optimize sending of getheaders when pindexLast is an ancestor of pindexBestHeader (06master...06OptimizeMoreGetheaders) 02https://github.com/bitcoin/bitcoin/pull/9091
 55 2017-05-17 09:06:03	0|fanquake|wumpus got a utACK from cfields on #7522, did you want to merge it?
 56 2017-05-17 09:06:05	0|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
 57 2017-05-17 09:06:54	0|wumpus|ah yes let's merge it
 58 2017-05-17 09:07:21	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0542978aae12...d25449f85862
 59 2017-05-17 09:07:22	0|bitcoin-git|13bitcoin/06master 14df63490 15Luke Dashjr: Merge tag 'branch-0.13' into bugfix_gitdir
 60 2017-05-17 09:07:22	0|bitcoin-git|13bitcoin/06master 14e98e3dd 15Luke Dashjr: Bugfix: Only use git for build info if the repository is actually the right one...
 61 2017-05-17 09:07:23	0|bitcoin-git|13bitcoin/06master 14ed1fcdc 15Luke Dashjr: Bugfix: Detect genbuild.sh in repo correctly
 62 2017-05-17 09:11:21	0|fanquake|wumpus Looks like #10319 is good to merge also.
 63 2017-05-17 09:11:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10319 | Remove unused argument from MarkBlockAsInFlight(...) by practicalswift · Pull Request #10319 · bitcoin/bitcoin · GitHub
 64 2017-05-17 09:12:19	0|wumpus|fanquake: yep
 65 2017-05-17 09:13:00	0|wumpus|fanquake: I wasn't sure there, because I'm fairly sure that argument was only added recently
 66 2017-05-17 09:13:46	0|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
 67 2017-05-17 09:14:17	0|wumpus|maybe we should ask jtimon
 68 2017-05-17 09:14:38	0|wumpus|not that I'd mind just merging it, but I don't want to sabotage anyone's work in progress
 69 2017-05-17 09:15:54	0|wumpus|ok I see sdaftuar added it and now is ok with removing it
 70 2017-05-17 09:15:58	0|fanquake|wumpus ok. I'll ping him in that PR.
 71 2017-05-17 09:16:17	0|wumpus|fanquake: not necessary, I think
 72 2017-05-17 09:16:26	0|wumpus|he's not involved with this one
 73 2017-05-17 09:16:46	0|fanquake|wumpus All good then. #10388 should also be ok to merge.
 74 2017-05-17 09:16:47	0|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
 75 2017-05-17 09:17:01	0|bitcoin-git|13bitcoin/06master 146345f0b 15practicalswift: Remove unused argument from MarkBlockAsInFlight(...)
 76 2017-05-17 09:17:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d25449f85862...32f671b14107
 77 2017-05-17 09:17:02	0|bitcoin-git|13bitcoin/06master 1432f671b 15Wladimir J. van der Laan: Merge #10319: Remove unused argument from MarkBlockAsInFlight(...)...
 78 2017-05-17 09:17:26	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10319: Remove unused argument from MarkBlockAsInFlight(...) (06master...06remove-unused-argument) 02https://github.com/bitcoin/bitcoin/pull/10319
 79 2017-05-17 09:18:29	0|wumpus|yep
 80 2017-05-17 09:18:47	0|bitcoin-git|13bitcoin/06master 1465d484a 15Alex Morcos: Output line to debug.log when IsInitialBlockDownload latches to false
 81 2017-05-17 09:18:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/32f671b14107...526e8390e6be
 82 2017-05-17 09:18:48	0|bitcoin-git|13bitcoin/06master 14526e839 15Wladimir J. van der Laan: Merge #10388: Output line to debug.log when IsInitialBlockDownload latches to false...
 83 2017-05-17 09:19:22	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10388: Output line to debug.log when IsInitialBlockDownload latches to false (06master...06printIBD) 02https://github.com/bitcoin/bitcoin/pull/10388
 84 2017-05-17 09:20:57	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9325: Allow first cmpctblock/blocktxn received to be processed (rather than first requested) (06master...06ProcessFirstCmpct) 02https://github.com/bitcoin/bitcoin/pull/9325
 85 2017-05-17 09:23:18	0|fanquake|Good amount of Boost code being removed pre 0.15.
 86 2017-05-17 09:32:39	0|fanquake|Recent CVE (CVE-2017-8798) in miniupnpc. Committed fix: https://github.com/miniupnp/miniupnp/commit/f0f1f4b22d6a98536377a1bb07e7c20e4703d229
 87 2017-05-17 09:37:54	0|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
 88 2017-05-17 09:46:39	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #10414: [depends] miniupnpc 2.0.20170509 (06master...06depends-miniupnpc-2-0-20170509) 02https://github.com/bitcoin/bitcoin/pull/10414
 89 2017-05-17 10:40:32	0|wumpus|fanquake: yes, another (possibly exploitable) miniupnpc vuln, happy we don't have enabled by default anymore, still yes we should bump the version
 90 2017-05-17 10:54:53	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10415: [fuzz] Speed up fuzzing by ~200x when using afl-fuzz (06master...06fast-afl-fuzzing) 02https://github.com/bitcoin/bitcoin/pull/10415
 91 2017-05-17 11:52:59	0|SopaXorzTaker|Uhm, guys?..
 92 2017-05-17 11:53:16	0|SopaXorzTaker|we have a problem - P2SH addresses only depend on the security of RIPEMD-160
 93 2017-05-17 11:53:57	0|wumpus|please, #bitcoin
 94 2017-05-17 11:54:10	0|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
 95 2017-05-17 11:54:25	0|wumpus|again, #bitcoin, this is not the place to discuss the protocol in general
 96 2017-05-17 11:54:26	0|SopaXorzTaker|banned from #bitcoin for spreading bullsh*t
 97 2017-05-17 12:03:24	0|cypherbit|join bitcoin
 98 2017-05-17 13:12:28	0|jtimon|paveljanik: morcos asked not to remove the argument, so probably just renaming the argument is the less disruptive thing
 99 2017-05-17 13:40:43	0|fanquake|jonasschnelli Your PR/Nightly build server is pretty fancy now. Good work.
100 2017-05-17 13:40:54	0|jonasschnelli|fanquake: heh. Yeah... UI matters. :)
101 2017-05-17 13:42:23	0|fanquake|I can remember when it was basically a file directory. A lot more useful information now!
102 2017-05-17 14:43:29	0|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?
103 2017-05-17 14:46:05	0|luke-jr|timothy: it's technically illegal to redistribute :/  probably better off just waiting
104 2017-05-17 14:46:41	0|luke-jr|timothy: btw, you're the Arch package maintainer, right? I had heard the packages were outdated (but that was a while ago..)
105 2017-05-17 14:50:36	0|midnightmagic|It's also not really worth much if you take a closed-source distribution package from some rando on IRC. :-)
106 2017-05-17 15:03:48	0|timothy|midnightmagic: not really, in gitian files there is the sha256sum of the tar
107 2017-05-17 15:04:21	0|timothy|b49f056b0a3d88cb4def52aa612dc23084eade8699f853f68b4a4456daa7ddb6 MacOSX10.11.sdk.tar.gz
108 2017-05-17 15:04:47	0|timothy|if it's the same for anybody
109 2017-05-17 15:11:47	0|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
110 2017-05-17 15:12:20	0|jonasschnelli|sipa: Would support for Bech32 without hrp make sense in the ref. impl?
111 2017-05-17 15:12:22	0|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
112 2017-05-17 15:12:52	0|jonasschnelli|sipa: it's a simple change and allow to reuse Bech32 for other stuff...
113 2017-05-17 15:13:03	0|jonasschnelli|(where size matters)
114 2017-05-17 15:14:13	0|gmaxwell|jonasschnelli: without the HRP you'll decode strings for one application as correct for another-- mooting the fancy protection.
115 2017-05-17 15:15:22	0|jonasschnelli|gmaxwell: A single magic 5bit value inside the Bech32 would save 1char (the separator)...
116 2017-05-17 15:15:30	0|jonasschnelli|But maybe I'm wrong.
117 2017-05-17 15:16:35	0|jonasschnelli|I don't say we should throw it away.. just maybe the ref. impl. could support enc/dec Bech32 without the hrp
118 2017-05-17 15:17:10	0|jonasschnelli|(working on a use case where size really matters)
119 2017-05-17 15:21:01	0|gmaxwell|can't you prefill the prefix?
120 2017-05-17 15:22:12	0|midnightmagic|timothy: pretty sure it's not, unless there's some new tarball-maker for that..?
121 2017-05-17 15:33:31	0|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.
122 2017-05-17 15:36:42	0|jonasschnelli|But I guess I'm again micro-optimizing... so nm
123 2017-05-17 15:49:20	0|sipa|jonasschnelli: i would suggest you don't change the reference implementation, but just prefix a constant HRP before calling it
124 2017-05-17 15:50:03	0|jonasschnelli|sipa: Aha. Now I understand... yes. Much simpler.
125 2017-05-17 16:18:17	0|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
126 2017-05-17 16:20:27	0|wumpus|you might have to refresh my key in any case
127 2017-05-17 16:22:01	0|gmaxwell|jonasschnelli: sorry, thats what I meant by prefill the prefix.
128 2017-05-17 16:24:29	0|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.
129 2017-05-17 16:24:39	0|jonasschnelli|wumpus: Thanks for the info
130 2017-05-17 16:52:23	0|bitcoin-git|13bitcoin/06master 14d4668f3 15Jimmy Song: [test] Add test for getmemoryinfo...
131 2017-05-17 16:52:23	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/526e8390e6be...ea1fd43bb9a3
132 2017-05-17 16:52:24	0|bitcoin-git|13bitcoin/06master 14ea1fd43 15Wladimir J. van der Laan: Merge #10257: [test] Add test for getmemoryinfo...
133 2017-05-17 16:52:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10257: [test] Add test for getmemoryinfo (06master...06test_getmemoryinfo) 02https://github.com/bitcoin/bitcoin/pull/10257
134 2017-05-17 16:58:13	0|paveljanik|jtimon, morcos: OK, will PR it later to prevent warning with your comments included for future reference.
135 2017-05-17 16:58:23	0|paveljanik|(or someone else can do it ;-)
136 2017-05-17 17:28:11	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #10417: BIP 148 support (06master...06master-BIP148) 02https://github.com/bitcoin/bitcoin/pull/10417
137 2017-05-17 18:58:53	0|bitcoin-git|13bitcoin/06master 14af5d48c 15fanquake: [depends] miniupnpc 2.0.20170509
138 2017-05-17 18:58:53	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ea1fd43bb9a3...e61fc2d7cb4f
139 2017-05-17 18:58:54	0|bitcoin-git|13bitcoin/06master 14e61fc2d 15Wladimir J. van der Laan: Merge #10414: [depends] miniupnpc 2.0.20170509...
140 2017-05-17 18:59:30	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10414: [depends] miniupnpc 2.0.20170509 (06master...06depends-miniupnpc-2-0-20170509) 02https://github.com/bitcoin/bitcoin/pull/10414
141 2017-05-17 18:59:50	0|bitcoin-git|13bitcoin/060.13 148adf75e 15fanquake: [depends] miniupnpc 2.0.20170509...
142 2017-05-17 18:59:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/8adf75e6a124267da1ae46be1eee50c52ce6082b
143 2017-05-17 20:15:33	0|bitcoin-git|[13bitcoin] 15sipa pushed 16 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e61fc2d7cb4f...318ea50a1c2f
144 2017-05-17 20:15:34	0|bitcoin-git|13bitcoin/06master 14c0a273f 15Alex Morcos: Change file format for fee estimates....
145 2017-05-17 20:15:34	0|bitcoin-git|13bitcoin/06master 14e5007ba 15Alex Morcos: Change parameters for fee estimation and estimates on all 3 time horizons....
146 2017-05-17 20:15:35	0|bitcoin-git|13bitcoin/06master 14d3e30bc 15Alex Morcos: Refactor to update moving average on fly
147 2017-05-17 20:16:02	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10199: Better fee estimates (06master...06smarterfee) 02https://github.com/bitcoin/bitcoin/pull/10199
148 2017-05-17 20:23:22	0|morcos|sipa:  yikes!  thanks, i think
149 2017-05-17 20:25:49	0|bitcoin-git|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/318ea50a1c2f...bee35299716c
150 2017-05-17 20:25:50	0|bitcoin-git|13bitcoin/06master 146c2e25c 15Suhas Daftuar: [qa] Test prioritise_transaction / getblocktemplate interaction
151 2017-05-17 20:25:50	0|bitcoin-git|13bitcoin/06master 14acc2e4b 15Suhas Daftuar: Bugfix: PrioritiseTransaction updates the mempool tx counter...
152 2017-05-17 20:25:51	0|bitcoin-git|13bitcoin/06master 14bee3529 15Pieter Wuille: Merge #10196: Bugfix: PrioritiseTransaction updates the mempool tx counter...
153 2017-05-17 20:26:14	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10196: Bugfix: PrioritiseTransaction updates the mempool tx counter (06master...062017-04-prioritise-transaction) 02https://github.com/bitcoin/bitcoin/pull/10196
154 2017-05-17 20:54:14	0|achow101|would it be possible to ban wewillfindyou? He's derailing and possibly trolling #10417
155 2017-05-17 20:54:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/10417 | BIP 148 support by achow101 · Pull Request #10417 · bitcoin/bitcoin · GitHub
156 2017-05-17 20:57:09	0|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
157 2017-05-17 20:57:11	0|sipa|achow101: done
158 2017-05-17 20:57:38	0|achow101|ty
159 2017-05-17 20:57:41	0|sipa|Chris_Stewart_5: signalling for BU != running BU
160 2017-05-17 20:58:12	0|achow101|Chris_Stewart_5: they shouldn't select segwit txs though since they are non-standard under current rules
161 2017-05-17 20:59:35	0|Chris_Stewart_5|achow101: P2SH(P2WPKH or P2WSH) would be wouldn't it?
162 2017-05-17 20:59:47	0|sipa|Chris_Stewart_5: no
163 2017-05-17 21:00:00	0|sipa|those still require a spend that violates the CLEANSTACK rule
164 2017-05-17 21:00:10	0|sipa|which has been in every release since 0.11
165 2017-05-17 21:00:41	0|achow101|the transactions creating the p2sh nested outputs themselves are find and can be mined. the spending transaction is not
166 2017-05-17 21:00:50	0|achow101|s/find/fine/
167 2017-05-17 21:01:48	0|luke-jr|(and mining those p2sh txs won't be a problem for the BU blocks)
168 2017-05-17 21:10:34	0|BlueMatt|luke-jr: this is absurd, do you seriously believe the vast, vast majority of bitcoin users (incl businesses) support bip 148?
169 2017-05-17 21:10:58	0|gmaxwell|he believes they support segwit, which is super clear at this point.
170 2017-05-17 21:11:25	0|BlueMatt|bip 148 != segwit, they are different proposed consensus changes, despite sharing many features
171 2017-05-17 21:11:27	0|luke-jr|BlueMatt: businesses exist to serve the users
172 2017-05-17 21:11:45	0|gmaxwell|yea, I'm not arguing that they're the same, just trying to clarify luke's position the way I understand it.
173 2017-05-17 21:11:54	0|luke-jr|BlueMatt: and so far, the businesses are taking a hardline position of "we will run Core only"
174 2017-05-17 21:11:56	0|gmaxwell|Chris_Stewart_5: No it won't.
175 2017-05-17 21:12:00	0|luke-jr|which is half the reason we need to merge it in Core
176 2017-05-17 21:12:35	0|luke-jr|if businesses weren't being stupid about this, I'd prefer BIP148 activate without Core. but reality is what it is
177 2017-05-17 21:12:40	0|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
178 2017-05-17 21:14:19	0|luke-jr|the only "opposition" (besides trolls) I see to BIP148, is the mistaken belief that it won't or can't work
179 2017-05-17 21:14:38	0|gmaxwell|it's very disruptive if it isn't an overwhelming success.
180 2017-05-17 21:14:47	0|sipa|it can only work if everyone adopts it
181 2017-05-17 21:14:55	0|sipa|it is not our job to push for that
182 2017-05-17 21:15:17	0|luke-jr|gmaxwell: which is why it's important to ensure it's an overwhelming success.
183 2017-05-17 21:15:21	0|BlueMatt|it is not bitcoin core's job to merge something *until* that exists, irrespective of whether individual contributors are pushing for it
184 2017-05-17 21:15:53	0|luke-jr|BlueMatt: until what exists?
185 2017-05-17 21:16:04	0|BlueMatt|ovherwhelming support across the ecosystem
186 2017-05-17 21:16:16	0|luke-jr|that pretty much exists to the extent it can without Core merging it.
187 2017-05-17 21:16:26	0|luke-jr|businesses will run whatever Core releases, and won't run what Core won't release.
188 2017-05-17 21:16:30	0|luke-jr|it sucks, but that's how it is right now
189 2017-05-17 21:17:10	0|sipa|and they do that, hopefully because they believe we're making sane choices of what is included in a release
190 2017-05-17 21:17:11	0|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
191 2017-05-17 21:17:24	0|BlueMatt|plus as many polls as you can possibly create at physical meetups
192 2017-05-17 21:17:27	0|BlueMatt|and then get back to me
193 2017-05-17 21:18:54	0|luke-jr|sipa: missing the point. it creates chicken-and-egg
194 2017-05-17 21:19:22	0|BlueMatt|not entirely, the chicken-and-egg problem can be solved by active outreach
195 2017-05-17 21:19:23	0|gmaxwell|BlueMatt: hopefully not your intent, but you did just make it sound like only business mattter.
196 2017-05-17 21:19:29	0|BlueMatt|something that I have yet to see literally any of
197 2017-05-17 21:19:44	0|BlueMatt|gmaxwell: fair, yes, that tis not at all my intent, hence the mention of physical meetups
198 2017-05-17 21:19:55	0|luke-jr|BlueMatt: no, because the businesses will NEVER run BIP148 until Core merges it
199 2017-05-17 21:20:00	0|BlueMatt|businesses do matter, but, indeed, only as much as every other group
200 2017-05-17 21:20:11	0|BlueMatt|luke-jr: we did it with segwit and got back overwhelmingly positive response!
201 2017-05-17 21:20:30	0|BlueMatt|prior to the parameters being merged
202 2017-05-17 21:20:35	0|luke-jr|besides half the businesses supporting Classic back then..
203 2017-05-17 21:20:55	0|BlueMatt|we got back 0 negative responses
204 2017-05-17 21:21:01	0|BlueMatt|0
205 2017-05-17 21:21:28	0|BlueMatt|on top of people doing physical outreach and talking to various groups at meetups, plus discussions with long-time bitcoin holders and investors
206 2017-05-17 21:21:35	0|gmaxwell|BlueMatt: no, not true, we got a response from one webwallet vendor saying they prefer it be delayed a few months.
207 2017-05-17 21:21:52	0|gmaxwell|BlueMatt: the was the only negative response.. And I got more than a 50% response rate.
208 2017-05-17 21:22:06	0|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"
209 2017-05-17 21:22:25	0|BlueMatt|well, ok, mostly you got, but ok :)
210 2017-05-17 21:22:57	0|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".
211 2017-05-17 21:23:08	0|BlueMatt|oh, somehow i misrecalled, sorry
212 2017-05-17 21:24:36	0|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?
213 2017-05-17 21:24:49	0|sipa|luke-jr: i personally don't believe BIP148 will happen
214 2017-05-17 21:24:59	0|luke-jr|sipa: it will, even if it is a minority chain splitting off
215 2017-05-17 21:25:07	0|BlueMatt|business + broad user study
216 2017-05-17 21:25:12	0|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
217 2017-05-17 21:25:46	0|sipa|if core merges bip148 as a default option, it will just make people run other software instead, and the same will happen
218 2017-05-17 21:26:13	0|luke-jr|people who are making a conscious decision on what software to run, are switching to BIP148 nodes or at least uacomments
219 2017-05-17 21:26:17	0|sipa|this is my expectation, and i certainly may be wrong
220 2017-05-17 21:26:24	0|BlueMatt|luke-jr: do you not agree that we should be, above all, absolutely and strictly requiring consensus for any consensus rule changes?
221 2017-05-17 21:26:42	0|luke-jr|BlueMatt: not for softforks, no. otherwise Segwit should never have been merged.
222 2017-05-17 21:27:02	0|BlueMatt|bip 148 has many of the upgrade properties of a hf
223 2017-05-17 21:27:05	0|luke-jr|Segwit is absolutely contentious. But it has sufficient support to merge as a softfork.
224 2017-05-17 21:27:10	0|BlueMatt|from that perspective bip 148 is closer to a hf than a sf, by far
225 2017-05-17 21:27:31	0|sipa|luke-jr: and bip148 obviously does not
226 2017-05-17 21:27:33	0|BlueMatt|segwit contention is overstated, in my experience
227 2017-05-17 21:27:39	0|sipa|luke-jr: i don't understand why we're even discussing this
228 2017-05-17 21:27:41	0|luke-jr|I don't agree. BIP 148 only needs a majority to avoid a split.
229 2017-05-17 21:27:44	0|Anduck|maybe core should publish two versions.
230 2017-05-17 21:27:54	0|luke-jr|Anduck: there's an interesting idea
231 2017-05-17 21:27:55	0|BlueMatt|Anduck: we do *not* ship code with a massive face cannon built in
232 2017-05-17 21:28:11	0|BlueMatt|you're welcome to, however :p
233 2017-05-17 21:28:33	0|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?
234 2017-05-17 21:28:44	0|BlueMatt|but, yea, I'm with sipa, this is fucking stupid
235 2017-05-17 21:28:48	0|Anduck|it's indeed tough. SF-SW itself can be seen as "bad" because it relies on miners.. it's all very hard
236 2017-05-17 21:28:52	0|luke-jr|BlueMatt: telling miners is very different from economically forcing their hand
237 2017-05-17 21:29:40	0|luke-jr|especially when the miners are already hostile and attacking the network
238 2017-05-17 21:30:13	0|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
239 2017-05-17 21:30:23	0|BlueMatt|this it not true for bip 148, just as it is not true for a hf
240 2017-05-17 21:30:43	0|BlueMatt|luke-jr: great, so go talk to the exchanges and merchants where miners sell their coins and tell them to switch
241 2017-05-17 21:30:51	0|BlueMatt|I'm happy to help intro you to folks if you dont know most of them
242 2017-05-17 21:31:05	0|Anduck|BlueMatt: yeah, that's true
243 2017-05-17 21:31:30	0|luke-jr|BlueMatt: another dev has already tried this, and found they will only if Core releases it..
244 2017-05-17 21:31:59	0|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
245 2017-05-17 21:32:07	0|BlueMatt|so sounds like you got a "no"
246 2017-05-17 21:32:30	0|luke-jr|it's not clearly "yes", but it's certainly far from clearly "no"
247 2017-05-17 21:33:01	0|luke-jr|the community seems very much in favour of it, with a positive trent
248 2017-05-17 21:33:02	0|luke-jr|trend*
249 2017-05-17 21:33:11	0|BlueMatt|if they're, otoh, expecting "Core" to decide consensus rules for the bitcoin ecosystem, then they can also clearly fuck off
250 2017-05-17 21:33:18	0|BlueMatt|that is not the same as consensus?
251 2017-05-17 21:33:24	0|luke-jr|Segwit doesn't have consensus.
252 2017-05-17 21:33:42	0|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
253 2017-05-17 21:33:50	0|BlueMatt|and if you're claiming you can, please pull your head out of your ass
254 2017-05-17 21:34:23	0|luke-jr|I'd say it seems pretty similar to segwit itself.
255 2017-05-17 21:34:36	0|BlueMatt|you think bip 148 has the same level of support as segwit?!
256 2017-05-17 21:34:53	0|BlueMatt|i refer you to my previous comment about bodily orifices
257 2017-05-17 21:34:55	0|luke-jr|maybe slightly less, but it seems to be pretty close
258 2017-05-17 21:35:11	0|BlueMatt|(and the differences between SFs and uasfs)
259 2017-05-17 21:36:23	0|Anduck|well, it's obvious that community wants segwit. now the big question is just how to deploy it
260 2017-05-17 21:36:47	0|Anduck|apparently masf is not working because some small part of community can keep it not happening
261 2017-05-17 21:38:49	0|BlueMatt|well activation method is a key part of any consensus rule change proposal
262 2017-05-17 21:43:52	0|gmaxwell|BIP148 is also something they would want but IF and only IF most everyone
263 2017-05-17 21:43:52	0|gmaxwell|My view: Community and industry overwhelmingly want segwit. Given that
264 2017-05-17 21:43:55	0|gmaxwell|else wants it. (because it's disruptive if partial).  So there is a symmerty
265 2017-05-17 21:43:58	0|gmaxwell|breaking problem.  Either ~everyone or ~no one should want it.
266 2017-05-17 21:44:00	0|gmaxwell|So if a sufficiently high profile group said they would do it, they'd
267 2017-05-17 21:44:03	0|gmaxwell|probably break the symmetry.  But we really don't want it to be us
268 2017-05-17 21:44:05	0|gmaxwell|in particular because it would feed the FUD that core controls this
269 2017-05-17 21:44:08	0|gmaxwell|or that (when really the whole thing would work because the support
270 2017-05-17 21:44:10	0|gmaxwell|for segwit is already overwhelming).  Unfortunately, everyone else
271 2017-05-17 21:44:13	0|gmaxwell|who would be a potential symmetry breaker has a starting disadvantage:
272 2017-05-17 21:44:15	0|gmaxwell|they're not known and trusted for pruducing software and BIP148
273 2017-05-17 21:44:18	0|gmaxwell|needs software.   We could ship BIP148 switchable and defaulted to
274 2017-05-17 21:44:20	0|gmaxwell|off but this raises a concern why not some other change: I would
275 2017-05-17 21:44:23	0|gmaxwell|point out that the ONLY argument against BIP148 given what we know
276 2017-05-17 21:44:25	0|gmaxwell|is that other people might not run it and the people who do run it
277 2017-05-17 21:44:28	0|gmaxwell|may be disrupted.. this doesn't hold for 12345MB blocks or whatever,
278 2017-05-17 21:44:30	0|gmaxwell|as there are solid issues there indpendant of the level of
279 2017-05-17 21:44:33	0|gmaxwell|popular support.
280 2017-05-17 21:44:35	0|gmaxwell|I've heard directly from people trying to push for BIP148 that they
281 2017-05-17 21:44:38	0|gmaxwell|felt undermined by the project's lack of implementation of the
282 2017-05-17 21:44:40	0|gmaxwell|mechenism.
283 2017-05-17 21:45:43	0|BlueMatt|I'm happy to ship code with an #ifdef NEVER_DEFINED_BIP148_IMPL_FLAG, but, otherwise, yes, totally agree with the above
284 2017-05-17 21:47:35	0|sdf_0010|what is the reason for core not including BIP148 or similar as a switch defaulting to off?
285 2017-05-17 21:48:31	0|BlueMatt|sdf_0010: we dont ship software with a -maybeblowmyfaceoff=true option
286 2017-05-17 21:48:36	0|BlueMatt|sorry, we just dont
287 2017-05-17 21:49:40	0|luke-jr|but not enforcing BIP 148 is more "blow my face off" than enforcing it :/
288 2017-05-17 21:50:19	0|luke-jr|(also, I'm pretty sure I can find such a flag.. but not the point :p)
289 2017-05-17 21:50:22	0|sdf_0010|it's hard to even take BlueMatt seriously if he is going to use such ridiculous language
290 2017-05-17 21:51:02	0|Anduck|BlueMatt: bip148 version "flavor" could be handed by core anyway. just with proper warnings everywhere, and good reasoning why core is making it
291 2017-05-17 21:51:09	0|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
292 2017-05-17 21:51:30	0|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?
293 2017-05-17 21:52:50	0|Anduck|...
294 2017-05-17 21:52:53	0|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
295 2017-05-17 21:52:57	0|gmaxwell|sdf_0010: he's right, and I agree in general without agreeing in this case.
296 2017-05-17 21:53:15	0|BlueMatt|just like we merged the segwit code without activation flags on
297 2017-05-17 21:53:29	0|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.
298 2017-05-17 21:53:32	0|BlueMatt|there was no way to turn it on on mainnet (afair), but the code was all there
299 2017-05-17 21:54:31	0|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
300 2017-05-17 21:54:37	0|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.
301 2017-05-17 21:54:58	0|gmaxwell|sdf_0010: better example is you can set dbcache higher than the amount of ram you have, and you'll crash.
302 2017-05-17 21:55:07	0|BlueMatt|sdf_0010: do you believe we should have an option that sends your private keys to me for analysis?
303 2017-05-17 21:55:15	0|gmaxwell|or you can set your fee levels really stupidly high.
304 2017-05-17 21:55:30	0|gmaxwell|but thats about as close to a suicide button as I think we get.
305 2017-05-17 21:55:45	0|sdf_0010|BlueMatt, are you evne trying to engage me with  in a genuine manner?
306 2017-05-17 21:56:00	0|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?
307 2017-05-17 21:56:17	0|gmaxwell|sdf_0010: he is, don't be fragile. :)
308 2017-05-17 21:56:38	0|BlueMatt|sdf_0010: I was eggagerating slightly to highlight the type of issue here
309 2017-05-17 21:56:42	0|gmaxwell|sdf_0010: bluematt wants to do the right thing, it's not a personal dispute. Don't take it that way.
310 2017-05-17 21:56:43	0|sdf_0010|asking rhetoical questions and pretending they are equivalent to my example is highly idiotic behavior or trollish
311 2017-05-17 21:56:58	0|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
312 2017-05-17 21:57:08	0|gmaxwell|achow101: pm me an email address and I'll share the contact sheet I used for segwit outreach.
313 2017-05-17 21:57:09	0|sdf_0010|and i do believe he isn't stupid, but pretending my exmaple and his are equivilent is purely idiotic
314 2017-05-17 21:57:24	0|BlueMatt|sdf_0010: actually, I believe they are highly analygous
315 2017-05-17 21:57:29	0|sdf_0010|haha
316 2017-05-17 21:57:42	0|BlueMatt|sdf_0010: maybe a better comparison is a flag to run bitcoin core on testnet but have everything pretend to be mainnet
317 2017-05-17 21:58:04	0|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
318 2017-05-17 21:58:11	0|BlueMatt|with valueless coins, but you are nonethewiser
319 2017-05-17 21:58:21	0|BlueMatt|gmaxwell: if that is insufficient, then we should revisit the issue at that point, I believe
320 2017-05-17 21:58:25	0|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
321 2017-05-17 21:58:59	0|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
322 2017-05-17 21:58:59	0|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
323 2017-05-17 21:59:51	0|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
324 2017-05-17 21:59:57	0|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.
325 2017-05-17 22:00:44	0|BlueMatt|bitcoin even is
326 2017-05-17 22:00:44	0|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
327 2017-05-17 22:01:21	0|luke-jr|gmaxwell: partial adoption is happening regardless though
328 2017-05-17 22:01:25	0|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.
329 2017-05-17 22:01:53	0|gmaxwell|if it's (say) 5% then it's just bad for the BIP148 users.
330 2017-05-17 22:02:18	0|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.
331 2017-05-17 22:02:35	0|morcos|BIP148 is essentially hot off the press, and we're already trying to merge it
332 2017-05-17 22:02:42	0|gmaxwell|morcos: +1
333 2017-05-17 22:02:45	0|morcos|This is premature by at least 6 months, if not a year
334 2017-05-17 22:02:52	0|gmaxwell|morcos: we'll be 'we' you mean like luke. :P
335 2017-05-17 22:03:28	0|BlueMatt|yea, that too
336 2017-05-17 22:03:31	0|morcos|well, i just think it shouldn't even be a conversation at this point (about merging).  Debating the overal merits makes sense
337 2017-05-17 22:04:01	0|luke-jr|morcos: BIP148 is 2 months old, and IMO better than any hypothetical alternative; anything else will require a redeployment
338 2017-05-17 22:04:03	0|gmaxwell|yea, I think it's useful to talk through it.. thats how you get to maturity 6months henceforth, as you suggested.
339 2017-05-17 22:04:22	0|gmaxwell|luke-jr: as I've said before, you're really overvaluing the redeployment cost.
340 2017-05-17 22:04:32	0|gmaxwell|Yea, sure, it'll cause developer effort but thats what we signed up for.
341 2017-05-17 22:04:42	0|luke-jr|gmaxwell: I don't think I am. Consider how much additional work segwit required that we didn't anticipate.
342 2017-05-17 22:04:45	0|BlueMatt|yea, luckily the parameter space here is rather well-defined and somewhat limited, so its not a particularly extended discussion, I'd hope
343 2017-05-17 22:05:23	0|gmaxwell|luke-jr: segwit finished astonishingly quickly.
344 2017-05-17 22:06:03	0|luke-jr|what? it was several months later than planned
345 2017-05-17 22:06:05	0|Anduck|morcos: good point. i guess the main hurry comes from btc/usd and altcoin valuations
346 2017-05-17 22:08:28	0|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.
347 2017-05-17 22:08:46	0|gmaxwell|luke-jr: no it was several months later than idiotic estimates.
348 2017-05-17 22:09:05	0|gmaxwell|If you reacall I was pointing out those estimates were absurd in january.
349 2017-05-17 22:09:41	0|gmaxwell|Did you not even listen to the example I gave you earlier about 4 byte ASNs in BGP?  It took a _decade_.
350 2017-05-17 22:10:05	0|BlueMatt|*ahem* IPv6 *ahem*
351 2017-05-17 22:10:26	0|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)
352 2017-05-17 22:10:50	0|BlueMatt|did you....segregate the last 2 bytes :p
353 2017-05-17 22:11:27	0|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.
354 2017-05-17 22:13:08	0|luke-jr|AFAICT that analogy is about segwit, not BIP148
355 2017-05-17 22:13:18	0|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. :) )
356 2017-05-17 22:13:24	0|gmaxwell|luke-jr: sure but BIP148 is about segwit.
357 2017-05-17 22:13:32	0|gmaxwell|It's about getting segwit deployed faster.
358 2017-05-17 22:13:34	0|luke-jr|BIP148 is about segwit, but BIP148 itself is very simple
359 2017-05-17 22:13:44	0|gmaxwell|yea, BIP148 is very simple, I agree.
360 2017-05-17 22:14:10	0|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.
361 2017-05-17 22:14:29	0|luke-jr|then why didn't we set the timeout later?
362 2017-05-17 22:14:41	0|gmaxwell|even in protocols with far less demands than ours-- like BGP for example-- upgrades take a long time.
363 2017-05-17 22:15:09	0|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.
364 2017-05-17 22:15:30	0|gmaxwell|No one thought through that for segwit (unlike most SF) it's a bit harder to just renew. Ooops.
365 2017-05-17 22:15:39	0|achow101|gmaxwell: but to keep renewing it requires everyone to upgrade yet again
366 2017-05-17 22:15:40	0|gmaxwell|if not for that I think we'd already have a renewal staged in master.
367 2017-05-17 22:16:16	0|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. :)
368 2017-05-17 22:16:31	0|luke-jr|gmaxwell: I don't see a reason in this, to make BIP148 fail and split the chain.
369 2017-05-17 22:16:37	0|gmaxwell|it's perhaps an argument that the BIP9 timeout default should be more like 2 or three years.
370 2017-05-17 22:17:24	0|gmaxwell|luke-jr: no one has to run BIP148.
371 2017-05-17 22:17:43	0|luke-jr|gmaxwell: a non-trivial amount of the community will be doing so
372 2017-05-17 22:18:48	0|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.
373 2017-05-17 22:19:07	0|BlueMatt|morcos: ugh, i started looking at other node behavior and then got distrcated by bullshit
374 2017-05-17 22:23:16	0|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
375 2017-05-17 22:23:57	0|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
376 2017-05-17 22:24:47	0|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
377 2017-05-17 22:26:16	0|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
378 2017-05-17 22:28:20	0|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
379 2017-05-17 22:30:44	0|Anduck|bgp is not comparable to bitcoin because there's no competitor. nobody gains anything if they get bgp replaced by something else
380 2017-05-17 22:33:24	0|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
381 2017-05-17 22:43:03	0|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?
382 2017-05-17 22:43:03	0|lichtamberg_|I cannot understand why there is such a strong stand against a toggle option...
383 2017-05-17 22:43:03	0|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..
384 2017-05-17 22:43:35	0|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
385 2017-05-17 22:44:22	0|Anduck|in a sense, it's irresponsible to give user an option to fail horribly.
386 2017-05-17 22:45:07	0|lichtamberg_|it's also irresponsible to remove the option if the community support is getting enough traction
387 2017-05-17 22:45:57	0|lichtamberg_|you are only thinking about the failing part… but look on reddit
388 2017-05-17 22:46:06	0|lichtamberg_|a not so small part of the community will go this way
389 2017-05-17 22:47:21	0|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?
390 2017-05-17 22:47:23	0|lichtamberg_|and as far as I know, this is the biggest community movement which we ever saw until now?
391 2017-05-17 22:48:32	0|Anduck|like, should core offer the best and safest product available and have no comment in ANY kind of protocol updates?
392 2017-05-17 22:49:16	0|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
393 2017-05-17 22:51:01	0|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)
394 2017-05-17 22:55:57	0|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.
395 2017-05-17 22:57:31	0|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
396 2017-05-17 22:58:27	0|luke-jr|Anduck: in this case, it's not "no comment", it's actively anti-BIP148.
397 2017-05-17 22:59:22	0|Anduck|or pro-no-disruption-to-the-system ?
398 2017-05-17 22:59:44	0|Anduck|segwit masf was defined as only activated if miners choose so. it's disruption to change this now
399 2017-05-17 23:00:25	0|luke-jr|Anduck: nope, Core's current anti-BIP148 position increases the disruption
400 2017-05-17 23:00:33	0|Anduck|no matter how sane it would be if it wasn't so disruptive
401 2017-05-17 23:00:51	0|Anduck|luke-jr: well, that's an opinion only. there are tons of factors to consider --most of them are unknown.
402 2017-05-17 23:01:38	0|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"
403 2017-05-17 23:02:16	0|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
404 2017-05-17 23:05:16	0|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… :)
405 2017-05-17 23:05:36	0|Anduck|"If all core members would support BIP148, we could do it really easily" << i disagree.
406 2017-05-17 23:06:12	0|lichtamberg_|i disagree with your disagreement :D
407 2017-05-17 23:06:29	0|lichtamberg_|we have so much support for segwit
408 2017-05-17 23:06:36	0|lichtamberg_|there is such a big hype about UASF
409 2017-05-17 23:06:56	0|lichtamberg_|the only ones which are missing are: the miners (obviously) - and core
410 2017-05-17 23:07:02	0|Anduck|could be that you're right. could be that you're not. i think hype for bip148 is largely hype only.
411 2017-05-17 23:07:25	0|Anduck|reddit is only one small piece of the community.
412 2017-05-17 23:07:26	0|lichtamberg_|hard to measure that, but I dont think so
413 2017-05-17 23:07:31	0|Anduck|i don't see big companies supporting uasf either
414 2017-05-17 23:08:11	0|lichtamberg_|they are just scared to be the first one… first mover effect..
415 2017-05-17 23:08:23	0|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)
416 2017-05-17 23:09:11	0|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
417 2017-05-17 23:09:20	0|Anduck|we've already seen signals about this phenomenon
418 2017-05-17 23:09:42	0|Anduck|not only in bitcoin scene, that is
419 2017-05-17 23:11:00	0|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