1 2017-07-22 02:11:58	0|luke-jr|gmaxwell: BIP148's patch is only larger for safety and unit tests. it's much smaller than BIP91 without those.
 2 2017-07-22 02:13:26	0|gmaxwell|luke-jr: well it does things like preferential peering, for example.
 3 2017-07-22 02:13:26	0|luke-jr|given the short time period and risk of splitting up enforcement too much, I currently favour just deployment of BIP148 as-is. not perfect, but I think it's the least-risky all things considered
 4 2017-07-22 02:13:55	0|luke-jr|right, that's what I mean (partly)
 5 2017-07-22 02:14:03	0|luke-jr|fortunately, not ALL users need that, only some
 6 2017-07-22 02:14:35	0|luke-jr|the banning-old-nodes part is probably a bigger deal, but the same applies there
 7 2017-07-22 02:15:24	0|gmaxwell|as-is has the now-we-have-three-forks problem
 8 2017-07-22 02:15:33	0|luke-jr|essentially it's uasfsegwit 0.3 vs 1.0
 9 2017-07-22 02:16:16	0|luke-jr|gmaxwell: less likely than if 30% run BIP148-adapted-to-BIP91, 30% run BIP148-as-is, and 40% run non-BIP148
10 2017-07-22 02:16:18	0|luke-jr|no?
11 2017-07-22 02:16:52	0|luke-jr|at least if it's simply BIP148 or non-BIP148, *users* will be on one or the other
12 2017-07-22 02:17:37	0|gmaxwell|luke-jr: no, because presumably there are foolish people running btc1.
13 2017-07-22 02:17:58	0|luke-jr|not that many?
14 2017-07-22 02:18:36	0|gmaxwell|no, but we can't tell for sure.
15 2017-07-22 02:20:35	0|luke-jr|seems the binary choice (plus btc1) is only *at worst* equivalent to the trinary choice, and at best, an improvement
16 2017-07-22 02:20:59	0|luke-jr|too many people disagree with the adjusted-BIP148 it seems, to reduce to a binary choice there
17 2017-07-22 02:26:25	0|luke-jr|am I missing something still?
18 2017-07-22 02:51:54	0|praxeology|gmaxwell: what do you want to do? just stick w/ the current release?
19 2017-07-22 03:14:53	0|btcdrak|If pools have direct connected to eachother and are also on FIBRE, isnt that enough to mitigate the problems without trying to deploy something in <24 hours?
20 2017-07-22 03:16:42	0|praxeology|btcdrak: the worst case scenario is  that someone will make a non-segwit signalling block (very likely) and then half of the miners will accept it (not actually enforcing BIP 91) and the other half will reject it
21 2017-07-22 03:18:15	0|praxeology|which would then potentially result in the longest valid chain (as appearing to current bitcoin core clients) to swap back and forth between the chain w/ the non-segwit-signal chain and the all segwit-signal chain
22 2017-07-22 03:18:49	0|btcdrak|I've asked several pools and based on what they say at least, much more than 51% of the hashrate is running BIP91 enforcement code either btc1 or segsignal. They understand they must enforce the rule.
23 2017-07-22 03:20:53	0|btcdrak|I agree this situation is ideal. If BIP91 had the same activation date as BIP148 it could have piggypacked and there would be significant node enforcement. But in 24 hours, I dont see how we can make this better at all. Asking exchanges et al to run a quick untested patch (by Core's standards) for what doesnt seem like an emergency (at least to me), seems irresponsible.
24 2017-07-22 03:21:14	0|btcdrak|s/is idea/isn't ideal/
25 2017-07-22 03:23:34	0|praxeology|btcdrak: I agree that bitcoincore.org / etc people should definitely not ask people to run BIP 91 enforcing software, or even recommend it.  They might just want to create a BIP 91 or 148 release just to satisfy demand
26 2017-07-22 03:24:14	0|luke-jr|btcdrak: without enforcement, you lose full node security
27 2017-07-22 03:25:01	0|praxeology|But for exchanges, established businesses etc, i think they should just stick to 0.14.2 for now... and then if there actually is a lasting split, then wait for replay attack prevention to be tested and released
28 2017-07-22 03:25:55	0|praxeology|luke-jr: what do you mean you lose full node security?
29 2017-07-22 03:26:12	0|praxeology|you are still fully verifying the money supply
30 2017-07-22 03:26:21	0|luke-jr|praxeology: full node security means you enforce ALL the rules
31 2017-07-22 03:26:34	0|praxeology|all of your own rules
32 2017-07-22 03:26:39	0|luke-jr|anything less than all, is effectively nothing
33 2017-07-22 03:26:49	0|sipa|luke-jr: i disagree with that
34 2017-07-22 03:27:14	0|praxeology|BIP91 rules are not/never were my rules.  I only heard about it yesterday when I was checking up on BIP 148 status
35 2017-07-22 03:27:32	0|sipa|(especially if you're not doing anything based on low confirmation count)
36 2017-07-22 03:27:42	0|luke-jr|praxeology: yet if you don't enforce it, you lose security
37 2017-07-22 03:28:51	0|praxeology|luke-jr: only for low confirmation count, only over about the next 2 weeks, and only if there is a near 50% split on bip 91 enforcement
38 2017-07-22 03:28:52	0|luke-jr|sipa: if you're trusting miners, that's pSPV, not full node. or do you mean something else?
39 2017-07-22 03:29:17	0|sipa|luke-jr: yes, you're trusting them for some rules
40 2017-07-22 03:30:04	0|luke-jr|how is some any different from all, practically speaking?
41 2017-07-22 03:30:39	0|praxeology|One only need enforce rules that oneself cares about
42 2017-07-22 03:30:48	0|praxeology|if others enforce more rules, it does not matter to you
43 2017-07-22 03:31:16	0|luke-jr|praxeology: it does, because if the unenforced rule is violated, the entire block is invalid, even if you were personally okay with it
44 2017-07-22 03:31:57	0|praxeology|its only a short term problem w/ orphaning blocks
45 2017-07-22 03:32:16	0|sipa|luke-jr: maybe you're ok with spv security for incoming payments, but still want to help make sure miners cannot inflate the currency supply
46 2017-07-22 03:32:45	0|luke-jr|hm
47 2017-07-22 03:40:08	0|morcos|My general view is that the more we think the miners are going to properly enforce BIP91, the more we want to make a patch/release that does so
48 2017-07-22 03:40:22	0|morcos|B/c that means the more sure we are that it is the actual rules
49 2017-07-22 03:40:49	0|morcos|If we think there might be all kinds of shenanigans, maybe we just want to stay clear of these rushed consenus chicken games
50 2017-07-22 05:31:44	0|bitcoin-git|[13bitcoin] 15jamesob opened pull request #10903: Add configuration files for a Docker-based development environment (06master...06docker) 02https://github.com/bitcoin/bitcoin/pull/10903
51 2017-07-22 05:37:05	0|gmaxwell|btcdrak: as morcos says, -- we think non SW signaling blocks will be orphaned... not everyone can stop transacting for most of the weekend...  to avoid losses they need to either wait an unreasonable amount of confirmations or enforce the rules that (in their best estimation) the network will enforce.
52 2017-07-22 08:44:39	0|bitcoin-git|13bitcoin/06master 1444eb9d4 15Jonas Schnelli: [QA] Avoid running multiwallet.py twice
53 2017-07-22 08:44:39	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/420238d3103a...0c173a15ca1b
54 2017-07-22 08:44:40	0|bitcoin-git|13bitcoin/06master 140c173a1 15MarcoFalke: Merge #10893: [QA] Avoid running multiwallet.py twice...
55 2017-07-22 08:45:09	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10893: [QA] Avoid running multiwallet.py twice (06master...062017/07/fix_mw_test) 02https://github.com/bitcoin/bitcoin/pull/10893
56 2017-07-22 10:52:16	0|bitcoin-git|[13bitcoin] 15corebob opened pull request #10907: Prefer iterators arrow operator over iterator dereference (06master...0620170722-refactor-arrow-1) 02https://github.com/bitcoin/bitcoin/pull/10907
57 2017-07-22 11:35:25	0|bitcoin-git|[13bitcoin] 15Astrali opened pull request #10908: pls review (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10908
58 2017-07-22 11:44:26	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10908: pls review (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10908
59 2017-07-22 15:23:44	0|NicolasDorier|It seems importaddress does not track properly bare segwit scriptPubKey.
60 2017-07-22 15:24:16	0|NicolasDorier|Is it expected? If not will try to find the root cause
61 2017-07-22 15:39:29	0|amosbird|hello
62 2017-07-22 15:39:37	0|amosbird|can anyone help me with this compilation error ? https://la.wentropy.com/oEcj
63 2017-07-22 15:39:41	0|amosbird|it's in centos 7
64 2017-07-22 16:13:17	0|sipa|NicolasDorier: by bare segwit, you mean not embedded in p2sh?
65 2017-07-22 16:15:59	0|sipa|NicolasDorier: you may need to use importpubkey
66 2017-07-22 16:16:43	0|sipa|NicolasDorier: there is extra protection for segwit outputs to not accidentally treat uncompressed pubkeys as ismine
67 2017-07-22 16:27:58	0|goatpig|you're lacking the some boost code files
68 2017-07-22 16:28:06	0|goatpig|you have the headers therefor you can compile
69 2017-07-22 16:28:13	0|goatpig|but the .cpp is missing, so it can't link
70 2017-07-22 16:28:40	0|goatpig|basically boost::thread related libs
71 2017-07-22 16:29:13	0|goatpig|either that or you don't have the libraries installed at all
72 2017-07-22 16:29:15	0|goatpig|and can't link to them
73 2017-07-22 16:29:26	0|goatpig|did you run the configure script?
74 2017-07-22 16:29:36	0|goatpig|it should have warned you of missing boost packages
75 2017-07-22 16:54:06	0|bitcoin-git|[13bitcoin] 15keystrike opened pull request #10911: Typo in optionsdialog.ui (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10911
76 2017-07-22 22:04:05	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10912: [tests] Remove incorrect memory_cleanse(…) call in crypto_tests.cpp (06master...06arrays-are-not-pointers) 02https://github.com/bitcoin/bitcoin/pull/10912