1 2016-06-16T00:01:19  *** molz has joined #bitcoin-core-dev
  2 2016-06-16T00:04:15  *** moli has quit IRC
  3 2016-06-16T00:05:45  *** kadoban has quit IRC
  4 2016-06-16T00:22:39  *** wumpus has quit IRC
  5 2016-06-16T00:24:01  *** wumpus has joined #bitcoin-core-dev
  6 2016-06-16T00:29:06  *** go1111111 has joined #bitcoin-core-dev
  7 2016-06-16T00:30:34  *** Chris_Stewart_5 has quit IRC
  8 2016-06-16T00:31:59  *** Squidicuz has joined #bitcoin-core-dev
  9 2016-06-16T00:34:33  *** Squidicc has quit IRC
 10 2016-06-16T00:35:28  *** frankenmint has joined #bitcoin-core-dev
 11 2016-06-16T00:40:01  *** frankenmint has quit IRC
 12 2016-06-16T00:41:18  *** Ylbam has quit IRC
 13 2016-06-16T00:42:23  *** nets1n has joined #bitcoin-core-dev
 14 2016-06-16T00:44:57  *** Giszmo has quit IRC
 15 2016-06-16T01:03:35  *** nets1n has quit IRC
 16 2016-06-16T01:08:13  *** jiggalator has joined #bitcoin-core-dev
 17 2016-06-16T01:11:26  *** jiggalator has quit IRC
 18 2016-06-16T01:13:32  *** lesderid_ has quit IRC
 19 2016-06-16T01:13:39  *** lesderid has joined #bitcoin-core-dev
 20 2016-06-16T01:17:44  *** achow101 has quit IRC
 21 2016-06-16T01:29:21  *** adnn has joined #bitcoin-core-dev
 22 2016-06-16T01:33:49  *** achow101 has joined #bitcoin-core-dev
 23 2016-06-16T01:36:16  *** frankenmint has joined #bitcoin-core-dev
 24 2016-06-16T01:39:20  *** Cory has quit IRC
 25 2016-06-16T01:39:53  *** PRab has joined #bitcoin-core-dev
 26 2016-06-16T01:41:03  *** Pasha has joined #bitcoin-core-dev
 27 2016-06-16T01:41:52  *** frankenmint has quit IRC
 28 2016-06-16T01:47:57  *** Pasha is now known as Cory
 29 2016-06-16T01:58:02  *** phantomcircuit_ is now known as phantomcircuit
 30 2016-06-16T01:58:07  *** kadoban has joined #bitcoin-core-dev
 31 2016-06-16T01:58:51  <phantomcircuit> jonasschnelli, can you review 8152? i'd like to move onto the next step which is moving things that aren't called externally to private and having them use a cached CWalletDB*
 32 2016-06-16T02:02:43  *** fengling has quit IRC
 33 2016-06-16T02:22:53  *** xiangfu has quit IRC
 34 2016-06-16T02:31:36  *** justanotheruser has quit IRC
 35 2016-06-16T02:37:23  *** justanotheruser has joined #bitcoin-core-dev
 36 2016-06-16T02:38:25  *** frankenmint has joined #bitcoin-core-dev
 37 2016-06-16T02:40:31  *** adnn_ has joined #bitcoin-core-dev
 38 2016-06-16T02:43:04  *** adnn has quit IRC
 39 2016-06-16T02:43:10  *** frankenmint has quit IRC
 40 2016-06-16T03:09:51  *** [b__b] has quit IRC
 41 2016-06-16T03:25:58  *** adnn has joined #bitcoin-core-dev
 42 2016-06-16T03:28:59  *** adnn_ has quit IRC
 43 2016-06-16T03:30:58  *** [b__b] has joined #bitcoin-core-dev
 44 2016-06-16T03:41:04  *** frankenmint has joined #bitcoin-core-dev
 45 2016-06-16T03:46:24  *** frankenmint has quit IRC
 46 2016-06-16T03:53:10  *** raedah2 has quit IRC
 47 2016-06-16T03:54:47  *** raedah2 has joined #bitcoin-core-dev
 48 2016-06-16T03:55:36  *** [b__b] has quit IRC
 49 2016-06-16T04:18:08  *** adnn_ has joined #bitcoin-core-dev
 50 2016-06-16T04:19:01  *** adnn has quit IRC
 51 2016-06-16T04:25:46  *** [b__b] has joined #bitcoin-core-dev
 52 2016-06-16T04:26:45  *** adnn_ has quit IRC
 53 2016-06-16T04:50:47  *** warren_ is now known as warren
 54 2016-06-16T05:11:30  *** larrysalibra has joined #bitcoin-core-dev
 55 2016-06-16T05:11:49  *** larrysalibra has quit IRC
 56 2016-06-16T05:13:44  *** larrysalibra has joined #bitcoin-core-dev
 57 2016-06-16T05:17:12  *** larrysalibra has quit IRC
 58 2016-06-16T05:24:32  *** [b__b] has quit IRC
 59 2016-06-16T05:24:54  *** [b__b] has joined #bitcoin-core-dev
 60 2016-06-16T05:30:34  *** TomMc has quit IRC
 61 2016-06-16T05:37:52  *** so has joined #bitcoin-core-dev
 62 2016-06-16T05:39:53  *** Giszmo has joined #bitcoin-core-dev
 63 2016-06-16T05:41:51  *** haakonn has joined #bitcoin-core-dev
 64 2016-06-16T05:48:32  *** spudowiar has quit IRC
 65 2016-06-16T05:51:32  *** spudowiar has joined #bitcoin-core-dev
 66 2016-06-16T05:52:46  *** pedrobranco has joined #bitcoin-core-dev
 67 2016-06-16T05:52:58  *** haakonn has quit IRC
 68 2016-06-16T05:52:58  *** so has quit IRC
 69 2016-06-16T05:55:20  *** Ylbam has joined #bitcoin-core-dev
 70 2016-06-16T05:57:03  *** pedrobranco has quit IRC
 71 2016-06-16T05:58:37  *** so has joined #bitcoin-core-dev
 72 2016-06-16T06:00:21  *** haakonn has joined #bitcoin-core-dev
 73 2016-06-16T06:03:26  <paveljanik> I'd like to be able to save mempool snapshot at shutdown so it could be "loaded" back on startup...
 74 2016-06-16T06:36:06  *** frankenmint has joined #bitcoin-core-dev
 75 2016-06-16T06:41:12  *** frankenmint has quit IRC
 76 2016-06-16T06:52:13  *** kadoban has quit IRC
 77 2016-06-16T06:53:22  <jonasschnelli> phantomcircuit: 8152 has a large diff now... but I'll try to review it.
 78 2016-06-16T06:54:49  <jonasschnelli> ?w=1 helps though
 79 2016-06-16T06:58:25  <phantomcircuit> jonasschnelli: there's very little changed only things moved
 80 2016-06-16T06:58:34  <jonasschnelli> Yes. Will test now.
 81 2016-06-16T06:58:43  <phantomcircuit> (there is some changed, but most of the lines are just moving stuff and changing the indentation)
 82 2016-06-16T07:20:52  <jonasschnelli> paveljanik MarcoFalke: https://github.com/bitcoin/bitcoin/pull/8207 is this ready?
 83 2016-06-16T07:36:50  *** frankenmint has joined #bitcoin-core-dev
 84 2016-06-16T07:37:09  <paveljanik> yes, we can fix the URL later
 85 2016-06-16T07:41:26  *** frankenmint has quit IRC
 86 2016-06-16T07:43:55  *** Giszmo has quit IRC
 87 2016-06-16T08:06:48  *** tripleslash has joined #bitcoin-core-dev
 88 2016-06-16T08:10:26  *** MarcoFalke has joined #bitcoin-core-dev
 89 2016-06-16T08:37:36  *** frankenmint has joined #bitcoin-core-dev
 90 2016-06-16T08:42:15  *** frankenmint has quit IRC
 91 2016-06-16T08:49:43  *** Guyver2 has joined #bitcoin-core-dev
 92 2016-06-16T08:51:36  *** frankenmint has joined #bitcoin-core-dev
 93 2016-06-16T08:53:37  *** tripleslash has quit IRC
 94 2016-06-16T08:56:53  <GitHub163> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb0ac482eee7...f7a403b4cf22
 95 2016-06-16T08:56:53  <GitHub163> bitcoin/master fa58e5e MarcoFalke: [doc] Add website links to about dialog
 96 2016-06-16T08:56:54  <GitHub163> bitcoin/master f7a403b Wladimir J. van der Laan: Merge #8207: [trivial] Add a link to the Bitcoin-Core repository and website to the About Dialog...
 97 2016-06-16T08:57:03  <GitHub19> [bitcoin] laanwj closed pull request #8207: [trivial] Add a link to the Bitcoin-Core repository and website to the About Dialog (master...Mf1606-LicInfo) https://github.com/bitcoin/bitcoin/pull/8207
 98 2016-06-16T08:57:35  *** CubicEarth has joined #bitcoin-core-dev
 99 2016-06-16T08:58:21  <GitHub171> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f7a403b4cf22...0a64777b909e
100 2016-06-16T08:58:21  <GitHub171> bitcoin/master bc0a895 Pieter Wuille: Do not set extra flags for unfiltered DNS seed results
101 2016-06-16T08:58:22  <GitHub171> bitcoin/master 0a64777 Wladimir J. van der Laan: Merge #8208: Do not set extra flags for unfiltered DNS seed results...
102 2016-06-16T08:58:33  <GitHub118> [bitcoin] laanwj closed pull request #8208: Do not set extra flags for unfiltered DNS seed results (master...simplerservices) https://github.com/bitcoin/bitcoin/pull/8208
103 2016-06-16T09:00:43  *** fengling has joined #bitcoin-core-dev
104 2016-06-16T09:04:11  <GitHub95> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0a64777b909e...e4bb4a85a551
105 2016-06-16T09:04:12  <GitHub95> bitcoin/master 5d0ca81 Gregory Maxwell: Add recently accepted blocks and txn to AttemptToEvictConnection....
106 2016-06-16T09:04:12  <GitHub95> bitcoin/master 6ee7f05 Gregory Maxwell: Allow disconnecting a netgroup with only one member in eviction....
107 2016-06-16T09:04:13  <GitHub95> bitcoin/master e4bb4a8 Wladimir J. van der Laan: Merge #8084: Add recently accepted blocks and txn to AttemptToEvictConnection....
108 2016-06-16T09:04:21  <GitHub166> [bitcoin] laanwj closed pull request #8084: Add recently accepted blocks and txn to AttemptToEvictConnection. (master...protect_recent_blocks) https://github.com/bitcoin/bitcoin/pull/8084
109 2016-06-16T09:05:36  *** AtashiCon has quit IRC
110 2016-06-16T09:07:12  <GitHub112> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e4bb4a85a551...62fcf27bd8d7
111 2016-06-16T09:07:12  <GitHub112> bitcoin/master 6fa950a Jonas Schnelli: [RPC] Fix createrawtx sequence number unsigned int parsing
112 2016-06-16T09:07:13  <GitHub112> bitcoin/master 62fcf27 Wladimir J. van der Laan: Merge #8171: [RPC] Fix createrawtx sequence number unsigned int parsing...
113 2016-06-16T09:07:22  <GitHub191> [bitcoin] laanwj closed pull request #8171: [RPC] Fix createrawtx sequence number unsigned int parsing (master...2016/06/fix_crt) https://github.com/bitcoin/bitcoin/pull/8171
114 2016-06-16T09:07:35  <jonasschnelli> cfields_: I'm working on Qt5.6.1 fix... I can compile it.. but had to restore two .pc files. Any idea why Qt.5.6.1 does not come with Qt5XcbQpa.pc and Qt5PlatformSupport.pc?
115 2016-06-16T09:12:43  *** ennui has joined #bitcoin-core-dev
116 2016-06-16T09:16:24  *** Anduck_ is now known as Anduck
117 2016-06-16T09:22:23  <wumpus> I don't think cfields_ is back yet :)
118 2016-06-16T09:23:39  *** pedrobranco has joined #bitcoin-core-dev
119 2016-06-16T09:28:35  <paveljanik> interesting, I'll again try new dmg installer on OS X
120 2016-06-16T09:30:38  *** kcud_dab is now known as bad_duck
121 2016-06-16T09:31:45  *** ws2k3 has joined #bitcoin-core-dev
122 2016-06-16T09:32:05  <wumpus> jonasschnelli: that's curious! maybe qt git history will tell us something
123 2016-06-16T09:32:13  <ws2k3> hello, my bitcoin core says no source for block available how can i fix this?
124 2016-06-16T09:32:32  <jonasschnelli> Ah right. cfields_ is not here...
125 2016-06-16T09:32:47  <jonasschnelli> wumpus: I looked into it and could not figure it out... but maybe need to look closer.
126 2016-06-16T09:32:54  <wumpus> ws2k3: fix your internet connection, usually :)
127 2016-06-16T09:33:20  <wumpus> usually means it cannot connect to other nodes (on port 8333)
128 2016-06-16T09:34:54  <paveljanik> jonasschnelli, https://bugreports.qt.io/browse/QTBUG-50073
129 2016-06-16T09:35:09  <ws2k3> wumpus it does say 8 connection to the bitcoin network
130 2016-06-16T09:35:20  <ws2k3> but in the left bottum it still says no source for blocks available
131 2016-06-16T09:35:27  <wumpus> how long has it been showing that there is no source for blocks available?
132 2016-06-16T09:35:45  <ws2k3> wumpus sinds i started using it(15 min ago)
133 2016-06-16T09:36:07  <ws2k3> wumpus i already restarted it a few times
134 2016-06-16T09:36:27  <wumpus> ok, no idea then
135 2016-06-16T09:36:55  <wumpus> anything strange in debug.log?
136 2016-06-16T09:42:55  <ws2k3> wumpus no nothing strange there i now have connection with 8 nodes it says. but it still does not download data
137 2016-06-16T09:43:45  <wumpus> what is the output of 'getpeerinfo'?
138 2016-06-16T09:44:24  <ws2k3> wumpus it shows a huge list i can pastebin if you want?
139 2016-06-16T09:44:30  <wumpus> yes
140 2016-06-16T09:44:58  <jonasschnelli> paveljanik: thanks!
141 2016-06-16T09:46:42  <wumpus> also the output of getblockchaininfo would be useful
142 2016-06-16T09:48:21  <ws2k3> wumpus i sended you a link
143 2016-06-16T09:49:12  <wumpus> hm apparently the node is at block 136572 - which means it did download some blocks earlier on
144 2016-06-16T09:49:44  <wumpus> but it isn't requesting any new blocks
145 2016-06-16T09:50:41  *** Arnavion has quit IRC
146 2016-06-16T09:50:46  *** Arnavion3 has joined #bitcoin-core-dev
147 2016-06-16T09:50:49  *** Arnavion3 is now known as Arnavion
148 2016-06-16T09:51:23  <wumpus> can you try: getblockheader 00000000000003ba98accad570d9b74fff1287508cbabb0955b54f0dc18ef64e  (that's the block after it)
149 2016-06-16T09:52:45  <wumpus> ok this makes no sense, it is supposed to return BLOCK_SOURCE_NETWORK in every case that there is more than one network connection
150 2016-06-16T09:53:04  <wumpus> so with those peers it certainly shouldn't be showing no block source available
151 2016-06-16T09:53:16  <ws2k3> wumpus i runned the command and it gave me some output
152 2016-06-16T09:53:30  <wumpus> looks like the GUI is stuck but it is actually doing something in the background?
153 2016-06-16T09:53:39  <ws2k3> wumpus should i pastebin it
154 2016-06-16T09:53:46  <ws2k3> wumpus it does not seem to do anything atm
155 2016-06-16T09:54:00  <wumpus> if you call getblockchaininfo multiple times in a row does the number of blocks increase?
156 2016-06-16T09:54:06  <wumpus> nah, not necessary
157 2016-06-16T09:54:51  <ws2k3> wumpus no the block number does not raise
158 2016-06-16T09:55:32  <ws2k3> wumpus but the network graph shows it does around 50 kbps
159 2016-06-16T09:55:33  <wumpus> can you try reconsiderblock 00000000000003ba98accad570d9b74fff1287508cbabb0955b54f0dc18ef64e
160 2016-06-16T09:56:20  <ws2k3> wumpus i runned the command output is emty
161 2016-06-16T09:56:36  <wumpus> anything in debug.log?
162 2016-06-16T09:57:36  <ws2k3> wumpus check link i pastebinned
163 2016-06-16T09:58:04  <wumpus> 2016-06-16 09:50:28 ProcessMessages(headers, 162003 bytes) FAILED peer=2
164 2016-06-16T09:58:04  <wumpus> 2016-06-16 09:55:51 ERROR: ConnectBlock(): tried to overwrite transaction
165 2016-06-16T09:58:08  <wumpus> ouch, your database is broken
166 2016-06-16T09:58:18  <wumpus> restart with the -reindex flag
167 2016-06-16T09:59:04  <ws2k3> wumpus i did its not reindexing
168 2016-06-16T09:59:41  <wumpus> ok then backup wallet.dat, remove the entire data directory
169 2016-06-16T09:59:54  <wumpus> and restart
170 2016-06-16T10:00:37  <ws2k3> wumpus sorry i made a typo. it is reindexing now
171 2016-06-16T10:00:53  <ws2k3> 5 years 2 weeks and counting down
172 2016-06-16T10:04:21  *** [b__b] has quit IRC
173 2016-06-16T10:05:25  *** [b__b] has joined #bitcoin-core-dev
174 2016-06-16T10:07:14  <GitHub161> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/62fcf27bd8d7...3f89a534acfe
175 2016-06-16T10:07:15  <GitHub161> bitcoin/master 1111b80 Pieter Wuille: Rework addnode behaviour...
176 2016-06-16T10:07:15  <GitHub161> bitcoin/master f9f5cfc Pieter Wuille: Prevent duplicate connections where one is by name and another by ip
177 2016-06-16T10:07:16  <GitHub161> bitcoin/master 1a5a4e6 Pieter Wuille: Randomize name lookup result in ConnectSocketByName
178 2016-06-16T10:07:18  <GitHub63> [bitcoin] laanwj closed pull request #8113: Rework addnode behaviour (master...saneaddednode) https://github.com/bitcoin/bitcoin/pull/8113
179 2016-06-16T10:08:33  *** laurentmt has joined #bitcoin-core-dev
180 2016-06-16T10:08:40  *** murch has joined #bitcoin-core-dev
181 2016-06-16T10:08:53  <GitHub188> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f89a534acfe...9c3d0fab3623
182 2016-06-16T10:08:54  <GitHub188> bitcoin/master 60ab9b2 Wladimir J. van der Laan: Squashed 'src/univalue/' changes from 2740c4f..f32df99...
183 2016-06-16T10:08:54  <GitHub188> bitcoin/master 6315152 Wladimir J. van der Laan: Merge commit '60ab9b200654ef0914459711cf2b22be16be3dc2'
184 2016-06-16T10:08:55  <GitHub188> bitcoin/master a406fcb Wladimir J. van der Laan: test: add ensure_ascii setting to AuthServiceProxy...
185 2016-06-16T10:08:58  <GitHub4> [bitcoin] laanwj closed pull request #7892: Add full UTF-8 support to RPC (master...2016_04_i18n_unicode_rpc) https://github.com/bitcoin/bitcoin/pull/7892
186 2016-06-16T10:09:48  *** pedrobranco has quit IRC
187 2016-06-16T10:11:19  *** [b__b] has quit IRC
188 2016-06-16T10:12:31  *** laurentmt has quit IRC
189 2016-06-16T10:17:35  <wumpus> PSA: it looks like the build system doesn't detect changes to univalue source files and will not automatically rebuild the library: **if you get RPC test failures concerning unicode, please build from a clean tree**
190 2016-06-16T10:18:38  *** G1lius has joined #bitcoin-core-dev
191 2016-06-16T10:21:34  *** molz has quit IRC
192 2016-06-16T10:22:54  *** gevs has quit IRC
193 2016-06-16T10:23:25  *** pedrobranco has joined #bitcoin-core-dev
194 2016-06-16T10:24:03  *** [b__b] has joined #bitcoin-core-dev
195 2016-06-16T10:26:45  *** pedrobranco has quit IRC
196 2016-06-16T10:30:07  *** CubicEarth has quit IRC
197 2016-06-16T10:34:47  *** gevs has joined #bitcoin-core-dev
198 2016-06-16T10:34:48  *** gevs has joined #bitcoin-core-dev
199 2016-06-16T10:36:52  *** pedrobranco has joined #bitcoin-core-dev
200 2016-06-16T10:41:08  *** pedrobranco has quit IRC
201 2016-06-16T10:41:36  *** pedrobranco has joined #bitcoin-core-dev
202 2016-06-16T11:17:19  *** pedrobranco has quit IRC
203 2016-06-16T11:18:02  *** pedrobranco has joined #bitcoin-core-dev
204 2016-06-16T11:21:17  *** mkarrer has quit IRC
205 2016-06-16T11:21:25  *** mkarrer has joined #bitcoin-core-dev
206 2016-06-16T11:25:13  *** pedrobranco has quit IRC
207 2016-06-16T11:26:34  *** pedrobranco has joined #bitcoin-core-dev
208 2016-06-16T11:27:09  *** AtashiCon has joined #bitcoin-core-dev
209 2016-06-16T11:27:15  *** mkarrer has quit IRC
210 2016-06-16T11:29:20  *** mkarrer has joined #bitcoin-core-dev
211 2016-06-16T11:29:20  *** pedrobranco has quit IRC
212 2016-06-16T11:30:55  *** Arnavion has quit IRC
213 2016-06-16T11:31:00  *** Arnavion has joined #bitcoin-core-dev
214 2016-06-16T11:35:04  *** pedrobranco has joined #bitcoin-core-dev
215 2016-06-16T11:36:30  *** cryptapus has joined #bitcoin-core-dev
216 2016-06-16T11:41:08  *** frankenmint has quit IRC
217 2016-06-16T11:43:25  *** pedrobranco has quit IRC
218 2016-06-16T11:44:45  *** pedrobranco has joined #bitcoin-core-dev
219 2016-06-16T11:45:49  *** mkarrer has quit IRC
220 2016-06-16T11:46:11  *** mkarrer has joined #bitcoin-core-dev
221 2016-06-16T11:52:12  *** kadoban has joined #bitcoin-core-dev
222 2016-06-16T11:57:48  *** pedrobranco has quit IRC
223 2016-06-16T12:01:44  *** pedrobranco has joined #bitcoin-core-dev
224 2016-06-16T12:11:19  *** mkarrer has quit IRC
225 2016-06-16T12:15:35  *** mkarrer has joined #bitcoin-core-dev
226 2016-06-16T12:22:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
227 2016-06-16T12:26:42  *** mkarrer has quit IRC
228 2016-06-16T12:27:00  *** mkarrer has joined #bitcoin-core-dev
229 2016-06-16T12:28:06  *** pedrobranco has quit IRC
230 2016-06-16T12:31:29  *** Humanity has joined #bitcoin-core-dev
231 2016-06-16T12:33:52  *** pedrobranco has joined #bitcoin-core-dev
232 2016-06-16T12:41:52  *** frankenmint has joined #bitcoin-core-dev
233 2016-06-16T12:47:54  *** frankenmint has quit IRC
234 2016-06-16T12:58:22  *** pedrobranco has quit IRC
235 2016-06-16T13:03:40  *** kadoban has quit IRC
236 2016-06-16T13:03:44  *** pedrobranco has joined #bitcoin-core-dev
237 2016-06-16T13:25:26  *** Sosumi has joined #bitcoin-core-dev
238 2016-06-16T13:28:13  *** Humanity has left #bitcoin-core-dev
239 2016-06-16T13:38:57  *** TomMc has joined #bitcoin-core-dev
240 2016-06-16T13:44:10  *** frankenmint has joined #bitcoin-core-dev
241 2016-06-16T13:48:51  *** frankenmint has quit IRC
242 2016-06-16T14:00:10  *** MarcoFalke has left #bitcoin-core-dev
243 2016-06-16T14:06:06  *** pedrobranco has quit IRC
244 2016-06-16T14:08:13  *** JackH has joined #bitcoin-core-dev
245 2016-06-16T14:09:50  *** molz has joined #bitcoin-core-dev
246 2016-06-16T14:13:45  *** pedrobranco has joined #bitcoin-core-dev
247 2016-06-16T14:16:34  *** CubicEarth has joined #bitcoin-core-dev
248 2016-06-16T14:18:34  *** CubicEarth has quit IRC
249 2016-06-16T14:24:33  *** Giszmo has joined #bitcoin-core-dev
250 2016-06-16T14:31:31  *** pedrobranco has quit IRC
251 2016-06-16T14:32:02  *** pedrobranco has joined #bitcoin-core-dev
252 2016-06-16T14:39:15  *** mkarrer has quit IRC
253 2016-06-16T14:39:40  *** mkarrer has joined #bitcoin-core-dev
254 2016-06-16T14:46:16  *** Chris_Stewart_5 has quit IRC
255 2016-06-16T14:53:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
256 2016-06-16T14:59:08  *** slackircbridge has quit IRC
257 2016-06-16T14:59:19  *** slackircbridge1 has joined #bitcoin-core-dev
258 2016-06-16T15:16:28  *** TomMc has quit IRC
259 2016-06-16T15:20:05  *** Chris_Stewart_5 has quit IRC
260 2016-06-16T15:36:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
261 2016-06-16T15:40:43  *** Chris_Stewart_5 has quit IRC
262 2016-06-16T15:54:42  *** Giszmo has quit IRC
263 2016-06-16T16:06:45  *** Frederic94500 has joined #bitcoin-core-dev
264 2016-06-16T16:08:30  *** Giszmo has joined #bitcoin-core-dev
265 2016-06-16T16:10:05  *** Yv7trNY has joined #bitcoin-core-dev
266 2016-06-16T16:13:42  *** frankenmint has joined #bitcoin-core-dev
267 2016-06-16T16:29:04  *** Yv7trNY has quit IRC
268 2016-06-16T16:52:09  *** Chris_St1 has joined #bitcoin-core-dev
269 2016-06-16T17:01:14  *** raedah2 is now known as raedah
270 2016-06-16T17:03:43  *** G1lius has quit IRC
271 2016-06-16T17:21:18  <GitHub98> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9c3d0fab3623...66db2d62d598
272 2016-06-16T17:21:19  <GitHub98> bitcoin/master c82a4e9 Suhas Daftuar: Use ancestor-feerate based transaction selection for mining...
273 2016-06-16T17:21:19  <GitHub98> bitcoin/master 29fac19 Suhas Daftuar: Add unit tests for ancestor feerate mining
274 2016-06-16T17:21:20  <GitHub98> bitcoin/master 66db2d6 Pieter Wuille: Merge #7600: Mining: Select transactions using feerate-with-ancestors...
275 2016-06-16T17:21:23  <GitHub152> [bitcoin] sipa closed pull request #7600: Mining: Select transactions using feerate-with-ancestors (master...ancestor-mining) https://github.com/bitcoin/bitcoin/pull/7600
276 2016-06-16T17:22:40  *** CubicEarth has joined #bitcoin-core-dev
277 2016-06-16T17:25:00  <sdaftuar> woot!
278 2016-06-16T17:25:18  <gmaxwell> Woot.
279 2016-06-16T17:25:46  <Chris_St1> woot?
280 2016-06-16T17:28:58  <sdaftuar> Chris_St1: i'm just glad ancestor feerate mining ("child pays for parent") was merged, is all.
281 2016-06-16T17:49:57  <GitHub121> [bitcoin] jl2012 opened pull request #8209: Showing "not_applicable" if BIP9 timeout is 0 (master...patch-13) https://github.com/bitcoin/bitcoin/pull/8209
282 2016-06-16T17:50:38  *** Chris_St1 has quit IRC
283 2016-06-16T18:06:43  *** Chris_St1 has joined #bitcoin-core-dev
284 2016-06-16T18:19:03  <btcdrak> sdaftuar: congratz
285 2016-06-16T18:25:26  *** Ylbam has quit IRC
286 2016-06-16T18:27:39  <jonasschnelli> sdaftuar: I haven't fully read myself through the CPFP PR. But how would this affect the wallet regarding fee bumps, etc.?
287 2016-06-16T18:27:59  *** Ylbam has joined #bitcoin-core-dev
288 2016-06-16T18:28:14  <jonasschnelli> Usecase: how could you "unstuck" a tx with CPFP... just use your unconfirmed/stuck input in a new transaction paying higher fees?
289 2016-06-16T18:29:53  <sipa> yes
290 2016-06-16T18:30:12  <sipa> (though that's less efficient than RBF, as you'll need to pay for inclusion of two transactions)
291 2016-06-16T18:30:41  <jonasschnelli> Okay. Thanks... but..
292 2016-06-16T18:30:53  *** CubicEarth has quit IRC
293 2016-06-16T18:31:00  <jonasschnelli> Could the enduser usecases be identical for RBF and CPFP?
294 2016-06-16T18:31:17  <jonasschnelli> Something like the "bumpfee" API?
295 2016-06-16T18:32:54  <Chris_St1> Has there been any effort to introduce property based testing? From what I can tell there isn't any in the code base yet
296 2016-06-16T18:34:19  *** Guyver2 has quit IRC
297 2016-06-16T18:34:21  *** Guyver2_ has joined #bitcoin-core-dev
298 2016-06-16T18:43:31  *** go1111111 has quit IRC
299 2016-06-16T18:50:42  <GitHub157> [bitcoin] jonasschnelli opened pull request #8210: [Qt] Bump to Qt5.6.1 (master...2016/06/qt_561) https://github.com/bitcoin/bitcoin/pull/8210
300 2016-06-16T18:54:48  *** BakSAj has joined #bitcoin-core-dev
301 2016-06-16T18:56:12  *** raedah has quit IRC
302 2016-06-16T18:56:13  *** e4xit has joined #bitcoin-core-dev
303 2016-06-16T18:57:17  <Frederic94500> When Segwit update is available and when he is activate?
304 2016-06-16T18:57:21  *** go1111111 has joined #bitcoin-core-dev
305 2016-06-16T18:58:11  *** raedah has joined #bitcoin-core-dev
306 2016-06-16T19:00:41  <wumpus> meeting time?
307 2016-06-16T19:00:49  <petertodd> yup
308 2016-06-16T19:00:52  <btcdrak> yup
309 2016-06-16T19:00:53  <wumpus> #startmeeting
310 2016-06-16T19:00:53  <lightningbot> Meeting started Thu Jun 16 19:00:53 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
311 2016-06-16T19:00:53  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
312 2016-06-16T19:00:59  <Frederic94500> Okay
313 2016-06-16T19:01:14  <BakSAj> hi
314 2016-06-16T19:01:16  <wumpus> topic suggestion: merge compactblocks for 0.13
315 2016-06-16T19:01:21  <btcdrak> ack
316 2016-06-16T19:01:29  <gmaxwell> I like topics.
317 2016-06-16T19:02:04  <jonasschnelli> replacements (RBF/bumpfee) in 0.13
318 2016-06-16T19:02:30  <btcdrak> segwit status
319 2016-06-16T19:02:32  <jonasschnelli> ack for compactblocks topic
320 2016-06-16T19:02:35  <sipa> topic: i propose pushing the feature freeze one week further for CB and segwit to stabilize
321 2016-06-16T19:02:42  <gmaxwell> sipa: morcos: sdaftuar: jonasschnelli: btcdrak: phantomcircuit: paveljanik:
322 2016-06-16T19:02:48  <wumpus> I really don't like that\
323 2016-06-16T19:02:53  <wumpus> we already pushed it back a month
324 2016-06-16T19:02:56  <gmaxwell> sipa: hm. so feature freeze doesn't mean the software is done.
325 2016-06-16T19:03:04  <wumpus> I really want to feature freeze this week
326 2016-06-16T19:03:06  <gmaxwell> it's not like we're waiting for new features for these things.
327 2016-06-16T19:03:20  <gmaxwell> Is the issue just that we're worred about destablizing master a bit?
328 2016-06-16T19:03:28  <wumpus> note that it's okay to merge something that still needs some work given that it can be done before rc1
329 2016-06-16T19:03:35  <btcdrak> CB is mergeable. any bug fixes woudl be minor and can be merged afterwards.
330 2016-06-16T19:03:36  <wumpus> but we really want to merge things now
331 2016-06-16T19:03:43  <sdaftuar> CB is not mergeable imo
332 2016-06-16T19:03:52  <sipa> well CB and segwit cannot be merged both
333 2016-06-16T19:03:55  <wumpus> of course it shouldn't leave master in broken state
334 2016-06-16T19:03:56  <sdaftuar> also true
335 2016-06-16T19:04:04  <sipa> not right now
336 2016-06-16T19:04:12  *** moli has joined #bitcoin-core-dev
337 2016-06-16T19:04:27  <gmaxwell> sdaftuar: do you think it's mergable with the outstanding raised issues resolved?
338 2016-06-16T19:04:36  <luke-jr> we can merge segwit+CB+CPFP and let them stabilise in master?
339 2016-06-16T19:04:43  <wumpus> sdaftuar: you realize that means it misses the merge window for 0.13?
340 2016-06-16T19:04:44  <sdaftuar> i haven't finished my review, but i raised some issues last night that i think need to be addressed
341 2016-06-16T19:04:45  <gmaxwell> luke-jr: CPFP is merged now.
342 2016-06-16T19:04:49  <btcdrak> luke-jr: CPFP merged
343 2016-06-16T19:04:51  <luke-jr> oh, missed that, k
344 2016-06-16T19:05:13  <sdaftuar> actually
345 2016-06-16T19:05:25  <sdaftuar> bluematt hasn't updated yet to remove the work limit
346 2016-06-16T19:05:26  <sdaftuar> that has to go
347 2016-06-16T19:05:54  <sdaftuar> i hadn't bothered commenting because i was under the impression he's working on it
348 2016-06-16T19:05:54  <gmaxwell> the criteria for merging isn't bugfree, its free of major architectural flaws or so full of issues we're not confident that it can be believed bugfree by rc1.
349 2016-06-16T19:06:04  <wumpus> what about merging it and putting it behind an experimental option?
350 2016-06-16T19:06:23  <btcdrak> sdaftuar: agreed, but it can be removed post merge in a separate PR.
351 2016-06-16T19:06:29  <gmaxwell> sdaftuar: I presume he'll remove it as soon as he's back on.
352 2016-06-16T19:06:33  *** molz has quit IRC
353 2016-06-16T19:06:36  <luke-jr> which topic are we on now? CB?
354 2016-06-16T19:06:42  <btcdrak> yes CB
355 2016-06-16T19:06:43  <jeremyrubin> luke-jr: yes
356 2016-06-16T19:06:45  <luke-jr> #topic Compact block relay
357 2016-06-16T19:07:06  <gmaxwell> (thats why I asked if you'd think it would be mergable if the outstanding identified issues were resolved)
358 2016-06-16T19:07:39  <btcdrak> CB is clearly working as it's being live tested in the wild by major pools.
359 2016-06-16T19:07:49  <sdaftuar> there's DoS risk that has not been analyzed at all
360 2016-06-16T19:07:55  <gmaxwell> btcdrak: that doesn't mean that there aren't outstanding issues.
361 2016-06-16T19:08:05  <wumpus> what about merging it experimentally for 0.13.0
362 2016-06-16T19:08:06  <luke-jr> btcdrak: well, so is X-thin.. working in practice doesn't mean reliable
363 2016-06-16T19:08:08  <phantomcircuit> gmaxwell: present
364 2016-06-16T19:08:15  <sdaftuar> wumpus: that sounds fine to me
365 2016-06-16T19:08:25  <wumpus> put itbehind an option, then when the outstanding issues are fixed, remove that in 0.13.1 or so
366 2016-06-16T19:08:27  <sdaftuar> and we can use the time between now and the release candidates to make it more stable/reliable?
367 2016-06-16T19:08:35  <instagibbs> here as well
368 2016-06-16T19:08:37  <jeremyrubin> I'd like to see more limit options to address sdaftuar's concerns
369 2016-06-16T19:08:46  <btcdrak> the point of the feature freeze is that the main bulk of the master branch enters a stabalisation phase.
370 2016-06-16T19:08:50  <sipa> wumpus: i can live with that
371 2016-06-16T19:09:10  <wumpus> the other option is to move compactblocks to 0.14
372 2016-06-16T19:09:11  <luke-jr> wumpus: 0.13.1 shouldn't remove features IMO, but maybe changing the default would make sense
373 2016-06-16T19:09:20  <luke-jr> I don't think CB can wait for 0.14, unfortunately
374 2016-06-16T19:09:24  <jeremyrubin> I would also like to see more analysis on how CB would affect miner's txn selection
375 2016-06-16T19:09:34  <wumpus> luke-jr: this would be adding features, not removing them, and yes it's cheating of a sort
376 2016-06-16T19:09:38  <petertodd> jeremyrubin: I don't think that's a barrier to merging though
377 2016-06-16T19:09:53  <sipa> jeremyrubin: without work limit, there shouldn't be any
378 2016-06-16T19:10:05  <instagibbs> sipa, sorry what's the "work limit" here?
379 2016-06-16T19:10:05  <wumpus> seems there are still a lot of concerns for CB. why so last minute?
380 2016-06-16T19:10:09  <wumpus> why didn't this come up weeks ago?
381 2016-06-16T19:10:19  <sipa> instagibbs: not checking the entire mempool
382 2016-06-16T19:10:22  <instagibbs> oh ok
383 2016-06-16T19:10:29  <sdaftuar> i've been reviewing segwit :P
384 2016-06-16T19:10:45  <instagibbs> sdaftuar, why aren't you doing both simultaneously?
385 2016-06-16T19:10:49  <gmaxwell> wumpus: these are implementation details and people have been reviewing other things, some are driven out of last minute opimizations matt added that he didn't need to add.
386 2016-06-16T19:10:59  <wumpus> wasns't talking about you specifically sdaftuar :)
387 2016-06-16T19:11:06  <jonasschnelli> we could delay 0.13 once again. There are no urgent features and the release due date is artificial. Right?
388 2016-06-16T19:11:08  <wumpus> I know you focused on segwit, that's good
389 2016-06-16T19:11:18  <wumpus> I don't want to delay 0.13 again
390 2016-06-16T19:11:18  <jeremyrubin> sipa: without work limit there is also DOS concern (although limited by needing to re-connect)
391 2016-06-16T19:11:31  <gmaxwell> jeremyrubin: thats not true.
392 2016-06-16T19:11:37  <wumpus> too much slip and we can just forget 0.14
393 2016-06-16T19:11:39  <gmaxwell> jeremyrubin: please, this isn't helpful.
394 2016-06-16T19:12:00  <wumpus> 0.13 is good enough for a release right now
395 2016-06-16T19:12:29  <luke-jr> release 0.13 without segwit+CB then, and merge those immediately for 0.14?
396 2016-06-16T19:12:32  <jonasschnelli> I agree with wumpus: CB 0.13 as experimental (for our own protection) and non-exp in 0.13.1
397 2016-06-16T19:12:35  <wumpus> it would be nice to merge CB, and i think we should, but it's not a requiremnt
398 2016-06-16T19:12:37  <gmaxwell> lets take a step back there are two categories of remaining issue on CB,  one if the work limit stuff matt added recently. This was driven purely out of his unrelated UDP forwarding that is based on CB, which sent him into microsecond shaving mode.
399 2016-06-16T19:12:42  <sipa> i don't want (1) keep rebasing segwit (2) wait until february 2017 for CB
400 2016-06-16T19:12:59  <wumpus> sipa: me neither
401 2016-06-16T19:13:12  <jeremyrubin> I think that segwit should take priority in merging.
402 2016-06-16T19:13:14  <luke-jr> wumpus: 1 MB blocks is already killing; segwit without CB is likely to be a disaster
403 2016-06-16T19:13:20  <sipa> i am fine with making CB experimental in 0.13
404 2016-06-16T19:13:28  <petertodd> sipa: ack
405 2016-06-16T19:13:31  <sipa> if there are a few days to work out the kinks
406 2016-06-16T19:13:31  <jeremyrubin> sipa: experimental sounds fine
407 2016-06-16T19:13:39  <gmaxwell> We cannot have SW deployed with no prospect of CB live nad in use.
408 2016-06-16T19:13:44  <petertodd> gmaxwell: also ack
409 2016-06-16T19:13:45  <wumpus> sipa: there's still until july 7 for the planned rc1
410 2016-06-16T19:13:57  <sipa> wumpus: that should be plenty
411 2016-06-16T19:14:14  <wumpus> but the point is we want to merge feaatures *now*, exactly so that the next weeks can be fixing the remaining issues
412 2016-06-16T19:14:18  <BakSAj> guys, please dont delay segwit, whole community is watching you and we need capacity increase soon :-(
413 2016-06-16T19:14:24  <gmaxwell> yes, the concerns there appear small. And indeed, we SW activation not set we don't need to have CB requesting enabled.
414 2016-06-16T19:14:37  <sipa> BakSAj: this has no effect on segwit's activation time
415 2016-06-16T19:14:57  <sdaftuar> must we merge CB now though?  i feel like the bug fixes are more likely to happen in the initial PR, than trying to clean up post merge to meet the feature freeze deadline
416 2016-06-16T19:15:04  <BakSAj> oh ok then
417 2016-06-16T19:15:12  <luke-jr> oh, we're leaving SW undefined on mainnet?
418 2016-06-16T19:15:17  <sipa> luke-jr: yes
419 2016-06-16T19:15:24  <sipa> luke-jr: until a backport to 0.12 is ready
420 2016-06-16T19:15:30  <wumpus> sdaftuar: if we don't merge CB this week it misses the merge window for 0.13, and will be merged for 0.14
421 2016-06-16T19:15:32  <luke-jr> ok
422 2016-06-16T19:15:49  <gmaxwell> sdaftuar: I assumed the outstanding issues raised last night will be fixed before its merged.
423 2016-06-16T19:15:52  <wumpus> sdaftuar: bug fixes do not need to be done before the feature freeze
424 2016-06-16T19:16:01  <wumpus> it's a feature freeze, not a bug fix freeze, that would be silly
425 2016-06-16T19:16:23  <btcdrak> sdaftuar: it alows master to stabalise. Then we know there wont be hugely disruptive things getting merged post freeze.
426 2016-06-16T19:16:26  <BakSAj> sipa: how hard is it to backport segwit to 0.12.2 ?
427 2016-06-16T19:16:30  <wumpus> integration testing
428 2016-06-16T19:16:40  <jeremyrubin> wumpus: can we keep the feature freeze date and alloc an addtl week for bug fix now?
429 2016-06-16T19:16:53  <phantomcircuit> BakSAj: after the meeting?
430 2016-06-16T19:16:57  <gmaxwell> jeremyrubin: we have until july 7th for that.
431 2016-06-16T19:16:58  <petertodd> jeremyrubin: bug fix time isn't "allocated"
432 2016-06-16T19:17:04  <wumpus> jeremyrubin: do you need an additional week for bug fixing? rc1 is planned for july 7, according to sipa that was good
433 2016-06-16T19:17:19  <gmaxwell> the whole reason for feature freeze ahead of rc1 is to allow time for fixing and testing. :)
434 2016-06-16T19:17:23  <sipa> i think 3 weeks to work out the problems in CB is sufficient
435 2016-06-16T19:17:27  <sipa> they are details
436 2016-06-16T19:17:31  *** cryptapus has quit IRC
437 2016-06-16T19:17:36  <BakSAj> phantomcircuit: yeah, sure
438 2016-06-16T19:17:40  <jonasschnelli> sipa: ack
439 2016-06-16T19:17:41  <sipa> my concern with merging is that the code has been in flux the past days
440 2016-06-16T19:17:43  <wumpus> and that's only rc1, I'm sure there will be bugs in rc1, and we'll need rc2 rc3
441 2016-06-16T19:17:50  <sdaftuar> i think so too, but it seems silly that we're merging a PR that we otherwise wouldn't merge to get around a self-imposed deadline
442 2016-06-16T19:18:13  <gmaxwell> sdaftuar: I know it seems stupid, but long time expirence with creep shows that deadlines have value.
443 2016-06-16T19:18:15  <wumpus> sdaftuar: you don't think the release schedule is important?
444 2016-06-16T19:18:40  <gmaxwell> Or another way to look at it, it's fine that some well known important features get fixes and evolution, but we need a bar against other creep.
445 2016-06-16T19:18:41  <sdaftuar> wumpus: probably no point in arguing further.  i'll be happy to help work the bugs out...
446 2016-06-16T19:18:54  <wumpus> sdaftuar: no, there is really no point in arguing this
447 2016-06-16T19:18:56  <gmaxwell> (you don't want me submitting the n-th fold relay improvement or whatnot in the next couple weeks)
448 2016-06-16T19:19:04  <petertodd> sdaftuar: well, I think gmaxwell has a good point that CB is very important to get in to be ready for segwit
449 2016-06-16T19:19:04  <wumpus> and I'm kind of tired having to argue the value of having deadlines for every release
450 2016-06-16T19:20:05  <gmaxwell> With a big team, bright lines are helpful. Even if they're sometimes objectively dumb.
451 2016-06-16T19:20:15  <btcdrak> wumpus: well I for one appreciate the scheduling. It's more productive.
452 2016-06-16T19:20:31  <Chris_St1> ^^^
453 2016-06-16T19:20:50  <luke-jr> scheduled releases IMO are great; the only problem I think we're hitting is outside pressure to get specific things in sooner
454 2016-06-16T19:20:57  <wumpus> I do agree CB is still a lot in flux
455 2016-06-16T19:21:12  *** cryptapus has joined #bitcoin-core-dev
456 2016-06-16T19:21:21  <wumpus> which is why I brought up this topic in the first place instead of just merging it
457 2016-06-16T19:22:03  <wumpus> so, ok, let's decide that CB still gets a week to be ready
458 2016-06-16T19:22:15  <gmaxwell> Thank you.
459 2016-06-16T19:22:24  <sdaftuar> sounds good to me.
460 2016-06-16T19:22:25  <btcdrak> great.
461 2016-06-16T19:22:37  <jeremyrubin> wumpus: can you clarify "gets a week" meaning
462 2016-06-16T19:22:42  <sipa> wumpus: ack
463 2016-06-16T19:22:50  <jeremyrubin> i think I am interpreting it as 1 more week till merge
464 2016-06-16T19:22:55  <btcdrak> jeremyrubin: it get's merged next week.
465 2016-06-16T19:22:55  <wumpus> jeremyrubin: can you clarify what is unclear about it?
466 2016-06-16T19:23:11  <achow101> is segwit ready for merging?
467 2016-06-16T19:23:44  <sipa> segwit is ready for merging, though i'd like to get review on the changes made the past few days
468 2016-06-16T19:23:58  <luke-jr> I think it should increase the pkh length limit to 75 bytes, but not important
469 2016-06-16T19:24:01  <wumpus> segwit is also still very much in flux
470 2016-06-16T19:24:03  <jeremyrubin> wumpus: not too much... just a little unclear what the week is for etc
471 2016-06-16T19:24:08  <gmaxwell> the changes were just related to merging it without an activation date, right?
472 2016-06-16T19:24:14  <Frederic94500> Because the last night, there are 40K+ unconfirmed transaction
473 2016-06-16T19:24:15  <wumpus> jeremyrubin: to finish up the pull request so that it can be merged
474 2016-06-16T19:24:18  <sipa> they're mostly making segwit p2p deal correctly with having no activation date
475 2016-06-16T19:24:27  <jeremyrubin> wumpus: but all ok now (I think you missed my second msg)
476 2016-06-16T19:24:29  <sipa> and tests/nots
477 2016-06-16T19:24:32  <luke-jr> Frederic94500: #bitcoin
478 2016-06-16T19:24:33  <sipa> *nits
479 2016-06-16T19:25:00  <btcdrak> and ticks
480 2016-06-16T19:25:02  <gmaxwell> Okay can we move to the next topic?
481 2016-06-16T19:25:07  <wumpus> #topic segwit
482 2016-06-16T19:25:09  <instagibbs> luke-jr, noted, but I think that ship has sailed
483 2016-06-16T19:25:30  <sipa> i don't think there will be any further changes to segwit necessary, apart from potentially making it cooperate with CB
484 2016-06-16T19:26:15  *** raedah has quit IRC
485 2016-06-16T19:26:21  <sipa> we may find some edge cases in the transition between activation date unset and set, which i plan to actively help testing he next few days
486 2016-06-16T19:26:38  <sipa> that is, assuming people find the review and testing it has had so far sufficient
487 2016-06-16T19:26:54  <wumpus> so it would be better to merge segwit *before* CB?
488 2016-06-16T19:27:03  <sipa> i don't care
489 2016-06-16T19:27:15  <sipa> i'll help rebase either one on top of the other
490 2016-06-16T19:27:33  <sipa> sdaftuar: opinion?
491 2016-06-16T19:27:34  <instagibbs> sdaftuar, any outstanding concerns re testing?
492 2016-06-16T19:27:36  *** raedah has joined #bitcoin-core-dev
493 2016-06-16T19:27:40  <wumpus> at the least we need to make sure one of them is merged asap
494 2016-06-16T19:27:44  <wumpus> so the other one can be integrated into it
495 2016-06-16T19:27:46  <instagibbs> wumpus, ACK
496 2016-06-16T19:27:51  <gmaxwell> sipa: if you were to do the rebase which do you think would be less work?  I have a pref for merging segwit first due to review things.  (though I believe we can't set an activation for it without CB)
497 2016-06-16T19:28:10  <sdaftuar> instagibbs: i'm doing testing now for the activation date unset -> set scenario
498 2016-06-16T19:28:19  <sdaftuar> i'd like more eyes on that issue, as it only just came up
499 2016-06-16T19:28:20  <Chris_St1> 'activation' is wrt BIP9 right?
500 2016-06-16T19:28:22  <wumpus> otherwise we'll keep this 'we need to rebase it over X' problem, and integration (and fixing bugs in integration) always causes unexpected issues
501 2016-06-16T19:28:28  <gmaxwell> basically CB is less to review, and fewer have reviewed it, disrupting review with a rebase there is less of an issue.
502 2016-06-16T19:28:33  <luke-jr> merging CB first makes it potentially easier to backport if people want to
503 2016-06-16T19:28:43  <btcdrak> Chris_St1: yes, the parameters for activation on mainnet (starttime, timeout, bit)
504 2016-06-16T19:28:44  <gmaxwell> Chris_St1: BIP9 starting date, yes.
505 2016-06-16T19:28:55  <luke-jr> but if CB needs a week of revisions, merging segwit first might just make more sense
506 2016-06-16T19:28:57  <wumpus> the thing is though: CB is bound by the feature freeze, segwit is not
507 2016-06-16T19:29:03  <luke-jr> especially since segwit needs backports anyway
508 2016-06-16T19:29:03  <gmaxwell> luke-jr: a backport of CB without segwit wouldn't be very interesting in any case.
509 2016-06-16T19:29:17  <jonasschnelli> good point wumpus
510 2016-06-16T19:29:35  <luke-jr> wumpus: it's less important so long as segwit has no mainnet activation params set
511 2016-06-16T19:29:40  <luke-jr> IMO
512 2016-06-16T19:30:09  <wumpus> luke-jr: just need to get the code into master, it's been reviewed and tested so extensively
513 2016-06-16T19:30:45  <gmaxwell> yes the merge there is about code maintance.
514 2016-06-16T19:30:49  <sdaftuar> wumpus: fyi the issue that came up this week about merging with no mainnet activation was a surprise to all of us
515 2016-06-16T19:30:52  <BakSAj> isnt segwit the most reviewed btc code ever?
516 2016-06-16T19:30:53  <instagibbs> sdaftuar, I can take a look too.
517 2016-06-16T19:30:54  <Frederic94500> Actually, there are 13K+ unconfirmed transaction and we need segwit
518 2016-06-16T19:30:57  <sdaftuar> wumpus: i think that particular issue should be thought abou tmore
519 2016-06-16T19:31:01  <sdaftuar> to make sure we haven't missed anything
520 2016-06-16T19:31:02  <sipa> Frederic94500: #bitcoin
521 2016-06-16T19:31:15  <Frederic94500> #bitcoin
522 2016-06-16T19:31:18  *** ChanServ sets mode: +o wumpus
523 2016-06-16T19:31:22  <sdaftuar> sipa: but to answer your question about my opinion, i think i agree it should be fine to merge
524 2016-06-16T19:31:43  <jeremyrubin> Frederic94500: it means move your conversation to that channel as it is off topic here.
525 2016-06-16T19:31:58  <sdaftuar> i will finish my testing/review of the latest changes, and then hopefully ack this week
526 2016-06-16T19:32:02  <sdaftuar> ie today/tomorrow
527 2016-06-16T19:32:26  <Chris_St1> sdaftuar: So BIP9 parameters need to be set in the pull request before being merged into master correct?
528 2016-06-16T19:32:39  <gmaxwell> Chris_St1: no, it can be merged with no starting date set.
529 2016-06-16T19:32:40  <sipa> wumpus: segwit is merged this week or not at all, CB thursday or not at all.
530 2016-06-16T19:32:51  <btcdrak> no. they will bet set later in a seprate pull
531 2016-06-16T19:32:52  <sipa> wumpus: is that acceptable?
532 2016-06-16T19:32:56  <gmaxwell> Which is what will happen for master.
533 2016-06-16T19:33:01  <luke-jr> sipa: next thursday*
534 2016-06-16T19:33:08  <wumpus> sipa: CB needs to be merged before (or on) next week thursday
535 2016-06-16T19:33:14  <wumpus> sipa: segwit doesn't really have  a constraint
536 2016-06-16T19:33:23  <sipa> wumpus: ok
537 2016-06-16T19:33:45  <wumpus> I just thought merging it first was preferable, so that maintenance and testing of it can happen on master
538 2016-06-16T19:33:55  <sipa> yes, i agree
539 2016-06-16T19:34:04  <gmaxwell> I'm really tired of not being able to work on some things due to avoiding disrupting segwit, it'll be good to have it merged.
540 2016-06-16T19:34:07  <gmaxwell> :)
541 2016-06-16T19:34:11  <jonasschnelli> Yes. Merging it before 0.13 would make things more testable/tested
542 2016-06-16T19:34:12  <wumpus> right
543 2016-06-16T19:34:13  <instagibbs> Only a few ACKs so far, start cracking the whip!
544 2016-06-16T19:34:39  <gmaxwell> all my focus is on things that were freeze gated.
545 2016-06-16T19:34:42  <btcdrak> instagibbs: this meeting is one huge ACK :-p
546 2016-06-16T19:34:47  <gmaxwell> (in the last week)
547 2016-06-16T19:34:49  <jonasschnelli> I have reviewed SW for serval hours but I don't feel myself in a position to give a it a utACK (or more)
548 2016-06-16T19:34:58  <sipa> i would also like to point to #8149 for review, where i've reorganized the commits per BIP
549 2016-06-16T19:35:19  <sipa> it may make sense for people to just ack certain sections of it, as it touches many relatively unrelated things
550 2016-06-16T19:35:23  <btcdrak> sipa: is #8149 the version to merge?
551 2016-06-16T19:35:39  <sipa> (testing, wallet, p2p, consensus, script)
552 2016-06-16T19:35:44  <sipa> btcdrak: yes
553 2016-06-16T19:35:52  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8149 for review with reorganized commits per BIP
554 2016-06-16T19:35:56  <gmaxwell> I really like the ordering of 8149, FWIW.
555 2016-06-16T19:36:06  <instagibbs> jonasschnelli, just pick a part you can review comfortably
556 2016-06-16T19:36:28  <sipa> and don't look at the commit by github; there is a summary comment with a list of all commits organized per section
557 2016-06-16T19:36:32  <sipa> which i keep up to date
558 2016-06-16T19:36:46  <jeremyrubin> sipa: thank you it's much easier to review
559 2016-06-16T19:37:41  <sipa> ok, any other topics?
560 2016-06-16T19:37:52  <jeremyrubin> yes
561 2016-06-16T19:38:02  <wumpus> jonasschnelli had one
562 2016-06-16T19:38:06  <jeremyrubin> I'd like to briefly call for more review on cory's cconman
563 2016-06-16T19:38:08  <jeremyrubin> refctor
564 2016-06-16T19:38:17  <sipa> jeremyrubin: i will, but after 0.13
565 2016-06-16T19:38:18  <jonasschnelli> I think we should have a replacement option for the wallet in 0.13
566 2016-06-16T19:38:21  <wumpus> #topic replacements (RBF/bumpfee) in 0.13
567 2016-06-16T19:38:29  <sipa> ack topic
568 2016-06-16T19:38:34  <wumpus> jeremyrubin: when Cory is back
569 2016-06-16T19:38:54  <instagibbs> cory is answering pr stuff now, but I think he's not supposed to be :)
570 2016-06-16T19:38:56  <jonasschnelli> Also,... what happens if users start up a node and immediately send a tx?
571 2016-06-16T19:39:01  <gmaxwell> am I missing something in thinking thats post 0.13 work now?
572 2016-06-16T19:39:04  <wumpus> oh, more review, yes that's always good, although peopel are very busy with pre-0.13 issues now
573 2016-06-16T19:39:06  <luke-jr> cfields_:
574 2016-06-16T19:39:08  <gmaxwell> (the conman stuff)
575 2016-06-16T19:39:10  <wumpus> gmaxwell: yes
576 2016-06-16T19:39:21  <wumpus> gmaxwell: I mena, no, you're not missing anything
577 2016-06-16T19:39:25  <gmaxwell> Thanks. whew.
578 2016-06-16T19:39:34  <sipa> i'd to see conman go in right after 0.13 branch off
579 2016-06-16T19:39:42  <sdaftuar> jonasschnelli: are you talking about how fee estimation should work in that case?
580 2016-06-16T19:39:46  <sipa> *conmann
581 2016-06-16T19:39:47  <gmaxwell> jeremyrubin: thats why there isn't attention on it right at this second (also because cory is out)
582 2016-06-16T19:39:47  <jonasschnelli> Review of https://github.com/bitcoin/bitcoin/pull/8182 would be nice. Its a bumpfee command for GUI only.
583 2016-06-16T19:39:51  <wumpus> sipa: +1
584 2016-06-16T19:39:54  <jonasschnelli> sdaftuar: yes
585 2016-06-16T19:39:57  <jeremyrubin> gmaxwell: he's been responsive
586 2016-06-16T19:40:09  <jeremyrubin> gmaxwell: but maybe let him relax a bit
587 2016-06-16T19:40:11  <petertodd> jonasschnelli: yeah, my apologies for not having already looked at that!
588 2016-06-16T19:40:14  <sipa> doesn't matter, there is no benefit in merging conman before the branch
589 2016-06-16T19:40:16  <gmaxwell> jeremyrubin: I want that too. Well, I really want the sequence setting parts and fee even on the bump parts.
590 2016-06-16T19:40:27  <luke-jr> jonasschnelli: I don't think "signals replaceability" is very useful
591 2016-06-16T19:40:46  <luke-jr> "Enable fee bumping" would make more sense
592 2016-06-16T19:40:52  <gmaxwell> er s/fee even/feel 50/50 on the bump parts/
593 2016-06-16T19:40:59  <jeremyrubin> I brought it up not for the 0.13 but because it seemed like we were out of topics so I raised it, no need to address further.
594 2016-06-16T19:41:06  <sipa> ok
595 2016-06-16T19:41:12  <jonasschnelli> luke-jr: you mean the text comment in the transaction details? Whats wrong with it. IMO we agreed on that term in a recent meeting.
596 2016-06-16T19:41:17  <luke-jr> right
597 2016-06-16T19:41:31  <gmaxwell> thats nits, can be worked out on the PR or out of meeting.
598 2016-06-16T19:41:42  <gmaxwell> please don't go into field naming details here. :)
599 2016-06-16T19:41:42  <luke-jr> k
600 2016-06-16T19:41:48  <phantomcircuit> jonasschnelli, maybe this is just me, but i generally much prefer that things be added to the cli before the gui
601 2016-06-16T19:41:50  <wumpus> nits shouldn't be a reason to hold up the feature merge
602 2016-06-16T19:41:52  <jonasschnelli> Agree. The question is do we want a feebump option in 0.13...
603 2016-06-16T19:41:58  <jonasschnelli> if so,.. its extermly late. :)
604 2016-06-16T19:42:01  <phantomcircuit> makes the initial review much easier for the feature itself
605 2016-06-16T19:42:18  <gmaxwell> So I think we really should have the sequence setting stuff, I kept trying to ack the prior PRs but they've been closed for new prs several times.
606 2016-06-16T19:42:20  <jonasschnelli> phantomcircuit: there is also a CLI PR. :)
607 2016-06-16T19:42:26  <wumpus> jonasschnelli: especially for the GUI isn't [retty much too late
608 2016-06-16T19:42:33  <wumpus> jonasschnelli: as it adds new translation strings
609 2016-06-16T19:42:45  <wumpus> translation for 0.13 already started a few weeks ago
610 2016-06-16T19:42:57  <sipa> that's sad, but understandable
611 2016-06-16T19:42:58  <jonasschnelli> Yes. I agree. But I just think option to increase fees for 0.14 is to late..
612 2016-06-16T19:43:01  <achow101> I think the fee bump stuff should definitely be in 0.13
613 2016-06-16T19:43:03  <wumpus> having the CLI option would make sense though
614 2016-06-16T19:43:06  <gmaxwell> jonasschnelli: where did we land with bumping interacting with the changs outputs already having been spent?
615 2016-06-16T19:43:11  *** Sosumi has quit IRC
616 2016-06-16T19:43:20  <gmaxwell> achow101: I want a pony.
617 2016-06-16T19:43:36  <wumpus> achow101: 'should', but there's preactical issues with timing and planning we're trying to cope with here
618 2016-06-16T19:43:36  * btcdrak gives gmaxwell a pony
619 2016-06-16T19:43:38  <phantomcircuit> jonasschnelli, 0.13.1 ?
620 2016-06-16T19:43:38  <sipa> achow101: i think we all like that, but we can't bypass safe practices for review and testing because we want it
621 2016-06-16T19:43:42  <phantomcircuit> it's a minor feature
622 2016-06-16T19:43:56  <jonasschnelli> Not sure if we want BP a bumpfeature...
623 2016-06-16T19:44:14  <sipa> BP?
624 2016-06-16T19:44:17  <jonasschnelli> backport
625 2016-06-16T19:44:22  <wumpus> to be honest I think getting CB and segwit is enough worry for next week
626 2016-06-16T19:44:36  <jonasschnelli> yes... agree.
627 2016-06-16T19:44:58  <jonasschnelli> Although it's a triangle. CB <-> SW <-> RBF
628 2016-06-16T19:45:00  *** Chris_St1 has quit IRC
629 2016-06-16T19:45:16  <petertodd> so, I'd strongly suggest we at least get in my global optin setting, so that people who need RBF can easily use external scripts to do so: https://github.com/bitcoin/bitcoin/pull/7132
630 2016-06-16T19:45:18  <wumpus> it's unfortunate that your PRs with feebump got little attention, but it's kind of late now, we can't just cram everything in last minute
631 2016-06-16T19:45:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
632 2016-06-16T19:45:32  <jonasschnelli> wumpus: Agree.
633 2016-06-16T19:45:48  <wumpus> in any case: RPC functionality must be in before the GUI
634 2016-06-16T19:45:50  <Chris_Stewart_5> Did we figure the ordering for those merges?
635 2016-06-16T19:45:50  <jonasschnelli> My feeling is that it is too late for 0.13 and I just wanted to make this clear. :)
636 2016-06-16T19:45:55  <instagibbs> petertodd, I agree with this
637 2016-06-16T19:45:56  <sipa> i will focus on reviewing RPC bumpfee
638 2016-06-16T19:45:56  <wumpus> that's always how we work
639 2016-06-16T19:46:00  <gmaxwell> wumpus: could we split the sequence setting parts and do those? I think they're simple and not risky and have been reviewed under several PRs.
640 2016-06-16T19:46:08  <Chris_Stewart_5> segwit -> CB or CB -> segwit?
641 2016-06-16T19:46:13  <gmaxwell> The issue for them is that those PRs kept getting closed with changing scope.
642 2016-06-16T19:46:19  <wumpus> gmaxwell: sounds good to me
643 2016-06-16T19:47:01  <gmaxwell> Chris_Stewart_5: we'll see how it goes with the actual timing of the changes.
644 2016-06-16T19:47:02  <luke-jr> suggested topic: how should GBT react to pre-segwit miners, once segwit activates?
645 2016-06-16T19:47:04  <wumpus> make sure the API is extensible enough to add the other things so we don't need to deprecate it already next version
646 2016-06-16T19:47:07  <gmaxwell> Chris_Stewart_5: we don't need to decide that now.
647 2016-06-16T19:47:15  <wumpus> but that's arguably a minor concern
648 2016-06-16T19:47:37  <gmaxwell> luke-jr: what does it do in the current implementation?
649 2016-06-16T19:47:44  <Chris_Stewart_5> gmaxwell: Also, these are BOTH to be included before the feature freeze, correct? Or is that tbd
650 2016-06-16T19:47:50  <Chris_Stewart_5> to be determined*
651 2016-06-16T19:48:02  <wumpus> Chris_Stewart_5: no, CB needs to be in before the feature freeze, softforks can in principle go in any time
652 2016-06-16T19:48:17  <gmaxwell> Chris_Stewart_5: SW is freeze unrelated, CB has another week to mature.
653 2016-06-16T19:48:17  <luke-jr> gmaxwell: just errors
654 2016-06-16T19:48:30  <sipa> luke-jr: what is the alternative?
655 2016-06-16T19:48:32  <luke-jr> gmaxwell: the RPC call errors, that is. so the miner will failover or stop
656 2016-06-16T19:48:42  <luke-jr> sipa: mine blocks without any witness transactions
657 2016-06-16T19:49:02  <gmaxwell> Chris_Stewart_5: question might suggest a misunderstanding, SW merge for master is not tightly coupled to deployment; it's mostly a discussion of code management.
658 2016-06-16T19:49:18  <sipa> luke-jr: that means mining on top of a chain they have not fully validated
659 2016-06-16T19:49:23  <sipa> oh, no, they have
660 2016-06-16T19:49:24  <sipa> sorry
661 2016-06-16T19:49:28  <luke-jr> sipa: no, the bitcoind is updated, just not the miner
662 2016-06-16T19:49:30  <sipa> i'm confusing client and server
663 2016-06-16T19:49:48  <gmaxwell> luke-jr: might be better to return an empty block, if the implementation would be simple.
664 2016-06-16T19:50:08  <gmaxwell> the failover might just cause it to fail over to something even stupider.
665 2016-06-16T19:50:16  <btcdrak> Chris_Stewart_5: the lifecycle page got updated to clarify some of this https://bitcoincore.org/en/lifecycle/
666 2016-06-16T19:50:17  <sdaftuar> presumably this is not a feature that there can possibly be a lot of demand for.  is it relaly worth the trouble?
667 2016-06-16T19:50:17  <luke-jr> I guess that's another option, but empty block is :<
668 2016-06-16T19:50:23  <wumpus> consensus changes are not on bitcoin core's major release schedule, the first release introducing segwit would ideally be 0.12.x
669 2016-06-16T19:50:44  <Chris_Stewart_5> gmaxwell: I guess it seems CB from my understanding isn't tightly coupled to deployment either since I'm assuming old block relay code will still be in core? I'll ask more questions after meeting..
670 2016-06-16T19:50:46  <wumpus> but that doesn't mean segwit code can't be merged (just not activated) in 0.13
671 2016-06-16T19:50:59  <luke-jr> gmaxwell: concern with non-witness template being code complexity, I guess?
672 2016-06-16T19:51:20  <sipa> i prefer empty block
673 2016-06-16T19:51:21  <luke-jr> I suppose empty blocks are also more likely to get noticed and upgraded
674 2016-06-16T19:51:30  <gmaxwell> luke-jr: just more features to test when hopefully thats just an emergency fallback.
675 2016-06-16T19:51:34  <sdaftuar> throwing an error should get noticed very fast
676 2016-06-16T19:51:42  <wumpus> Chris_Stewart_5: the old relay code will still be used in most cases, like with peers that don't support CB
677 2016-06-16T19:51:54  <gmaxwell> sdaftuar: error will result in failover to another daemon, perhaps without segwit support, which is somewhat less desirable. :)
678 2016-06-16T19:51:58  <Chris_Stewart_5> btcdrak: Thanks
679 2016-06-16T19:52:15  <sdaftuar> little known fact: those blocks will be orphaned,  that should also get noticed!
680 2016-06-16T19:52:17  <petertodd> ack empty blocks - that's a reasonable failsafe in a lot of conditions in general
681 2016-06-16T19:52:23  <luke-jr> sdaftuar: they won't, though
682 2016-06-16T19:52:26  <gmaxwell> I think error and empty are both acceptable, with a small preference for empty that would be overridden if i find out the implementation is more than about 4 lines of code.
683 2016-06-16T19:52:28  <sdaftuar> they won't relay
684 2016-06-16T19:52:32  <luke-jr> sdaftuar: they're valid
685 2016-06-16T19:52:34  <sdaftuar> yes
686 2016-06-16T19:52:36  <sdaftuar> but they won't relay
687 2016-06-16T19:52:38  <luke-jr> …
688 2016-06-16T19:52:41  <luke-jr> why not?
689 2016-06-16T19:52:41  <sdaftuar> hence, little known fact
690 2016-06-16T19:52:57  <gmaxwell> ah, well if they won't realy, okay, well no reason to not error then.
691 2016-06-16T19:53:03  <sipa> why would they not relay?
692 2016-06-16T19:53:05  <sdaftuar> segwit nodes will try to download blocks from WITNESS peers
693 2016-06-16T19:53:13  <sdaftuar> after activation
694 2016-06-16T19:53:14  <sipa> so, this is a witness peer
695 2016-06-16T19:53:17  <luke-jr> ^
696 2016-06-16T19:53:19  <sdaftuar> not if it fails over
697 2016-06-16T19:53:19  <sipa> just not a witness miner
698 2016-06-16T19:53:24  <luke-jr> hm
699 2016-06-16T19:53:38  <sipa> oh, i see what you're saying
700 2016-06-16T19:53:39  <sdaftuar> sorry i was responding to gmaxwell's failover to an old daemon
701 2016-06-16T19:53:44  <sipa> so, failover seems sufficient
702 2016-06-16T19:53:45  <gmaxwell> sdaftuar: this is a witness node, but asking what happens when a non-sw hasher connects.
703 2016-06-16T19:53:52  <gmaxwell> sdaftuar: OH!
704 2016-06-16T19:54:00  <gmaxwell> well okay, that would get noticed too.
705 2016-06-16T19:54:08  <luke-jr> yeah, I think this makes error the better behaviour
706 2016-06-16T19:54:18  <gmaxwell> still, the crap blocks produced would be noise to non-upgraded nodes.
707 2016-06-16T19:54:19  <petertodd> wait, did or didn't we remove the code that used to push new blocks to peers?
708 2016-06-16T19:54:42  <sdaftuar> technically, mining a non-witness block on an upgraded peer would relay, as per sipa's suggestion to mine an empty block
709 2016-06-16T19:54:48  <sdaftuar> i just don't think it's worth the trouble to code that up
710 2016-06-16T19:55:03  <luke-jr> oh
711 2016-06-16T19:55:20  <sdaftuar> code up/test/review
712 2016-06-16T19:55:21  <sdaftuar> etc
713 2016-06-16T19:55:31  <luke-jr> BFGMiner at least WILL submit blocks to local bitcoind regardless of what pool mined them, BUT it can only do that with GBT pools, and frankly nobody uses that
714 2016-06-16T19:55:48  <luke-jr> so probably not worth considering IMO
715 2016-06-16T19:55:58  <sipa> i think we're good
716 2016-06-16T19:56:06  <gmaxwell> K
717 2016-06-16T19:56:08  <sipa> unless miners complain about the behaviour
718 2016-06-16T19:56:13  <sipa> then wr can reconsider
719 2016-06-16T19:56:16  <sdaftuar> sounds good
720 2016-06-16T19:56:43  <wumpus> three minutes to go!
721 2016-06-16T19:56:48  <gmaxwell> jonasschnelli: if you split that PR I will go ack the non-bump part super fast.
722 2016-06-16T19:56:53  <petertodd> also, if a block is relayed to non-witness peers, we only need one node on the network to bridge that gap...
723 2016-06-16T19:57:07  <sipa> agree
724 2016-06-16T19:57:15  <jonasschnelli> gmaxwell: which one?
725 2016-06-16T19:57:23  <sipa> which their private infrastructure may do unknowlingly
726 2016-06-16T19:57:27  <gmaxwell> jonasschnelli: the bump fee PR.
727 2016-06-16T19:57:39  <luke-jr> petertodd: we don't *want* to bridge that gap, but I guess that's your point
728 2016-06-16T19:57:44  <luke-jr> any malicious actor could do it
729 2016-06-16T19:57:56  *** cryptapus has quit IRC
730 2016-06-16T19:58:09  <petertodd> luke-jr: having consensus depend on nuances of network behavior is icky...
731 2016-06-16T19:58:15  <luke-jr> but on the other hand, these blocks are only defective in being not fully verified parents, which won't affect full nodes
732 2016-06-16T19:58:20  <gmaxwell> jonasschnelli: the actual bumping reqiures review and testing for that I don't think we have time for pre-freeze regretable, but the rest (setting the sequence numbers and what not) is fine, and I've already reviewed it and tested it.
733 2016-06-16T19:58:27  <luke-jr> so this can only be done for valid blocks anyway
734 2016-06-16T19:58:45  <jonasschnelli> gmaxwell: okay. I'll try to factor this out in an independent PR
735 2016-06-16T19:59:08  <instagibbs> 1 minute
736 2016-06-16T19:59:30  <petertodd> instagibbs: hopefully we land on the drone ship this time
737 2016-06-16T19:59:34  <luke-jr> petertodd: consensus doesn't depend on it, just a slightly higher risk miners don't upgrade their nodes
738 2016-06-16T19:59:36  <phantomcircuit> sdaftuar, it should be only a few lines of code to simply not include any transactions which have witness data
739 2016-06-16T19:59:39  <gmaxwell> (also, in general, layering in seperate PRs RPC and GUI is useful, since we're usually more eager about merging rpc features-- easier to test, more sophicated users)
740 2016-06-16T19:59:59  * wumpus turns off thel lights
741 2016-06-16T20:00:03  <wumpus> #endmeeting
742 2016-06-16T20:00:03  <lightningbot> Meeting ended Thu Jun 16 20:00:03 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
743 2016-06-16T20:00:03  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-16-19.00.html
744 2016-06-16T20:00:03  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-16-19.00.txt
745 2016-06-16T20:00:03  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-16-19.00.log.html
746 2016-06-16T20:00:05  <sipa> phantomcircuit: there are 3 transaction selection algorithms now
747 2016-06-16T20:00:23  <sdaftuar> phantomcircuit: i agree, but this should not be anyone's priority
748 2016-06-16T20:00:51  <Chris_Stewart_5> wumpus: CB needs to be merged in before 0.13 because the protocol version in the version message indicates nodes need to talk using CB?
749 2016-06-16T20:00:57  <luke-jr> petertodd: I do think you've convinced me that maybe the empty-block behaviour is better again though.
750 2016-06-16T20:01:00  <petertodd> luke-jr: by "depends" I just mean the outcome of the consensus protocol is strongly affected by that nuance, in that case
751 2016-06-16T20:01:29  <petertodd> luke-jr: so in general, we're better off having an empty blockchain with everyone's funds frozen than other possible failure modes
752 2016-06-16T20:01:41  <gmaxwell> Chris_Stewart_5: hm? no unrelated. The issue is that if it isn't merged it would slip by something like a half year, which would be kinda dumb because the protocol is dumb.
753 2016-06-16T20:01:59  <BakSAj> what is the meeting result on merging segwit? tnx
754 2016-06-16T20:02:07  <petertodd> luke-jr: empty blocks work towards that goal
755 2016-06-16T20:02:46  <Chris_Stewart_5> gmaxwell: Is this because of the release policy we have come up with or something inherent to the protocol itself? I guess I'm missing the limitation for not being able to put this out in a minor..
756 2016-06-16T20:02:57  <wumpus> Chris_Stewart_5: it doesn't *need* to be merged before 0.13, we could postpone it to 0.14
757 2016-06-16T20:03:15  <wumpus> Chris_Stewart_5: but because it is such a useful feature everyone really wants it in 0.13
758 2016-06-16T20:03:22  <petertodd> though systems like Lightning are an annoying counterexample to the "empty blocks are safe" assumption...
759 2016-06-16T20:03:35  <gmaxwell> Chris_Stewart_5: there is nothing about the protocol being discussed today, this is all project management.
760 2016-06-16T20:03:48  <Chris_Stewart_5> gotcha.
761 2016-06-16T20:04:12  <wumpus> Chris_Stewart_5: also, because of bandwidth reasons people want CB with segwit
762 2016-06-16T20:04:37  <luke-jr> does segwit currently fetch the whole block in one chunk, or stripped + witness separately?
763 2016-06-16T20:05:03  <sipa> the whole block
764 2016-06-16T20:05:14  <gmaxwell> luke-jr: there is no seperate thing, it's just a block and you seralize it with or without the witness.
765 2016-06-16T20:05:33  <wumpus> also CB is pretty much ready, it hasbeen tested extensively, and reviewed quite well, as I see it there are just some last nits
766 2016-06-16T20:05:40  <GreenIsMyPepper> petertodd: w/r/t Lightning, i think with CSV, should be OK. transactions in-flight should be biased towards smaller values in the near term for the hard CLTV deadlines so impact for straight payments with empty blocks should be minimal but i'm not 100% sure
767 2016-06-16T20:05:43  <luke-jr> gmaxwell: oh, it's not even supported to fetch just the witness data? :/  would be nice for nodes that skip it and go back and check later
768 2016-06-16T20:05:47  <luke-jr> oh well, future improvements
769 2016-06-16T20:06:11  <sipa> luke-jr: indeed, that may be something useful to add at some point
770 2016-06-16T20:06:20  <wumpus> no scope creep please :)
771 2016-06-16T20:06:30  <instagibbs> action item: creep the scope
772 2016-06-16T20:06:37  <luke-jr> CB changes things too much to consider it now anyway
773 2016-06-16T20:06:45  <gmaxwell> fortunately the meeting is over so we don't have to take instagibbs' action.
774 2016-06-16T20:07:26  <luke-jr> I think for L1 consensus, we probably want to bridge the old-node valid blocks to the main network :/  which means we might want GBT to do empty blocks for old miners
775 2016-06-16T20:07:28  <wumpus> topic for next meeting :p
776 2016-06-16T20:07:31  <gmaxwell> luke-jr: really that kind of multistage sync is something independant of SW; it's just that it could be more efficient with segwit.
777 2016-06-16T20:07:38  <luke-jr> gmaxwell: right
778 2016-06-16T20:08:57  <petertodd> GreenIsMyPepper: it's ok for a bit, but given a sufficiently long period of empty blocks being mined eventually lightning users are really screwed over; that's not true for other ways of using Bitcoin
779 2016-06-16T20:09:13  <petertodd> GreenIsMyPepper: not necessarily a problem in practice, but it's worth considering
780 2016-06-16T20:09:35  *** BakSAj has quit IRC
781 2016-06-16T20:09:57  <luke-jr> sipa: is it trivial to configure a node to fetch and process blocks from old nodes?
782 2016-06-16T20:10:01  <gmaxwell> Chris_Stewart_5: going back to your earlier comments, per the lifecycle, changes for network consensus exist outside of the bitcoin core release cycle,  the reason we're talking about segwit merge in master here is not so much related to deploying segwit in the network, but related to managing the code implementing segwit in core as part of master. This is important to us because of the overhead
783 2016-06-16T20:10:07  <gmaxwell> s related to keeping it as a patch in flight.
784 2016-06-16T20:10:10  <GreenIsMyPepper> petertodd: yes, i agree, esp for time-dependent aspects during the switchover from mining->empty
785 2016-06-16T20:10:29  <gmaxwell> Chris_Stewart_5: generally a consensus rule change will show up in a point release, not in a new major release (though it might also be in the new major release in parallel)
786 2016-06-16T20:10:37  <sipa> luke-jr: what do you mean?
787 2016-06-16T20:11:00  <luke-jr> sipa: get a new node which downloads blocks from pre-segwit nodes, and relays them to the main/segwit nodes.
788 2016-06-16T20:11:07  <petertodd> GreenIsMyPepper: yeah, the tl;dr: is Lightning means if Bitcoin breaks, we have deadlines to fix it or all hell breaks loose
789 2016-06-16T20:11:10  <luke-jr> provided the block is valid without witness data
790 2016-06-16T20:11:39  <gmaxwell> Chris_Stewart_5: also consenus changes in core are often merged without any activation. (or in some cases with no nearterm plans to activate.. like the low-S signature stuff.)
791 2016-06-16T20:11:45  <luke-jr> petertodd: softfork sequence stuff to skip empty blocks
792 2016-06-16T20:11:59  <sipa> luke-jr: sounds trivial, just disable that check
793 2016-06-16T20:12:00  <petertodd> luke-jr: that's not a crazy idea
794 2016-06-16T20:12:13  <luke-jr> petertodd: it's not a new idea either :P:
795 2016-06-16T20:12:24  <luke-jr> empty blocks are just full blocks with a soft size limit of 0
796 2016-06-16T20:12:27  <petertodd> luke-jr: it's so not crazy, multiple people have proposed it :)
797 2016-06-16T20:12:37  <GreenIsMyPepper> petertodd: additionally, i think the 2016-block mining retargeting point is an interesting factor to consider with second-order effects/drivers
798 2016-06-16T20:12:51  <GreenIsMyPepper> when talking about stopping vs. empty
799 2016-06-16T20:12:56  <petertodd> GreenIsMyPepper: how so?
800 2016-06-16T20:13:59  <GreenIsMyPepper> in the sense that if the default was to stop, to encourage time for development, there's still a hard deadline of block retarget from part of the hashpower still mining
801 2016-06-16T20:14:17  <GreenIsMyPepper> still mining for one reason or another
802 2016-06-16T20:14:22  <sipa> luke-jr: all you need is one witness-capable node that attempts to download from its non-witness peers
803 2016-06-16T20:14:37  <luke-jr> sipa: what's the segwit branch I should work on top of, for adding GBT old-miner empty block stuff?
804 2016-06-16T20:14:47  <petertodd> GreenIsMyPepper: oh, nah, I was only talking about cases where ~all miners are mining empty blocks due to some kind of failure mode
805 2016-06-16T20:14:57  <GreenIsMyPepper> which I suspect may affect default selection of CSV timeouts
806 2016-06-16T20:15:05  <sipa> luke-jr: segwit-master or segwit-master2 (they are identical apart from commit structure)
807 2016-06-16T20:15:19  <GreenIsMyPepper> ah, i see, i was thinking of different problems. yeah in that case, if you presume that as a "backup feature" then yes that would be impacted, that's a very good point!
808 2016-06-16T20:15:25  <gmaxwell> GreenIsMyPepper: BIP-68 was setup so there could be other kinds of CSV counters in the future pretty easily.
809 2016-06-16T20:16:36  <GreenIsMyPepper> yeah, not sure whether you could sufficiently punt the problem via only "don't count if the blocks are empty", but this is veering into -wizards territory :P
810 2016-06-16T20:16:44  <gmaxwell> (so, e.g. when it's clear thats whats wanted, one that counted in terms of confirmed transactions could be done.)
811 2016-06-16T20:17:02  *** laurentmt has joined #bitcoin-core-dev
812 2016-06-16T20:17:32  <luke-jr> gmaxwell: empty block mining will be more than 4 lines.
813 2016-06-16T20:18:28  <luke-jr> possibly quite a lot, due to code movement (we populate "transactions" before checking deployments)
814 2016-06-16T20:19:01  *** raedah has quit IRC
815 2016-06-16T20:20:30  *** raedah has joined #bitcoin-core-dev
816 2016-06-16T20:20:59  <Chris_Stewart_5> gmaxwell: Thanks for the explanation
817 2016-06-16T20:22:32  <phantomcircuit> luke-jr, select them and... dont use them
818 2016-06-16T20:22:34  *** frankenmint has quit IRC
819 2016-06-16T20:26:37  <luke-jr> http://codepad.org/t97X9nU3 is a bit ugly, but *might* work   1 file changed, 9 insertions(+), 2 deletions(-)
820 2016-06-16T20:27:06  *** frankenmint has joined #bitcoin-core-dev
821 2016-06-16T20:27:31  <luke-jr> note that we cannot modify the value inside pblock, as it is cached for (potentially segwit) future GBT calls
822 2016-06-16T20:28:16  <luke-jr> thoughts?
823 2016-06-16T20:28:36  *** Frederic94500 has quit IRC
824 2016-06-16T20:30:05  <sipa> luke-jr: why do you need to do that?
825 2016-06-16T20:30:41  <luke-jr> sipa: this would avoid old miners failing over to possibly pre-segwit pools.
826 2016-06-16T20:31:11  <sipa> just give a new on-the-fly constructed empty result
827 2016-06-16T20:31:18  <sipa> instead of using the cached value
828 2016-06-16T20:31:32  <gmaxwell> thats what phantomcircuit was saying.
829 2016-06-16T20:31:38  <luke-jr> that's essentially what this is doing?
830 2016-06-16T20:32:04  <luke-jr> just adds a few lines of code to add a variable and use it
831 2016-06-16T20:32:04  <sipa> then why do you need to modify the cached value?
832 2016-06-16T20:32:12  <luke-jr> I don't, I'm explaining why not.
833 2016-06-16T20:33:46  <sipa> oh, i missed part of the conversation
834 2016-06-16T20:33:48  <sipa> apologies
835 2016-06-16T20:34:01  <phantomcircuit> sipa, i don't believe this is modifying the cached value
836 2016-06-16T20:34:04  <phantomcircuit> it seems reasonable
837 2016-06-16T20:34:14  <luke-jr> np
838 2016-06-16T20:34:58  <sipa> luke-jr: can't this be generically applied to all non-force deployments?
839 2016-06-16T20:35:33  <luke-jr> depends on the deployment.
840 2016-06-16T20:35:42  <luke-jr> I don't see any reason we can assume it will be.
841 2016-06-16T20:35:45  <sipa> or make the force field a tristate "no you can't use this without understanding", "you can make empty blocks without understanding", "yes you can always use this"
842 2016-06-16T20:36:02  <luke-jr> not sure it's worth that until we have both kinds
843 2016-06-16T20:38:48  <sipa> we only have two kinds now
844 2016-06-16T20:39:06  <luke-jr> shall I remove the segwit conditional?
845 2016-06-16T20:43:56  <luke-jr> eg http://codepad.org/gxEaJQpi
846 2016-06-16T20:44:10  <sipa> sounds good; you probably want to add a comment to the force field to explain that it implies an empty block will be produced
847 2016-06-16T20:44:48  *** laurentmt has quit IRC
848 2016-06-16T20:44:55  <sipa> what is the "unsupported" you report?
849 2016-06-16T20:45:33  *** cryptapus has joined #bitcoin-core-dev
850 2016-06-16T20:46:02  <luke-jr> http://codepad.org/QSnQQRD6
851 2016-06-16T20:46:18  <luke-jr> sipa: something to trigger BIP9-aware clients not to try merging the template
852 2016-06-16T20:46:47  <luke-jr> ie, "rules":["unsupported","csv"]
853 2016-06-16T20:47:23  <sipa> he, ok
854 2016-06-16T20:47:29  <luke-jr> (how do I improve the comments on this?)
855 2016-06-16T20:47:44  <sipa> is there any software in the real world that actually does such merging?
856 2016-06-16T20:47:48  <sipa> anyway, does not hurt
857 2016-06-16T20:48:24  <luke-jr> sipa: there is a fork of libblkmaker, not merged with BIP 9 code; but nothing uses it AFAIK
858 2016-06-16T21:04:16  *** cryptapus has quit IRC
859 2016-06-16T21:06:25  *** jannes has quit IRC
860 2016-06-16T21:08:36  *** cryptapus has joined #bitcoin-core-dev
861 2016-06-16T21:11:26  *** zooko has joined #bitcoin-core-dev
862 2016-06-16T21:13:35  *** Chris_Stewart_5 has quit IRC
863 2016-06-16T21:20:05  *** cryptapus has quit IRC
864 2016-06-16T21:22:24  *** cryptapus has joined #bitcoin-core-dev
865 2016-06-16T21:25:42  *** cryptapus has quit IRC
866 2016-06-16T21:29:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
867 2016-06-16T21:41:17  *** frankenmint has quit IRC
868 2016-06-16T22:11:13  *** frankenmint has joined #bitcoin-core-dev
869 2016-06-16T22:24:36  *** frankenmint has quit IRC
870 2016-06-16T22:26:04  *** JackH has quit IRC
871 2016-06-16T22:30:34  *** frankenmint has joined #bitcoin-core-dev
872 2016-06-16T22:32:08  *** zooko has quit IRC
873 2016-06-16T22:44:27  *** Kexkey has joined #bitcoin-core-dev
874 2016-06-16T22:44:43  *** cryptapus has joined #bitcoin-core-dev
875 2016-06-16T22:44:43  *** cryptapus has joined #bitcoin-core-dev
876 2016-06-16T22:45:52  *** ennui has quit IRC
877 2016-06-16T22:46:11  *** cryptapus has quit IRC
878 2016-06-16T22:46:38  *** cryptapus has joined #bitcoin-core-dev
879 2016-06-16T22:52:50  *** cryptapus has quit IRC
880 2016-06-16T22:53:27  *** cryptapus has joined #bitcoin-core-dev
881 2016-06-16T22:58:26  *** cryptapus has quit IRC
882 2016-06-16T23:02:00  *** frankenmint has quit IRC
883 2016-06-16T23:03:38  *** frankenmint has joined #bitcoin-core-dev
884 2016-06-16T23:19:11  *** skyraider has joined #bitcoin-core-dev
885 2016-06-16T23:25:01  *** Kexkey has quit IRC
886 2016-06-16T23:25:51  *** go111111111 has joined #bitcoin-core-dev
887 2016-06-16T23:37:19  *** murch has quit IRC
888 2016-06-16T23:37:58  *** xiangfu has joined #bitcoin-core-dev