1 2017-10-26 00:51:14 0|bitcoin-git|[13bitcoin] 15promag opened pull request #11563: Improve CheckBlockIndex performance (06master...062017-10-improve-checkblockindex) 02https://github.com/bitcoin/bitcoin/pull/11563
2 2017-10-26 01:25:26 0|Antranik|how about them dev forks ey
3 2017-10-26 02:18:38 0|jb55|#bitcoin-forks
4 2017-10-26 04:00:08 0|gmaxwell|sdaftuar: do we learn about a peer's tip from GETHEADERS messages they send us... e.g. if they send us a getheaders whos locator starts with our current tip will we update them to that
5 2017-10-26 06:37:18 0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #7601: [WIP] HTLC implementation in the wallet (06master...06zkcp) 02https://github.com/bitcoin/bitcoin/pull/7601
6 2017-10-26 09:29:01 0|sdaftuar|gmaxwell: my understanding of the scheduler is that it'll start scheduling callbacks at some point after startup, so i wouldn't expect the network to be completely synced
7 2017-10-26 09:29:19 0|sdaftuar|gmaxwell: also there's random drift, since the scheduler schedules the next callback N milliseconds after the prior one finishes
8 2017-10-26 09:29:40 0|sdaftuar|but worth discussing whether the interval is short enough that there still might be too much concentration of everyone trying to find a new peer
9 2017-10-26 09:30:12 0|sdaftuar|gmaxwell: regarding getheaders/locator -- no we don't update pindexBestKnownBlock from a peer's locator
10 2017-10-26 09:30:26 0|sdaftuar|we use pindexBestKnownBlock to figure out what blocks we can download from our peer
11 2017-10-26 09:30:58 0|sdaftuar|and the peer will update its locator based on headers it knows (not blocks!) during initial headers sync
12 2017-10-26 09:31:34 0|sdaftuar|in order to sync the whole headers chain (and given the MAX_HEADERS_RESULTS constraint on headers messages)
13 2017-10-26 10:20:57 0|bitcoin-git|[13bitcoin] 15Sjors closed pull request #11557: WIP: Use Sat/WU instead of (ü/m)BTC/kB (06master...06fee-sat-per-wu) 02https://github.com/bitcoin/bitcoin/pull/11557
14 2017-10-26 11:13:13 0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #11565: Make listsinceblock refuse unknown block hash (06master...06pr/since) 02https://github.com/bitcoin/bitcoin/pull/11565
15 2017-10-26 15:27:48 0|bitcoin-git|[13bitcoin] 15pkaksha opened pull request #11566: 0.9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/11566
16 2017-10-26 15:28:11 0|bitcoin-git|13bitcoin/06master 14fa81534 15MarcoFalke: Add share/rpcuser to dist. source code archive
17 2017-10-26 15:28:11 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/57ee73990f1c...cf8c4a7633b1
18 2017-10-26 15:28:12 0|bitcoin-git|13bitcoin/06master 14cf8c4a7 15Wladimir J. van der Laan: Merge #11530: Add share/rpcuser to dist. source code archive...
19 2017-10-26 15:28:54 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11530: Add share/rpcuser to dist. source code archive (06master...06Mf1710-distShare) 02https://github.com/bitcoin/bitcoin/pull/11530
20 2017-10-26 15:29:01 0|bitcoin-git|13bitcoin/060.15 14265bb21 15MarcoFalke: Add share/rpcuser to dist. source code archive...
21 2017-10-26 15:29:01 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.15: 02https://github.com/bitcoin/bitcoin/commit/265bb214ecf616a7a55fc979a227d5f215046d84
22 2017-10-26 15:47:08 0|bitcoin-git|[13bitcoin] 15sipa closed pull request #11566: 0.9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/11566
23 2017-10-26 16:56:51 0|bitcoin-git|[13bitcoin] 15sdaftuar closed pull request #11534: Evict outbound peers if tip is stale (06master...062017-10-stale-tip-eviction) 02https://github.com/bitcoin/bitcoin/pull/11534
24 2017-10-26 19:00:13 0|achow101|meeting?
25 2017-10-26 19:00:16 0|sdaftuar|meeting
26 2017-10-26 19:00:34 0|promag|+1
27 2017-10-26 19:00:53 0|wumpus|#startmeeting
28 2017-10-26 19:00:54 0|lightningbot|Meeting started Thu Oct 26 19:00:53 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
29 2017-10-26 19:00:54 0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
30 2017-10-26 19:01:11 0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
31 2017-10-26 19:01:18 0|achow101|hi
32 2017-10-26 19:01:20 0|meshcollider|Hi
33 2017-10-26 19:01:50 0|kanzure|hi.
34 2017-10-26 19:02:05 0|wumpus|#topic 0.15.0.2
35 2017-10-26 19:02:19 0|cfields|hi
36 2017-10-26 19:02:39 0|wumpus|anything ready for merge there?
37 2017-10-26 19:02:43 0|maaku|present
38 2017-10-26 19:02:49 0|sdaftuar|i think #11490 is ready? maybe needs another ACK?
39 2017-10-26 19:02:52 0|gribble|https://github.com/bitcoin/bitcoin/issues/11490 | Disconnect from outbound peers with bad headers chains by sdaftuar ÷ Pull Request #11490 ÷ bitcoin/bitcoin ÷ GitHub
40 2017-10-26 19:03:22 0|jtimon|hi
41 2017-10-26 19:03:39 0|wumpus|ok, good to know
42 2017-10-26 19:03:51 0|wumpus|#action merge 11490
43 2017-10-26 19:03:52 0|gmaxwell|Hi.
44 2017-10-26 19:04:20 0|cfields|11490 looked good last i looked, will take a quick look at the last changes and re-ack
45 2017-10-26 19:04:27 0|gmaxwell|sdaftuar: I already ACKed it. I think it's pretty great.
46 2017-10-26 19:04:30 0|sdaftuar|thanks!
47 2017-10-26 19:04:33 0|achow101|gmaxwell: found a peer that his node with 11490 kicked. we're not sure whether it was kicked for being brain dead or spynode
48 2017-10-26 19:04:40 0|achow101|or ibd
49 2017-10-26 19:04:49 0|gmaxwell|but is should have been kicked regardless.
50 2017-10-26 19:05:02 0|wumpus|yes was about to say that
51 2017-10-26 19:05:19 0|wumpus|seems an improvement in any case to kick it :)
52 2017-10-26 19:05:22 0|jtimon|I was going to say if there was anything stopping 8994, but it needs rebase...
53 2017-10-26 19:05:25 0|achow101|ok, I just wasn't sure that it would effect nodes in inbd
54 2017-10-26 19:05:35 0|gmaxwell|Yes, I've had a node running the patch for a few days and after the first day I started cycling out all my outbounds every few hours with the hopes of hitting some broken peers.
55 2017-10-26 19:05:50 0|gmaxwell|achow101: yes, it should-- they're useless to us as outbound targets.
56 2017-10-26 19:06:10 0|achow101|oh right, duh. outbound..
57 2017-10-26 19:06:18 0|gmaxwell|.yes, this is outbound only
58 2017-10-26 19:06:45 0|gmaxwell|and it avoids acting on 4 peers. so even if it goes nuts and kicks things it shouldn't the damage is limited.
59 2017-10-26 19:08:02 0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #11568: Disconnect outbound peers on invalid chains (06master...062017-10-disconnect-outbound-peers-on-invalid-chains) 02https://github.com/bitcoin/bitcoin/pull/11568
60 2017-10-26 19:08:14 0|sdaftuar|also i think i have a fix to #11446 that should satisfy concerns raised in that PR ^^^
61 2017-10-26 19:08:17 0|gribble|https://github.com/bitcoin/bitcoin/issues/11446 | Disconnect Peers for Duplicate Invalid blocks. by achow101 ÷ Pull Request #11446 ÷ bitcoin/bitcoin ÷ GitHub
62 2017-10-26 19:08:25 0|achow101|sdaftuar: yay
63 2017-10-26 19:08:31 0|cfields|tangentially, does it not make sense to take their blockheight in version into consideration? sure it can be spoofed higher, but if it's low and we're in IBD (and presumably they are too), is it worth it to hang around?
64 2017-10-26 19:08:35 0|gmaxwell|to reiterite why this specific patch is important; beyond general braindead peer elimination, it addresses the case where you have peers on incompatible consensus rules which you aren't discovering because their chain has less work, so you aren't fetching their invalid blocks.
65 2017-10-26 19:08:49 0|sdaftuar|it's a refactor unfortunately, so not sure it is a good candidate for backport to 0.15. but it was simple to do
66 2017-10-26 19:09:02 0|gmaxwell|cfields: well someone could have a lower height but more work chain
67 2017-10-26 19:09:29 0|wumpus|yes, so for 0.15.0.2 we have open at the moment, apart from the one just discussed: #11560 #11446 #10593
68 2017-10-26 19:09:31 0|gribble|https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar ÷ Pull Request #11560 ÷ bitcoin/bitcoin ÷ GitHub
69 2017-10-26 19:09:33 0|gribble|https://github.com/bitcoin/bitcoin/issues/11446 | Disconnect Peers for Duplicate Invalid blocks. by achow101 ÷ Pull Request #11446 ÷ bitcoin/bitcoin ÷ GitHub
70 2017-10-26 19:09:35 0|gribble|https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr ÷ Pull Request #10593 ÷ bitcoin/bitcoin ÷ GitHub
71 2017-10-26 19:09:58 0|sdaftuar|#11560 as well
72 2017-10-26 19:10:00 0|gribble|https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar ÷ Pull Request #11560 ÷ bitcoin/bitcoin ÷ GitHub
73 2017-10-26 19:10:04 0|sdaftuar|oh nvm you had that
74 2017-10-26 19:10:08 0|wumpus|#11446 has some doubts from BlueMatt
75 2017-10-26 19:10:10 0|gribble|https://github.com/bitcoin/bitcoin/issues/11446 | Disconnect Peers for Duplicate Invalid blocks. by achow101 ÷ Pull Request #11446 ÷ bitcoin/bitcoin ÷ GitHub
76 2017-10-26 19:10:48 0|meshcollider|Is #11531 also aimed for 0.15.0.2?
77 2017-10-26 19:10:49 0|gribble|https://github.com/bitcoin/bitcoin/issues/11531 | Check that new headers are not a descendant of an invalid block (more effeciently) by TheBlueMatt ÷ Pull Request #11531 ÷ bitcoin/bitcoin ÷ GitHub
78 2017-10-26 19:10:59 0|jnewbery|#10593 seems to be reverting unrelated code with no rationale, so I think that can be untagged
79 2017-10-26 19:11:01 0|gribble|https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr ÷ Pull Request #10593 ÷ bitcoin/bitcoin ÷ GitHub
80 2017-10-26 19:11:18 0|achow101|I guess 11446 has some edge cases that could be problematic
81 2017-10-26 19:11:28 0|gmaxwell|for some reason I thought what we were doing in 11446 was outbound only. I agree that our agressiveness increases here should be outbound only.
82 2017-10-26 19:11:46 0|luke-jr|jnewbery: reverting what? it removes tests that check for the behaviour that is being removed
83 2017-10-26 19:11:47 0|wumpus|ok added 11531
84 2017-10-26 19:11:48 0|gmaxwell|it's important that we don't fully partition old nodes during a softfork.
85 2017-10-26 19:12:01 0|achow101|it would be better if we could get more granular errors from processnewblockheaders
86 2017-10-26 19:12:03 0|wumpus|how much time do we have left?
87 2017-10-26 19:12:08 0|sdaftuar|11568 is the same as 11446, except it avoids disconnecting hb compact block peers, and only applies to outbound peers
88 2017-10-26 19:12:23 0|wumpus|sdaftuar: ok we should remove one, then :)
89 2017-10-26 19:12:44 0|sdaftuar|agreed :)
90 2017-10-26 19:12:57 0|wumpus|eh wait 11568 isn't tagged 0.15.0.2 at all
91 2017-10-26 19:13:01 0|cfields|heh, it's getting hard to keep up with these
92 2017-10-26 19:13:04 0|achow101|wumpus: it was just made
93 2017-10-26 19:13:18 0|sdaftuar|i was trying to open it before the meeting started, doh
94 2017-10-26 19:13:28 0|wumpus|cfields: very hard, yes
95 2017-10-26 19:13:30 0|achow101|if 11568 is 11446 but only for outbound peers, I'm fine with that
96 2017-10-26 19:13:43 0|jnewbery|luke-jr: I haven't fully dug into it, but it regresses #8305, no?
97 2017-10-26 19:13:45 0|gribble|https://github.com/bitcoin/bitcoin/issues/8305 | Improve handling of unconnecting headers by sdaftuar ÷ Pull Request #8305 ÷ bitcoin/bitcoin ÷ GitHub
98 2017-10-26 19:13:57 0|wumpus|ok, replacing 11446 then
99 2017-10-26 19:14:00 0|BlueMatt|I mean if we want a 0.15.0.2 we literally need to rc tomorrow or this weekend, imo
100 2017-10-26 19:14:49 0|gmaxwell|11568 looks good on first run through.
101 2017-10-26 19:15:05 0|cfields|disclosure there: I'll be away after tomorrow night until tuesday morning
102 2017-10-26 19:15:25 0|wumpus|BlueMatt: what can we realistically merge before that time?
103 2017-10-26 19:15:41 0|luke-jr|jnewbery: I don't think so - 8305 disconnects under certain conditions, but 10593 disconnects a superset of those conditions
104 2017-10-26 19:15:43 0|cfields|i can make plans to be available for building if really necessary
105 2017-10-26 19:15:56 0|BlueMatt|wumpus: I dont think a sufficient set to make 0.15.0.2 worth it
106 2017-10-26 19:16:09 0|gmaxwell|I think probably if you try you can merge one PR per minute... we could empty out github by then, no problem.. just lots of button pushing!
107 2017-10-26 19:16:22 0|meshcollider|lol
108 2017-10-26 19:16:23 0|wumpus|well we have some fixes on the 0.15 branch already that are nice
109 2017-10-26 19:16:25 0|BlueMatt|heh
110 2017-10-26 19:16:35 0|wumpus|but I agree it kind of misses the point
111 2017-10-26 19:16:40 0|BlueMatt|wumpus: anything worth an 0.15.0.2?
112 2017-10-26 19:17:06 0|wumpus|BlueMatt: well it's a minor-minor release, that's not a high bar, but yes
113 2017-10-26 19:17:20 0|BlueMatt|I mean things like #11531, which may be important as far as our b2x-shitshow fixes go, are smack-dab in the middle of consensus code and have not review yet?
114 2017-10-26 19:17:22 0|gribble|https://github.com/bitcoin/bitcoin/issues/11531 | Check that new headers are not a descendant of an invalid block (more effeciently) by TheBlueMatt ÷ Pull Request #11531 ÷ bitcoin/bitcoin ÷ GitHub
115 2017-10-26 19:17:25 0|wumpus|BlueMatt: nothing that warrants hurring it though
116 2017-10-26 19:17:45 0|BlueMatt|I suppose it may be worth it to get an 0.15.0.2 out like day-before b2x-shitshow
117 2017-10-26 19:17:59 0|gmaxwell|even a small portion of the network running it is protective.
118 2017-10-26 19:18:01 0|BlueMatt|then at least if some asshat spins up a billion stupid sybil nodes there is a response
119 2017-10-26 19:18:13 0|morcos|BlueMatt: +1
120 2017-10-26 19:18:21 0|BlueMatt|but we need to be clear what our target is here
121 2017-10-26 19:18:23 0|BlueMatt|and really focus on it
122 2017-10-26 19:18:23 0|gmaxwell|at least if we cover the major possible cases: Fork has low to no hashpower, fork has higher hashpower for the case where we're completely partitioned by surrounded by forknodes or where we're partially surrounded.
123 2017-10-26 19:18:30 0|BlueMatt|there hasnt been much progress the last 3 weeks
124 2017-10-26 19:18:45 0|BlueMatt|(I'm to blame there, too, I've been mostly mia)
125 2017-10-26 19:18:47 0|gmaxwell|I think there has been a lot of progress.
126 2017-10-26 19:19:00 0|gmaxwell|sdaftuar has been right on top of making changes.
127 2017-10-26 19:19:08 0|BlueMatt|sorry, lots of progress on making new prs, rewriting prs, talking about issues, lack of *merge* progress
128 2017-10-26 19:19:14 0|wumpus|yes there absolutely has been a lot of progress, PR after PR
129 2017-10-26 19:19:15 0|BlueMatt|or finalizing review for things to get merged
130 2017-10-26 19:19:25 0|wumpus|but very little merging, yeah
131 2017-10-26 19:19:39 0|morcos|have we finalized the list
132 2017-10-26 19:19:43 0|morcos|lets focus on that
133 2017-10-26 19:19:56 0|morcos|and then everyone commit to reviewing 2 of them over the next 24 hours
134 2017-10-26 19:19:59 0|BlueMatt|well one thing on it was opened today cause it was decided to also be important/replace other things
135 2017-10-26 19:19:59 0|morcos|and we'll see where we stand
136 2017-10-26 19:20:06 0|wumpus|no, it seems to change every week
137 2017-10-26 19:20:11 0|morcos|wumpus: exactly
138 2017-10-26 19:20:19 0|BlueMatt|but, yea, I think if we want to see hhis happen, we can get it out day-or-two-before-ish, but we need review *today*
139 2017-10-26 19:20:26 0|cfields|agree with gmaxwell about focusing on those things that may actually be of significance in the next month
140 2017-10-26 19:20:27 0|wumpus|as cfieds said it's hard to keep track of
141 2017-10-26 19:20:35 0|BlueMatt|I think they're all tagged now, no?
142 2017-10-26 19:20:41 0|gmaxwell|To get the full coverage of those sets of cases, we need 11490, 11560, and 11568-or-11446
143 2017-10-26 19:20:45 0|morcos|focus... BlueMatt, sipa, gmaxwell, sdaftuar you guys have been thinking abou tthis the most... look at the list right now and be confident it is right and if not fix it
144 2017-10-26 19:20:49 0|BlueMatt|except #10593, ignore that
145 2017-10-26 19:20:51 0|gribble|https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr ÷ Pull Request #10593 ÷ bitcoin/bitcoin ÷ GitHub
146 2017-10-26 19:20:53 0|achow101|I think we can remove 10593
147 2017-10-26 19:21:00 0|morcos|stop arguing with Belshe on the web
148 2017-10-26 19:21:07 0|sdaftuar|:)
149 2017-10-26 19:21:25 0|BlueMatt|yea, 10593 got nack'ed (correctly, imo) a while ago
150 2017-10-26 19:21:25 0|wumpus|ok removed 10593
151 2017-10-26 19:21:30 0|gmaxwell|11490 covers the case where fork has lower hashpower and doesn't completely surround you, 11560 covers where it has higher hashpower, 11568-or-11446 covers where it has lower and may completely surround you.
152 2017-10-26 19:21:37 0|luke-jr|does something else cover the cases 10593 does?
153 2017-10-26 19:21:58 0|rafalcpp|sorry if stupid question, but re `semOutbound = new CSemaphore(std::min((nMaxOutbound + nMaxFeeler + nMaxExtraOutbound), nMaxConnections));` if we're at nMaxOutbound == nMaxConnections doesn't it mean node in such conditin will not try to resolve being stalled? dunno if that's any issue
154 2017-10-26 19:22:03 0|morcos|luke-jr: explicit case you're worried about not being covered (soft forks? , we can worry abou tthose later)
155 2017-10-26 19:22:04 0|BlueMatt|luke-jr: tbh, I dont actually have any fucking clue what that pr is *supposed* to do in the context on b2x-shitshow
156 2017-10-26 19:22:10 0|achow101|rafalcpp: not now
157 2017-10-26 19:22:30 0|sdaftuar|rafalcpp: let's discuss after (thanks for taking a look!)
158 2017-10-26 19:22:37 0|BlueMatt|rafalcpp: sorry, mid-meeting atm
159 2017-10-26 19:22:45 0|morcos|rafalcpp: hi
160 2017-10-26 19:23:01 0|gmaxwell|achow101: that was related to the PR that adds an extra connection
161 2017-10-26 19:23:11 0|luke-jr|morcos: Bitcoin is almost a softfork relative to 2X
162 2017-10-26 19:23:29 0|luke-jr|BlueMatt: it is necessary for people to switch from 2X to Bitcoin, or run them both
163 2017-10-26 19:23:47 0|IniGit|hello
164 2017-10-26 19:23:49 0|BlueMatt|luke-jr: you cannot switch back and forth, your blockindex will be corrupt (yay shitty fork developers)
165 2017-10-26 19:24:00 0|IniGit|I read the whitepaper of ethereum and I have a question (it is the same for bitcoin):
166 2017-10-26 19:24:01 0|IniGit|APPLY(S,TX) -> S'
167 2017-10-26 19:24:01 0|IniGit|My question is since S is defined as a set of UTXO, but the blockchain does not store each balance in a block, is this set of UTXO only preset in RAM and not on the blockchain. Is it calculated by the node by going thhrough each block since the genesis block and only present in RAM?
168 2017-10-26 19:24:01 0|luke-jr|BlueMatt: different datadirs..
169 2017-10-26 19:24:13 0|luke-jr|or even different machines
170 2017-10-26 19:24:15 0|wumpus|IniGit: not here, not now
171 2017-10-26 19:24:18 0|morcos|luke-jr has a bit of a point there
172 2017-10-26 19:24:31 0|gmaxwell|luke-jr: it's unclear of specifically what you're turned about, don't get into an argument in the weeds, state what the overall concern is.
173 2017-10-26 19:24:44 0|IniGit|where can I ask this question and get more knowledge?
174 2017-10-26 19:24:53 0|gmaxwell|IniGit: #bitcoin
175 2017-10-26 19:24:54 0|sdaftuar|are we talking about relaxing bans to be disconnects instead? i generally agree with that
176 2017-10-26 19:24:56 0|BlueMatt|luke-jr: tbh, so what? our banning is deliberately slow, if you get banned from some small percentage of the network, slowly, over time, for running 2x, sucks for you
177 2017-10-26 19:24:57 0|morcos|gmaxwell: if someone on your IP runs a 2X node, your IP gets banned, and you cna't then run or simulataneiously run a core node
178 2017-10-26 19:25:03 0|luke-jr|gmaxwell: right now, we can peers that send invalid blocks, which means their Bitcoin nodes will get rejected from the p2p network too
179 2017-10-26 19:25:06 0|BlueMatt|(like one peer per block kinda slow)
180 2017-10-26 19:25:07 0|achow101|gmaxwell: I think the concern is if someone runs 2x and gets themselves banned, if they switch back to bitcoin they can't connect to the network anymore
181 2017-10-26 19:25:23 0|luke-jr|ban*
182 2017-10-26 19:25:31 0|gmaxwell|morcos: nothign we can do about that now regardless; as it's a property of the widely deployed network.
183 2017-10-26 19:25:45 0|wumpus|achow101: only if *everyone* banned them, which is unlikely as hell!
184 2017-10-26 19:25:58 0|wumpus|achow101: if a few nodes they were connected to banned them they will certainly find others
185 2017-10-26 19:26:05 0|luke-jr|wumpus: when 2X gets banned from Peer A, it will move on to Peer B, etc
186 2017-10-26 19:26:10 0|morcos|gmaxwell: hmm.. ok fair, and it'll take a lot of blocks to get banned by most of the network...
187 2017-10-26 19:26:30 0|gmaxwell|luke-jr: yes, but this takes longer than a day to cycle through all reachable nodes that way.
188 2017-10-26 19:26:31 0|luke-jr|gmaxwell: so long as not all peers ban, they will eventually find ones with the newer code..
189 2017-10-26 19:26:32 0|morcos|luke-jr's pull should be maybe considered for soon release, in case there is extended period of two chains
190 2017-10-26 19:26:36 0|karelb|sorry for breaking in, the plan is that you cannot simultaneously run 2x and btc on the same IP? that is unfortunate
191 2017-10-26 19:26:41 0|morcos|but maybe 0.15.1 espeically if its not ready yet
192 2017-10-26 19:26:48 0|wumpus|gmaxwell: and by that time the first ones will have unbanned them again
193 2017-10-26 19:26:52 0|luke-jr|gmaxwell: even with the peers banning them?
194 2017-10-26 19:27:05 0|morcos|karelb: that's not the plan, thats an unfortunate side effect of the existing software
195 2017-10-26 19:27:11 0|gmaxwell|luke-jr: yes, because the banning goes slowly.
196 2017-10-26 19:27:39 0|gmaxwell|karelb: 2x foolishly connects to non-2x nodes and will relay them invalid blocks, so it will get itself banned.
197 2017-10-26 19:27:42 0|achow101|banning also requires blocks to be found, so ...
198 2017-10-26 19:28:18 0|achow101|that means 144 peers to switch through per day, on average
199 2017-10-26 19:28:40 0|luke-jr|gmaxwell: just because it hits 20% DoS penalty each header?
200 2017-10-26 19:28:47 0|wumpus|karelb: it could have been resolved with e.g. service bits if 2x was willing, but they're insisting on making this a mess, so we have to do the least harmful thing for the existing bitcoin network
201 2017-10-26 19:28:49 0|karelb|oh OK. That happens with the current core node
202 2017-10-26 19:28:53 0|BlueMatt|karelb: if you run 2x nodes without their broken -pretendimnot2x then no, you cannot, if you dont use that option, you should be fine
203 2017-10-26 19:28:58 0|gmaxwell|karelb: yes.
204 2017-10-26 19:29:19 0|wumpus|BlueMatt: exactly
205 2017-10-26 19:29:24 0|karelb|BlueMatt ðŸâ great
206 2017-10-26 19:29:37 0|BlueMatt|(which is another point against 10593)
207 2017-10-26 19:29:40 0|gmaxwell|luke-jr: also as matt points out, if you don't undermine service flag disconnects you won't get banned by bitcoin 0.15+ peers, so I think that answers your concern/.
208 2017-10-26 19:29:46 0|luke-jr|ok
209 2017-10-26 19:30:10 0|BlueMatt|if you run with -imstupidandignorereason, you should get banned, thats your problem, not mine
210 2017-10-26 19:30:14 0|karelb|what would be the reason of running that option? what is the incentive for the 2x node to connect to core nodes?
211 2017-10-26 19:30:26 0|BlueMatt|karelb: please not mid-meeting
212 2017-10-26 19:30:26 0|gmaxwell|in the long run I want to move away from banning more or less entirely but that isn't a thing to worry about for now.
213 2017-10-26 19:30:29 0|karelb|ok
214 2017-10-26 19:30:31 0|karelb|sorry
215 2017-10-26 19:30:31 0|morcos|ok yes, thats a good point that we should publish, unfortunately lots of companies will need to run both
216 2017-10-26 19:30:53 0|BlueMatt|gmaxwell: lots to be fixed in our dos/ban/disconnect logic, indeed
217 2017-10-26 19:31:13 0|morcos|ok back to question... list is good, please ack if you know what you're talking about. alex was here.
218 2017-10-26 19:31:21 0|sdaftuar|getting back to 0.15.0.2 -- i think the currently tagged PRs cover all the cases i think we would ideally cover pre-b2x
219 2017-10-26 19:31:25 0|achow101|list looks good to me
220 2017-10-26 19:31:36 0|wumpus|sdaftuar: great!
221 2017-10-26 19:31:47 0|gmaxwell|What sdaftuar said
222 2017-10-26 19:31:51 0|wumpus|let's focus on getting these reviewed and merged as soon as possible then
223 2017-10-26 19:31:56 0|achow101|+1
224 2017-10-26 19:31:58 0|wumpus|and lot's not add any new ones unless absolutely necessary
225 2017-10-26 19:32:20 0|gmaxwell|unless some interesting bug crops up I don't see why we would.
226 2017-10-26 19:32:25 0|meshcollider|Sounds good
227 2017-10-26 19:32:27 0|BlueMatt|ok, so #action 24-hour review sprint?
228 2017-10-26 19:32:37 0|gmaxwell|like maybe B2X's developer tells us about this mysterious instability in 0.15. :)
229 2017-10-26 19:32:53 0|morcos|i can't wait to tell them about my embargoed accidental hard fork
230 2017-10-26 19:33:00 0|BlueMatt|gmaxwell: lol, uh huhhhhh
231 2017-10-26 19:33:56 0|luke-jr|FTR, the problematic option is -advertise2x=0 or -noadvertise2x
232 2017-10-26 19:34:21 0|BlueMatt|aka -shootmeinthefacekthx
233 2017-10-26 19:34:25 0|cfields|BlueMatt: i'll commit to a 24hr sprint, at least ack/nack/cfields was here on all of those PRs.
234 2017-10-26 19:34:57 0|wumpus|I'll try
235 2017-10-26 19:34:58 0|gmaxwell|I'll test and review all that I haven't yet, of course.
236 2017-10-26 19:35:15 0|BlueMatt|ok, just gotta finish caching debug.log writing on fibre nodes then I'll do it
237 2017-10-26 19:35:32 0|BlueMatt|30+ms pauses fron debug.log prints, ftr...........
238 2017-10-26 19:35:43 0|gmaxwell|BlueMatt: we could also release note this point-- that running -shootmeinthefacekthx will cause your IP to get banned by bitcoin nodes when the fork happens and make it harder to switch back or run both.
239 2017-10-26 19:35:53 0|gmaxwell|so uh. I hate to do this.
240 2017-10-26 19:35:55 0|gmaxwell|but
241 2017-10-26 19:35:58 0|achow101|oh no
242 2017-10-26 19:36:28 0|gmaxwell|... I believe a one liner is possible to detect if our chainstate DB has been corrupted by running b2x post fork... would it be worthwhile to have that?
243 2017-10-26 19:36:45 0|gmaxwell|e.g. check out block at the fork height and see if its too big.
244 2017-10-26 19:36:48 0|kanzure|detect and warn?
245 2017-10-26 19:36:54 0|wumpus|yes, that would be worth it
246 2017-10-26 19:36:59 0|gmaxwell|and then shut down with a polite fuck you instead of just sitting stuck.
247 2017-10-26 19:37:04 0|kanzure|detect and exit?
248 2017-10-26 19:37:06 0|wumpus|yes
249 2017-10-26 19:37:09 0|BlueMatt|yea, I think so :'(
250 2017-10-26 19:37:11 0|cfields|gmaxwell: that sounds like exactly the kind of thing we should be aiming for in 0.15.0.2 :(
251 2017-10-26 19:37:14 0|gmaxwell|all we can do is exit and tell you to reindex.
252 2017-10-26 19:37:16 0|achow101|I guess..
253 2017-10-26 19:37:17 0|morcos|in my opinion it'll be more than 24 hours until we agree if a 1-liner makes sense. i think we should just tell people you must reindex chainstate if you switch back...
254 2017-10-26 19:37:19 0|BlueMatt|i guess at least thats easy to review
255 2017-10-26 19:37:19 0|jnewbery|polite fuck you == "please use invalidateblock RPC" ?
256 2017-10-26 19:37:29 0|luke-jr|gmaxwell: why shut down? we can already rewind..
257 2017-10-26 19:37:30 0|gmaxwell|oaky I'm sorry for the scope creep. It should be a near oneliner.
258 2017-10-26 19:37:41 0|luke-jr|jnewbery: need to automatic it, because RPC won't work if we shutdown
259 2017-10-26 19:37:50 0|BlueMatt|jnewbery: no, I think probably easier to just printf("please reindex") exit();
260 2017-10-26 19:37:58 0|wumpus|that's more work
261 2017-10-26 19:38:00 0|gmaxwell|it's not easy to test unfortunately.
262 2017-10-26 19:38:05 0|luke-jr|BlueMatt: we already have code to rewind for segwit rechecking
263 2017-10-26 19:38:06 0|wumpus|for master it probably makes sense to make it automatic
264 2017-10-26 19:38:11 0|wumpus|but that's not realistic for 0.15.0.2
265 2017-10-26 19:38:13 0|BlueMatt|yea, i dont want to test any of this, or think about complicated interactions
266 2017-10-26 19:38:18 0|BlueMatt|just printf and exit
267 2017-10-26 19:38:22 0|wumpus|as gmaxwell says, warn+exit is better than mystieriously getting stuck
268 2017-10-26 19:38:24 0|wumpus|that's the aim here
269 2017-10-26 19:38:37 0|achow101|I support the thing that requires less work to review
270 2017-10-26 19:38:55 0|sdaftuar|i don't know that i think it's worth it, but i don't object i guess if other people want to add this "feature"
271 2017-10-26 19:39:12 0|gmaxwell|okay, I'll do the simplest possible first we could also consider others for master/later/etc...
272 2017-10-26 19:39:15 0|BlueMatt|morcos: points out this does not work on a pruned node, i forgot about that....
273 2017-10-26 19:39:19 0|wumpus|sdaftuar: less mysterious bug reports...
274 2017-10-26 19:39:22 0|wumpus|sdaftuar: that's always a plus
275 2017-10-26 19:39:31 0|morcos|can we agree that this extra PR is lower priority than the others, lets not risk getting 0 of them out
276 2017-10-26 19:39:39 0|gmaxwell|SURE
277 2017-10-26 19:39:41 0|wumpus|morcos: I agree with that too
278 2017-10-26 19:39:56 0|gmaxwell|I don't even 'want' it so much as I realized it was a problem people will encounter which we could address.
279 2017-10-26 19:39:56 0|wumpus|I think it's worth doing in general, don't care if it doesn't get into 0.15.0.2
280 2017-10-26 19:39:58 0|morcos|tag it "Extra Credit"
281 2017-10-26 19:40:06 0|sdaftuar|haha sounds good to me
282 2017-10-26 19:40:14 0|wumpus|fine for 0.15.1 too
283 2017-10-26 19:40:21 0|wumpus|heh
284 2017-10-26 19:40:35 0|gmaxwell|well I'll try something. decide if you want to review it or not.
285 2017-10-26 19:40:41 0|kanzure|might make sense for flip floppers later
286 2017-10-26 19:41:09 0|gmaxwell|after the fork it can just hardcode the hash. :)
287 2017-10-26 19:41:18 0|wumpus|yep
288 2017-10-26 19:41:30 0|gmaxwell|e.g. like doing an invalidateblock <b2xcrap> at startup.
289 2017-10-26 19:42:19 0|gmaxwell|I agree it's certantly less important in part because we can address with announcements/release notes-- don't do this.
290 2017-10-26 19:43:03 0|BlueMatt|sipa: we're doing 24 hour code review spring for 0.15.0.2, you owe us review on 4 prs today! :p
291 2017-10-26 19:43:54 0|sipa|BlueMatt: i'll try!
292 2017-10-26 19:44:16 0|achow101|not just 4 PRs, the 4 PRs tagged for 0.15.0.2
293 2017-10-26 19:45:47 0|luke-jr|we could make a BLOCK_OPT_WITNESS-like thing and require it for the 2X height block only.. but that'll break normal upgrades too
294 2017-10-26 19:45:52 0|luke-jr|not sure it's worth it
295 2017-10-26 19:46:02 0|spudowiar|Which PRs are those? https://github.com/bitcoin/bitcoin/projects/8 shows one PR under "Review priority for 0.15.0.2"
296 2017-10-26 19:46:11 0|achow101|spudowiar: https://github.com/bitcoin/bitcoin/milestone/32
297 2017-10-26 19:46:17 0|wumpus|spudowiar: just use the milestone https://github.com/bitcoin/bitcoin/milestone/32
298 2017-10-26 19:46:21 0|spudowiar|Thanks, sorry
299 2017-10-26 19:46:35 0|wumpus|yeah no problem, I'll update review priority too
300 2017-10-26 19:47:02 0|achow101|other topics?
301 2017-10-26 19:49:16 0|wumpus|apparently not
302 2017-10-26 19:49:17 0|achow101|In other news, I got someone to write meeting notes for the website. we'll try to get through all of the meetings missed too
303 2017-10-26 19:49:27 0|wumpus|achow101: that's great news!
304 2017-10-26 19:49:34 0|meshcollider|\o/
305 2017-10-26 19:50:08 0|gmaxwell|bad news is that the someone is roger ver.
306 2017-10-26 19:50:13 0|gmaxwell|:P
307 2017-10-26 19:50:23 0|achow101|lol. no
308 2017-10-26 19:50:24 0|wumpus|hahahaha
309 2017-10-26 19:51:00 0|luke-jr|XD
310 2017-10-26 19:51:11 0|luke-jr|achow101: you've checked?
311 2017-10-26 19:51:26 0|meshcollider|Comic relief would be the whole meeting notes
312 2017-10-26 19:51:38 0|achow101|luke-jr: unless I am blind, I am pretty sure the person writing the notes next to me is roger ver
313 2017-10-26 19:51:43 0|achow101|*is not
314 2017-10-26 19:51:49 0|gmaxwell|uh oh.
315 2017-10-26 19:51:53 0|luke-jr|achow101: maybe on his payroll :P
316 2017-10-26 19:52:12 0|achow101|now we got our comic relief :p
317 2017-10-26 19:52:52 0|lightningbot|Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-26-19.00.log.html
318 2017-10-26 19:52:52 0|lightningbot|Meeting ended Thu Oct 26 19:52:51 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
319 2017-10-26 19:52:52 0|lightningbot|Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-26-19.00.html
320 2017-10-26 19:52:52 0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-26-19.00.txt
321 2017-10-26 19:52:52 0|wumpus|#endmeeting
322 2017-10-26 19:53:03 0|sdaftuar|ico time?
323 2017-10-26 19:53:39 0|BlueMatt|sdaftuar: wait, we cant both ICO, I'm ICOing first!
324 2017-10-26 19:53:39 0|gmaxwell|ICO time.
325 2017-10-26 19:53:56 0|gmaxwell|pretty sure everyone can ICO, theres is like an app for it or something.
326 2017-10-26 19:54:06 0|clarkmoody|When your One More Thing (TM) comes from gmaxwell ...
327 2017-10-26 19:54:12 0|sdaftuar|rafalcpp: if you had questions about #11560 i'd be happy to discuss
328 2017-10-26 19:54:13 0|gribble|https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar ÷ Pull Request #11560 ÷ bitcoin/bitcoin ÷ GitHub
329 2017-10-26 19:54:15 0|gmaxwell|I heard about it in an email with the subject lime "Make Money Fast".
330 2017-10-26 19:54:23 0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cf8c4a7633b1...d93fa261f079
331 2017-10-26 19:54:24 0|bitcoin-git|13bitcoin/06master 145a6d00c 15Suhas Daftuar: Permit disconnection of outbound peers on bad/slow chains...
332 2017-10-26 19:54:24 0|bitcoin-git|13bitcoin/06master 14c60fd71 15Suhas Daftuar: Disconnecting from bad outbound peers in IBD...
333 2017-10-26 19:54:25 0|achow101|mmm. subject limes
334 2017-10-26 19:54:25 0|bitcoin-git|13bitcoin/06master 14e065249 15Suhas Daftuar: Add unit test for outbound peer eviction
335 2017-10-26 19:54:28 0|cfields|gmaxwell: it matters who's first though. If only we had some way to trustlessly timestamp things...
336 2017-10-26 19:54:32 0|luke-jr|ICO is just scamcoins 2.0; BlueMatt once had a generator..
337 2017-10-26 19:54:34 0|sdaftuar|wumpus: thanks!
338 2017-10-26 19:54:42 0|esotericnonsense|gmaxwell: well the title isn't wrong.
339 2017-10-26 19:54:43 0|sdaftuar|rebase time...
340 2017-10-26 19:54:47 0|rafalcpp|sdaftuar: right, it's the question that was posted above
341 2017-10-26 19:55:07 0|gmaxwell|cfields: it could be a device that ticks at a regular interval
342 2017-10-26 19:55:11 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11490: Disconnect from outbound peers with bad headers chains (06master...062017-10-outbound-peers-good-chain) 02https://github.com/bitcoin/bitcoin/pull/11490
343 2017-10-26 19:55:19 0|maaku|esotericnonsense: don't you go monetizing regtest coins!
344 2017-10-26 19:55:47 0|sdaftuar|nMaxConnections is generally much larger than nMaxOutbound, but yes if someone set nMaxConnections very low, then i think that could cause issues. but that's no different eg than running with -connect= or something, i think?
345 2017-10-26 19:56:01 0|sdaftuar|rafalcpp: ie if you run with non-standard p2p config, then i think you could run into issues... maybe worth release noting?
346 2017-10-26 19:56:17 0|cfields|gmaxwell: 15 seconds? :p
347 2017-10-26 19:57:08 0|luke-jr|btw, the advertise2x warning seems more appropriate for a blog post than release notes, since it has nothing to do with our release
348 2017-10-26 19:57:21 0|meshcollider|Only 3 PRs left to review now :)
349 2017-10-26 19:57:24 0|rafalcpp|sdaftuar: dunno, maybe? :) I didn't yet developed on bitcoin. Wouldn't it be possible to increase both sides of min?
350 2017-10-26 19:58:52 0|gmaxwell|luke-jr: well I dunno the release note is "if you plan on using this program with that program on the same computer"
351 2017-10-26 19:59:00 0|rafalcpp|though then we're skipping check for system limit of connections so maybe not. sdaftuar
352 2017-10-26 19:59:05 0|sdaftuar|rafalcpp: i think it makes more sense for the user to continue to have a toggle for the overall number of connections, and just explain what the consequence is
353 2017-10-26 19:59:10 0|luke-jr|gmaxwell: it's also true for older releases of ours though
354 2017-10-26 19:59:34 0|gmaxwell|if we have a zillion inbound connections we probably don't need the anti-partition rotation anyways.
355 2017-10-26 19:59:35 0|wumpus|meshcollider: review is still welcome after something is merged :)
356 2017-10-26 20:02:54 0|notmike|Its time. I'm ready.
357 2017-10-26 20:04:08 0|rafalcpp|sdaftuar: to me a release note sounds good. unless also logging a warning when it happens, if that code isn't frozen
358 2017-10-26 22:17:09 0|bitcoin-git|[13bitcoin] 15jnewbery reopened pull request #10160: [WIP] updatepeer RPC (06master...06updatepeer) 02https://github.com/bitcoin/bitcoin/pull/10160