1 2016-07-21T00:02:17  *** jiggalator has joined #bitcoin-core-dev
  2 2016-07-21T00:13:28  *** belcher has quit IRC
  3 2016-07-21T00:23:22  *** alpalp has quit IRC
  4 2016-07-21T00:34:45  *** jiggalator is now known as netsin
  5 2016-07-21T00:35:35  *** fengling has joined #bitcoin-core-dev
  6 2016-07-21T00:35:51  <phantomcircuit> jonasschnelli, can you check 8152 again
  7 2016-07-21T00:40:06  *** fengling has quit IRC
  8 2016-07-21T00:42:55  *** fengling has joined #bitcoin-core-dev
  9 2016-07-21T00:45:56  *** alpalp has joined #bitcoin-core-dev
 10 2016-07-21T00:45:56  *** alpalp has joined #bitcoin-core-dev
 11 2016-07-21T00:59:41  <PRab> Is there a way to have github notify you when there is a new tag?
 12 2016-07-21T01:00:54  <PRab> nm, I should know to google first.
 13 2016-07-21T01:00:59  <PRab> https://github.com/bitcoin/bitcoin/tags.atom works
 14 2016-07-21T01:03:08  *** CubicEarth has joined #bitcoin-core-dev
 15 2016-07-21T01:05:14  *** frankenmint has quit IRC
 16 2016-07-21T01:05:30  *** netsin has quit IRC
 17 2016-07-21T01:08:25  *** alpalp has quit IRC
 18 2016-07-21T01:09:51  *** netsin has joined #bitcoin-core-dev
 19 2016-07-21T01:15:35  <PRab> Testing 0.13.0rc1 from my gitian build. Looks like it upgraded smoothly from 0.12.1 and is working properly for me (Win7 64bit).
 20 2016-07-21T01:15:48  *** Ylbam has quit IRC
 21 2016-07-21T01:16:37  *** netsin has quit IRC
 22 2016-07-21T01:24:08  *** JackH has quit IRC
 23 2016-07-21T01:24:36  *** AaronvanW has quit IRC
 24 2016-07-21T01:31:02  *** Giszmo has joined #bitcoin-core-dev
 25 2016-07-21T01:34:04  *** Giszmo1 has quit IRC
 26 2016-07-21T01:40:34  *** alpalp has joined #bitcoin-core-dev
 27 2016-07-21T01:40:35  *** alpalp has joined #bitcoin-core-dev
 28 2016-07-21T01:54:18  *** jtimon has quit IRC
 29 2016-07-21T01:54:19  *** davec has quit IRC
 30 2016-07-21T01:54:58  *** davec has joined #bitcoin-core-dev
 31 2016-07-21T01:56:46  *** fengling has quit IRC
 32 2016-07-21T01:56:54  *** fengling_ has joined #bitcoin-core-dev
 33 2016-07-21T02:12:29  *** CubicEarth has quit IRC
 34 2016-07-21T02:17:29  *** netsin has joined #bitcoin-core-dev
 35 2016-07-21T02:23:11  *** netsin has quit IRC
 36 2016-07-21T02:33:18  *** TomMc has quit IRC
 37 2016-07-21T02:39:53  *** netsin has joined #bitcoin-core-dev
 38 2016-07-21T02:41:24  *** netsin has quit IRC
 39 2016-07-21T02:43:05  *** netsin has joined #bitcoin-core-dev
 40 2016-07-21T02:44:17  *** netsin has quit IRC
 41 2016-07-21T02:58:10  *** CubicEarth has joined #bitcoin-core-dev
 42 2016-07-21T03:01:05  *** alpalp has quit IRC
 43 2016-07-21T03:10:11  *** Chris_Stewart_5 has quit IRC
 44 2016-07-21T03:13:40  *** netsin has joined #bitcoin-core-dev
 45 2016-07-21T03:16:12  *** supasonic has quit IRC
 46 2016-07-21T03:45:46  *** fengling_ has quit IRC
 47 2016-07-21T03:55:27  *** fengling_ has joined #bitcoin-core-dev
 48 2016-07-21T04:02:46  *** fengling_ has quit IRC
 49 2016-07-21T04:04:40  *** CubicEarth has quit IRC
 50 2016-07-21T04:06:11  *** netsin has quit IRC
 51 2016-07-21T04:09:14  *** netsin has joined #bitcoin-core-dev
 52 2016-07-21T04:14:22  *** netsin has quit IRC
 53 2016-07-21T04:31:59  *** netsin has joined #bitcoin-core-dev
 54 2016-07-21T04:37:44  *** fengling_ has joined #bitcoin-core-dev
 55 2016-07-21T04:47:47  *** netsin has quit IRC
 56 2016-07-21T07:19:08  *** Ylbam has joined #bitcoin-core-dev
 57 2016-07-21T07:20:55  *** paveljanik has quit IRC
 58 2016-07-21T07:39:34  *** AaronvanW has joined #bitcoin-core-dev
 59 2016-07-21T07:39:34  *** AaronvanW has quit IRC
 60 2016-07-21T07:39:34  *** AaronvanW has joined #bitcoin-core-dev
 61 2016-07-21T07:53:47  *** laurentmt has joined #bitcoin-core-dev
 62 2016-07-21T08:20:38  *** blur3d has joined #bitcoin-core-dev
 63 2016-07-21T08:22:05  *** blur3d has quit IRC
 64 2016-07-21T08:41:10  *** spudowiar has joined #bitcoin-core-dev
 65 2016-07-21T08:48:52  *** fengling_ is now known as fengling
 66 2016-07-21T08:53:39  <NicolasDorier> wumpus: can you merge https://github.com/bitcoin/bitcoin/pull/8342 and https://github.com/bitcoin/bitcoin/pull/8341 when you have time (two trivial already acked commits)
 67 2016-07-21T08:55:55  <NicolasDorier> ha and https://github.com/bitcoin/bitcoin/pull/8347
 68 2016-07-21T08:56:28  <NicolasDorier> all trivial stuff so jtimon and me can rebase our independant work on top of it and have smaller future PR
 69 2016-07-21T09:05:03  *** harrymm has quit IRC
 70 2016-07-21T09:21:33  *** harrymm has joined #bitcoin-core-dev
 71 2016-07-21T09:34:58  *** spudowiar has quit IRC
 72 2016-07-21T09:38:19  *** pedrobranco has joined #bitcoin-core-dev
 73 2016-07-21T09:43:52  <wumpus> yes, makes sense
 74 2016-07-21T09:46:21  *** pedrobranco has quit IRC
 75 2016-07-21T09:47:27  *** pedrobranco has joined #bitcoin-core-dev
 76 2016-07-21T09:47:31  *** owowo has quit IRC
 77 2016-07-21T09:54:23  *** owowo has joined #bitcoin-core-dev
 78 2016-07-21T09:57:22  <GitHub64> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8e048f40cc25...6f4092da80bc
 79 2016-07-21T09:57:22  <GitHub64> bitcoin/master a3e1984 NicolasDorier: Consensus: Trivial transform BOOST_FOREACH into for loop
 80 2016-07-21T09:57:23  <GitHub64> bitcoin/master 6f4092d Wladimir J. van der Laan: Merge #8342: Consensus: Trivial transform BOOST_FOREACH into for loop...
 81 2016-07-21T09:57:34  <GitHub69> [bitcoin] laanwj closed pull request #8342: Consensus: Trivial transform BOOST_FOREACH into for loop (master...removeforeach) https://github.com/bitcoin/bitcoin/pull/8342
 82 2016-07-21T10:01:55  *** JackH has joined #bitcoin-core-dev
 83 2016-07-21T10:16:52  *** jtimon has joined #bitcoin-core-dev
 84 2016-07-21T10:20:32  *** jannes has joined #bitcoin-core-dev
 85 2016-07-21T10:48:20  *** Guyver2 has joined #bitcoin-core-dev
 86 2016-07-21T10:50:06  *** Sosumi has quit IRC
 87 2016-07-21T10:53:16  *** cryptapus has joined #bitcoin-core-dev
 88 2016-07-21T10:56:10  *** btcfan has joined #bitcoin-core-dev
 89 2016-07-21T11:32:09  *** btcfan has quit IRC
 90 2016-07-21T11:33:04  *** laurentmt has quit IRC
 91 2016-07-21T11:36:44  *** pmienk has quit IRC
 92 2016-07-21T11:45:41  *** laurentmt has joined #bitcoin-core-dev
 93 2016-07-21T11:49:17  *** pmienk has joined #bitcoin-core-dev
 94 2016-07-21T12:02:03  <NicolasDorier> wumpus: I just rebased https://github.com/bitcoin/bitcoin/pull/8341 (the second stupid trivial one)
 95 2016-07-21T12:02:17  <wumpus> NicolasDorier: thanks
 96 2016-07-21T12:10:04  <GitHub43> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6f4092da80bc...04af3cfe8fa9
 97 2016-07-21T12:10:04  <GitHub43> bitcoin/master 7821889 NicolasDorier: Consensus: Remove calls to error() from ContextualCheckBlock
 98 2016-07-21T12:10:04  <GitHub43> bitcoin/master 04af3cf Wladimir J. van der Laan: Merge #8341: Consensus: Remove calls to error() from ContextualCheckBlock...
 99 2016-07-21T12:10:13  <GitHub57> [bitcoin] laanwj closed pull request #8341: Consensus: Remove calls to error() from ContextualCheckBlock (master...error-calls) https://github.com/bitcoin/bitcoin/pull/8341
100 2016-07-21T12:12:19  *** TomMc has joined #bitcoin-core-dev
101 2016-07-21T12:17:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
102 2016-07-21T12:20:06  *** fengling has quit IRC
103 2016-07-21T12:26:57  <NicolasDorier> wumpus: last is https://github.com/bitcoin/bitcoin/pull/8347 of jtimon and I let you sleep in peace
104 2016-07-21T12:28:45  <NicolasDorier> wumpus: woops, wait
105 2016-07-21T12:28:50  <wumpus> OH I was misreading that, looking at the github page it seemed like jtimon was still adding commits to it, but it says "added a commit to jtimon/bitcoin that referenced this pull request", I think that's new?
106 2016-07-21T12:28:57  <sipa> i don't expect wumpus to sleep at 2:30 pm
107 2016-07-21T12:28:59  <sipa> :)
108 2016-07-21T12:29:20  <wumpus> I have a strange sleep/wake rhythm sometimes, but no, I don't expect so either :-)
109 2016-07-21T12:29:22  <NicolasDorier> yeah, I just saw that too sorry, last time I checked was only the const change :p
110 2016-07-21T12:29:31  <btcdrak> sipa: I dont expect him to sleep at all. I will buy some match sticks to keep his eyes open 24/7
111 2016-07-21T12:30:07  <sipa> btcdrak: quality of review may suffer slightly...
112 2016-07-21T12:30:10  <wumpus> it *is* only the const change, github is just making it confusing
113 2016-07-21T12:30:34  <NicolasDorier> oh indeed
114 2016-07-21T12:30:51  <NicolasDorier> got confused as well
115 2016-07-21T12:31:56  <GitHub37> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/04af3cfe8fa9...381917f610e3
116 2016-07-21T12:31:56  <GitHub37> bitcoin/master 6f3d616 Jorge Timón: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock
117 2016-07-21T12:31:57  <GitHub37> bitcoin/master 381917f Wladimir J. van der Laan: Merge #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock...
118 2016-07-21T12:32:08  <GitHub87> [bitcoin] laanwj closed pull request #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock (master...0.12.99-consensus-const-lost) https://github.com/bitcoin/bitcoin/pull/8347
119 2016-07-21T12:34:58  <NicolasDorier> thanks
120 2016-07-21T12:40:52  <jtimon> awesome, thanks guys
121 2016-07-21T12:41:42  <jtimon> NicolasDorier: regarding some of our diffenrces in getflags parameters, they will be resolved by removing issupermajority instead of moving it
122 2016-07-21T12:44:29  <NicolasDorier> ooooh that's super cool if we can remove it
123 2016-07-21T12:44:41  <NicolasDorier> how? hard coding the activations ?
124 2016-07-21T12:44:53  <btcdrak> NicolasDorier: this was the discussion on it https://botbot.me/freenode/bitcoin-core-dev/2016-07-17/?msg=69776851&page=1
125 2016-07-21T12:45:36  *** Chris_Stewart_5 has quit IRC
126 2016-07-21T12:47:12  <NicolasDorier> oh cool
127 2016-07-21T12:49:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
128 2016-07-21T12:52:13  <GitHub111> [bitcoin] NicolasDorier closed pull request #8344: Consensus: Use pindex for ISM check (master...not-using-block) https://github.com/bitcoin/bitcoin/pull/8344
129 2016-07-21T12:52:38  *** harrymm has quit IRC
130 2016-07-21T12:53:03  *** rubensayshi has joined #bitcoin-core-dev
131 2016-07-21T12:54:30  <NicolasDorier> gmaxwell: do you plan to make a PR soon about removing ISM completely ? I can work on redoing it  if needed, it simplify the code I'm writing for verifyBlock in consensuslib
132 2016-07-21T13:00:21  *** YOU-JI has joined #bitcoin-core-dev
133 2016-07-21T13:09:07  *** harrymm has joined #bitcoin-core-dev
134 2016-07-21T13:09:24  <jtimon> btw, https://github.com/bitcoin/bitcoin/pull/8348 and https://github.com/bitcoin/bitcoin/pull/8346 are pretty trivial too
135 2016-07-21T13:11:38  <jtimon> NicolasDorier: yeah, hardcoding the activations in Consensus::Params like CodeShark did with bip34, the other day gmaxwell said he was working on suh a branch
136 2016-07-21T13:12:13  <jtimon> Ideally we would use an array, I wish I had seen the PR for BIP34 when it was open...
137 2016-07-21T13:13:32  <jtimon> I'm happy to write that too, the hardest part for me would be too look at the heights and block hashes
138 2016-07-21T13:16:50  <jtimon> but yeah, whoever writes it, it simplifies things for libconsensus encapsulation
139 2016-07-21T13:50:12  *** Guyver2 has quit IRC
140 2016-07-21T13:53:10  *** YOU-JI has quit IRC
141 2016-07-21T13:54:08  *** rubensayshi has quit IRC
142 2016-07-21T14:18:51  *** fengling has joined #bitcoin-core-dev
143 2016-07-21T14:20:26  <GitHub197> [bitcoin] jtimon closed pull request #8345: Introduce Consensus::GetFlags() and hide IsSuperMajority() (master...0.12.99-consensus-flags) https://github.com/bitcoin/bitcoin/pull/8345
144 2016-07-21T14:23:46  *** fengling has quit IRC
145 2016-07-21T14:38:31  *** Chris_Stewart_5 has quit IRC
146 2016-07-21T14:43:12  *** harrymm has quit IRC
147 2016-07-21T14:53:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
148 2016-07-21T14:53:34  <jtimon> sipa: I've been thinking more about the consensus vs script flags, I guess it has the advantage of having a much shorter list of consensus flags, basically only one per consensus deployment (well, we can keep bip68 and bip112 as separated flags), while the script flags have many more thant in principle don't need to be exposed in libconsensus
149 2016-07-21T14:54:37  <sipa> jtimon: right; if the script code is at some point duplicated to form a consensus-only form, we could combine the flags there
150 2016-07-21T14:55:04  <sipa> but as long as the script code is more generically useful, it will have flags that are not necessarily consensus, and it feels cleaner to have the script code independent
151 2016-07-21T14:56:09  <jtimon> but I still believe that the refactor is much simpler if we put temporarily the locktime flags and the new ones (bip30 and bip34) in the script flags and then we separate them
152 2016-07-21T14:58:08  *** harrymm has joined #bitcoin-core-dev
153 2016-07-21T14:58:45  <jtimon> those non consensus script flags are hidden behind the flags in script/bitcoinconsensus.h for libconsensus anyway, that's why I wasn't seeing the point at first
154 2016-07-21T15:00:26  <jtimon> probably that's where the consensus flags should be instead of consensus/falgs.h as previously suggested, but then main would need to include script/bitcoinconsensus.h
155 2016-07-21T15:01:12  <jtimon> s/falgs/flags
156 2016-07-21T15:04:01  <jtimon> mhmm, no converter is necessary if the flags in script/bitcoinconsensus.h and script/interpreter.h just keep matching in their bit numbers...
157 2016-07-21T15:04:31  <sipa> that's a terrible idea
158 2016-07-21T15:04:46  <sipa> i've argued several times that they should be made independent
159 2016-07-21T15:05:02  <sipa> internal constants should not leak into a public API
160 2016-07-21T15:05:05  <jtimon> I also prefer the converter function, but that's what we're doing right now
161 2016-07-21T15:05:19  <jtimon> makes sense
162 2016-07-21T15:05:43  <jtimon> ok, this helps me understand your whole reasoning much better, thanks
163 2016-07-21T15:05:57  <sipa> but yes, that is what we're currently doing - but i wouldn't extend that practice further
164 2016-07-21T15:07:50  <jtimon> I'll write a converter function and see how disruptive it looks compared with temporarily putting non-script flags in script/interpreter.h
165 2016-07-21T15:10:27  <jtimon> erik from libbitcoin also complained about the flags, I believe that was one of the reasons they don't use our API directly and copy the code instead, but IIRC the main one is having to serialize/decerialize the tx to be signed
166 2016-07-21T15:12:42  <jtimon> should talk to him again to remind me his thoughts
167 2016-07-21T15:15:22  <jtimon> in fact, I should have taken notes
168 2016-07-21T15:15:51  <jtimon> I have a very good reason for trusting my memory instead of taking notes most of the time, but I forgot what it was ;)
169 2016-07-21T15:16:24  <sipa> hahaha
170 2016-07-21T15:20:52  *** fengling has joined #bitcoin-core-dev
171 2016-07-21T15:25:26  *** fengling has quit IRC
172 2016-07-21T15:26:40  *** pedrobranco has quit IRC
173 2016-07-21T15:27:07  *** pedrobranco has joined #bitcoin-core-dev
174 2016-07-21T15:30:25  *** pedrobranco has quit IRC
175 2016-07-21T15:30:47  *** pedrobranco has joined #bitcoin-core-dev
176 2016-07-21T15:32:22  <GitHub188> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/66dde4edf733...cbdbc75139a6
177 2016-07-21T15:32:22  <GitHub188> bitcoin/0.13 f891e34 Jannes Faber: fix typo: propagation relay -> delay
178 2016-07-21T15:32:23  <GitHub188> bitcoin/0.13 cbdbc75 Wladimir J. van der Laan: Merge #8380: fix typo: propagation relay -> delay...
179 2016-07-21T15:32:26  <GitHub33> [bitcoin] laanwj closed pull request #8380: fix typo: propagation relay -> delay (0.13...patch-1) https://github.com/bitcoin/bitcoin/pull/8380
180 2016-07-21T15:48:31  *** Chris_Stewart_5 has quit IRC
181 2016-07-21T15:50:59  *** Guyver2 has joined #bitcoin-core-dev
182 2016-07-21T15:54:03  <GitHub75> [bitcoin] laanwj closed pull request #8374: Add release notes for mining changes (0.13...release-notes-mining) https://github.com/bitcoin/bitcoin/pull/8374
183 2016-07-21T15:54:05  <GitHub67> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/cbdbc75139a6...76bc30beab86
184 2016-07-21T15:54:05  <GitHub67> bitcoin/0.13 52a4158 Suhas Daftuar: Add release notes for mining changes
185 2016-07-21T15:54:06  <GitHub67> bitcoin/0.13 76bc30b Wladimir J. van der Laan: Merge #8374: Add release notes for mining changes...
186 2016-07-21T15:54:57  <luke-jr> …
187 2016-07-21T15:58:39  <wumpus> luke-jr: you can do your proposed changes now
188 2016-07-21T15:59:51  * luke-jr wonders why his 0.10 won't compile anymore. :x
189 2016-07-21T16:02:41  * Lightsword wonders why luke-jr is using 0.10
190 2016-07-21T16:02:42  *** frankenmint has joined #bitcoin-core-dev
191 2016-07-21T16:03:35  <luke-jr> Lightsword: my hot wallet has too much in it to risk upgrading yet; I should probably deal with that
192 2016-07-21T16:03:46  *** spudowiar has joined #bitcoin-core-dev
193 2016-07-21T16:04:25  <Lightsword> luke-jr, can’t you just backup wallet.dat before doing anything with latest version?
194 2016-07-21T16:04:58  <luke-jr> Lightsword: sure, but bdb issues are the least probable kind of loss
195 2016-07-21T16:05:35  <luke-jr> I have no particular concerns, just don't like to use new code with lots of funds
196 2016-07-21T16:05:55  <Lightsword> what are the other probable kind?
197 2016-07-21T16:06:28  <luke-jr> Lightsword: sending the wrong amount somewhere, or to fee
198 2016-07-21T16:06:47  * Lightsword wonders why that would be less likely to happen with an older wallet
199 2016-07-21T16:07:25  <luke-jr> no changes to the old code
200 2016-07-21T16:07:56  <luke-jr> the usual reason stable software is preferred over bleeding edge
201 2016-07-21T16:08:27  <luke-jr> anyhow, looks like it was a build system issue, and got it to build
202 2016-07-21T16:08:28  <Lightsword> yeah…but 0.10…is two releases behind the latest stable
203 2016-07-21T16:09:11  <luke-jr> not even a year old
204 2016-07-21T16:09:21  <luke-jr> 0.10.4 was released 2015 Nov
205 2016-07-21T16:09:55  <Lightsword> I thought 0.11.2 or whatever was earlier since 0.10.4 was a backport
206 2016-07-21T16:12:24  <luke-jr> v0.11.0 was 2015 Jul
207 2016-07-21T16:12:33  <luke-jr> only a year
208 2016-07-21T16:22:02  *** fengling has joined #bitcoin-core-dev
209 2016-07-21T16:26:46  *** fengling has quit IRC
210 2016-07-21T16:34:10  *** aalex has quit IRC
211 2016-07-21T16:34:30  *** netsin has joined #bitcoin-core-dev
212 2016-07-21T16:35:27  *** aalex has joined #bitcoin-core-dev
213 2016-07-21T16:46:58  *** sipa has quit IRC
214 2016-07-21T16:46:58  *** sipa has joined #bitcoin-core-dev
215 2016-07-21T16:50:39  *** netsin has quit IRC
216 2016-07-21T17:01:33  <GitHub177> [bitcoin] luke-jr opened pull request #8386: mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti) https://github.com/bitcoin/bitcoin/pull/8386
217 2016-07-21T17:01:53  <GitHub184> [bitcoin] luke-jr opened pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
218 2016-07-21T17:02:01  <GitHub33> [bitcoin] luke-jr closed pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
219 2016-07-21T17:02:38  <GitHub51> [bitcoin] luke-jr opened pull request #8388: [0.13] mining: Optimise for typical mining use with blockmaxsize (0.13...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8388
220 2016-07-21T17:03:13  *** frankenmint has quit IRC
221 2016-07-21T17:06:12  *** spudowiar has quit IRC
222 2016-07-21T17:09:22  *** MarcoFalke has joined #bitcoin-core-dev
223 2016-07-21T17:21:16  *** netsin has joined #bitcoin-core-dev
224 2016-07-21T17:23:57  *** fengling has joined #bitcoin-core-dev
225 2016-07-21T17:28:26  *** fengling has quit IRC
226 2016-07-21T17:28:34  *** TomMc has quit IRC
227 2016-07-21T17:41:00  *** spudowiar has joined #bitcoin-core-dev
228 2016-07-21T17:45:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
229 2016-07-21T17:48:44  <gmaxwell> are there NO web block explorers that show transaction version numbers?!
230 2016-07-21T17:52:12  <gmaxwell> hmph, when connecting blocks at start RPC can return "Loading banlist" for the duration...
231 2016-07-21T17:53:01  <wumpus> gmaxwell: known issue https://github.com/bitcoin/bitcoin/issues/8117
232 2016-07-21T17:54:55  <wumpus> it's supposed to release the lock every block, but sometimes it appears it doesn't
233 2016-07-21T17:55:33  <roasbeef> gmaxwell: smartbit and http://srv1.yogh.io/ do, a few other do as well but can't recall off the top atm
234 2016-07-21T17:55:39  *** murch has joined #bitcoin-core-dev
235 2016-07-21T17:56:46  *** wangchun has quit IRC
236 2016-07-21T18:00:06  <achow101> gmaxwell: blockcypher does under "advanced details"
237 2016-07-21T18:03:02  <jonasschnelli> <phantomcircuit:#bitcoin-core-dev> jonasschnelli, can you check 8152 again
238 2016-07-21T18:03:14  <jonasschnelli> Yes. Will do.
239 2016-07-21T18:05:39  <sipa> wumpus: i think we should try adding a yield and see if there is a performance degradation
240 2016-07-21T18:06:51  <sipa> wumpus: in ActivateBestChain
241 2016-07-21T18:07:34  <gmaxwell> roasbeef: achow101: Thanks, I tried like 5 of them before giving up.
242 2016-07-21T18:09:54  <wumpus> sipa: Iworth a try I guess
243 2016-07-21T18:10:52  <sipa> wumpus: as far as i know there is no guarantee that the scheduler gives a fair distribution of cpu time in case there are multiple waiting threads
244 2016-07-21T18:11:26  <sipa> in ActivateBestChain we release cs_main but pretty much instantly grab it agaim
245 2016-07-21T18:11:27  <wumpus> there is no guarantee, no, but with multiple cores I think usually a waiting thread should get the lock
246 2016-07-21T18:12:18  <wumpus> but indeed if you grab it immediately again, that may be a special case
247 2016-07-21T18:12:39  <gmaxwell> we could just add explicit sleeps when connecting more than a few blocks.
248 2016-07-21T18:12:40  <wumpus> it may be re-locked before anyone else even sees
249 2016-07-21T18:12:49  <wumpus> adding sleeps sounds really ugly
250 2016-07-21T18:13:00  <wumpus> there must be a better way
251 2016-07-21T18:13:52  <sipa> yes, getting rid of locks that are held for long periods of time :)
252 2016-07-21T18:13:54  <wumpus> I'm aware a yield is effectively a sleep for one timeshare, but at least it's as short as possible
253 2016-07-21T18:15:13  <sipa> maybe we can release cs_main during signature verification (but after fetching inputs from the cache), and grabbing it back afterwards and compare if the tip is still the same, and apply the changes
254 2016-07-21T18:15:46  <wumpus> maybe yield-every-N-ms-or-more instead of, by definition, every block? this avoids the yield slowing things down in the beginning when blocks validate really fast
255 2016-07-21T18:15:52  <wumpus> then again maybe it's not a performance issue at all
256 2016-07-21T18:16:38  <sipa> well there are two questions: 1) is yield sufficient to fix this problem at all?
257 2016-07-21T18:16:55  <sipa> 2) what performance overhead does yield have if there are no orher waiters
258 2016-07-21T18:17:07  <wumpus> the issue is only noticable when cs_main is held for, say, more than a second
259 2016-07-21T18:17:27  <wumpus> (2) is up to 20ms, depending on the scheduler
260 2016-07-21T18:17:35  <wumpus> it just gives away the rest of the timeslot
261 2016-07-21T18:18:17  <sipa> it gives away the rest of the timeslot if there is another candidate for taking the timeslot
262 2016-07-21T18:18:34  <wumpus> yes, which is very likely on a modern multitasking OS
263 2016-07-21T18:19:38  <wumpus> but indeed it depends on factors not under bitcoind's control
264 2016-07-21T18:19:50  <sipa> we should benchmark :)
265 2016-07-21T18:21:36  *** AaronvanW has quit IRC
266 2016-07-21T18:24:58  *** fengling has joined #bitcoin-core-dev
267 2016-07-21T18:27:28  *** Amnez777 has quit IRC
268 2016-07-21T18:28:19  *** AaronvanW has joined #bitcoin-core-dev
269 2016-07-21T18:28:48  <jeremyrubin> I'm using this_thread::yield() in some code right now while I wait on something, seems to work well enough
270 2016-07-21T18:28:54  *** pedrobranco has quit IRC
271 2016-07-21T18:29:20  *** [b__b] has quit IRC
272 2016-07-21T18:29:37  *** gabridome has joined #bitcoin-core-dev
273 2016-07-21T18:29:46  *** fengling has quit IRC
274 2016-07-21T18:30:37  *** [b__b] has joined #bitcoin-core-dev
275 2016-07-21T18:51:05  *** lightningbot has joined #bitcoin-core-dev
276 2016-07-21T18:59:29  <wumpus> meeting time
277 2016-07-21T18:59:39  <jonasschnelli> megaping required
278 2016-07-21T18:59:41  <btcdrak> here
279 2016-07-21T18:59:46  <jeremyrubin> here
280 2016-07-21T18:59:49  <bsm117532> here
281 2016-07-21T18:59:50  <luke-jr> grubles: nicks
282 2016-07-21T18:59:51  <wumpus> #startmeeting
283 2016-07-21T18:59:51  <lightningbot> Meeting started Thu Jul 21 18:59:51 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
284 2016-07-21T18:59:51  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
285 2016-07-21T18:59:52  <sipa> here
286 2016-07-21T18:59:58  <luke-jr> guess he won't do it XD
287 2016-07-21T19:00:02  <gmaxwell> #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
288 2016-07-21T19:00:09  *** sanada has quit IRC
289 2016-07-21T19:00:16  <kanzure> topics?
290 2016-07-21T19:00:16  <sipa> thanks, gmaxwellbot
291 2016-07-21T19:00:20  <wumpus> topic: 0.13
292 2016-07-21T19:00:24  <gmaxwell> s'not a bot.
293 2016-07-21T19:00:30  <jonasschnelli> topic: 0.13 OSX determinism
294 2016-07-21T19:00:32  <btcdrak>  /msg gmaxwell help topics
295 2016-07-21T19:00:32  <cfields> here, but at conference and only 1/2 present
296 2016-07-21T19:00:36  <luke-jr> gribble: nicks
297 2016-07-21T19:00:44  <grubles> luke-jr: ?
298 2016-07-21T19:00:45  <btcdrak> maxwellbot appears to be down
299 2016-07-21T19:00:45  <wumpus> jonasschnelli: wasn't that solved already?
300 2016-07-21T19:00:50  <luke-jr> grubles: mixed you up with the box :p
301 2016-07-21T19:00:55  <wumpus> #topic 0.13
302 2016-07-21T19:01:07  <jonasschnelli> wumpus: ah. Was that merged already... sorry, have't noticed.
303 2016-07-21T19:01:11  <wumpus> any criticial issues reported with the rc1 yet?
304 2016-07-21T19:01:14  <grubles> luke-jr: oh ok :)
305 2016-07-21T19:01:24  <luke-jr> wumpus: lack of a way to export the seed has been a complaint on reddit at least
306 2016-07-21T19:01:34  <jonasschnelli> I'm working on the critical bug with HD and wallet encrypt (that's the only feedback I got from Rc1)
307 2016-07-21T19:01:39  <cfields> jonasschnelli: yes. I need to upstream it though.
308 2016-07-21T19:02:00  <wumpus> jonasschnelli: thanks, yes I've added 0.13 milestone to https://github.com/bitcoin/bitcoin/issues/8383
309 2016-07-21T19:02:01  *** pedrobranco has joined #bitcoin-core-dev
310 2016-07-21T19:02:01  <jonasschnelli> there is a PR to export the seed in dumpwallet
311 2016-07-21T19:02:07  <jonasschnelli> we could consider that for 0.13
312 2016-07-21T19:02:11  *** netsin has quit IRC
313 2016-07-21T19:02:12  <jonasschnelli> its easy to review.
314 2016-07-21T19:02:15  <jonasschnelli> Low impacts
315 2016-07-21T19:02:15  <wumpus> jonasschnelli: if it's low-impact, why not
316 2016-07-21T19:02:21  <luke-jr> wumpus: the default policy not performing as well as inadvisable policies is apparently an issue, which I just PR'd a fix for an hour or so ago
317 2016-07-21T19:02:21  <sipa> agree on that
318 2016-07-21T19:02:27  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8206
319 2016-07-21T19:02:28  <CodeShark> wumpus: there are a few issues with the release notes - I'll try to submit comments shortly
320 2016-07-21T19:02:33  <luke-jr> jonasschnelli: IMO yes
321 2016-07-21T19:02:47  <sipa> jonasschnelli: also in importwallet ?
322 2016-07-21T19:02:52  <jonasschnelli> Ino
323 2016-07-21T19:02:55  <jonasschnelli> no
324 2016-07-21T19:02:57  <wumpus> no, just exporting
325 2016-07-21T19:03:03  <jonasschnelli> import wallet imples "import" and no change the see
326 2016-07-21T19:03:05  <wumpus> importing is a wholly different issue
327 2016-07-21T19:03:05  <jonasschnelli> seed
328 2016-07-21T19:03:21  <luke-jr> jonasschnelli: I don't see why import doesn't imply adding the seed
329 2016-07-21T19:03:22  <jonasschnelli> Import would just pick the keys.
330 2016-07-21T19:03:23  <wumpus> (e.g. in some cases you may want to change the seed, but usually probably not)
331 2016-07-21T19:03:34  <luke-jr> does the current format all multiple seeds?
332 2016-07-21T19:03:35  <jonasschnelli> luke-jr: adding yes, but not overwriting the current one
333 2016-07-21T19:03:35  <wumpus> luke-jr: because you may be importing to *combine* wallets
334 2016-07-21T19:03:44  <jonasschnelli> luke-jr: a seed is just a key
335 2016-07-21T19:03:45  <luke-jr> err
336 2016-07-21T19:03:52  <luke-jr> *does the current format support having multiple seeds?
337 2016-07-21T19:03:56  <sipa> nope
338 2016-07-21T19:03:59  <gmaxwell> nope
339 2016-07-21T19:04:02  <wumpus> in any case that's too much impact
340 2016-07-21T19:04:06  <luke-jr> I suppose
341 2016-07-21T19:04:10  <wumpus> exporting is easy to do for 0.13 so I think we should
342 2016-07-21T19:04:15  <sipa> that would require having multiple lookahead key pools etc
343 2016-07-21T19:04:18  <sipa> ack on export
344 2016-07-21T19:04:18  <gmaxwell> it's the simplest possible.
345 2016-07-21T19:04:33  <wumpus> for 0.14 we could consider things like support multiple seeds
346 2016-07-21T19:04:45  <jonasschnelli> Okay. Marked #8206 for 0.13
347 2016-07-21T19:04:48  <jonasschnelli> #action review #8206
348 2016-07-21T19:04:53  <luke-jr> IMO as long as we're not ruling out multi-seed wallets in 0.14+, ok
349 2016-07-21T19:04:54  <wumpus> thanks
350 2016-07-21T19:05:06  <sipa> luke-jr: agree
351 2016-07-21T19:05:23  <jonasschnelli> Since we have now the most important change done for HD, we can try to add lots of features for 0.14.
352 2016-07-21T19:05:25  <jtimon> proposed topic: remove ISM
353 2016-07-21T19:05:27  *** GAit has joined #bitcoin-core-dev
354 2016-07-21T19:05:41  *** belcher has joined #bitcoin-core-dev
355 2016-07-21T19:06:21  *** pedrobranco has quit IRC
356 2016-07-21T19:06:21  <wumpus> proposed topic from jeremyrubin: checkqueue.h change
357 2016-07-21T19:06:43  <sipa> are we done with 0.13 discussion?
358 2016-07-21T19:06:45  <jeremyrubin> wumpus: topic proposal checkqueue performance
359 2016-07-21T19:07:03  <jeremyrubin> ah oops sorry network lag
360 2016-07-21T19:07:09  <jtimon> jeremyrubin: thanks for being more specific
361 2016-07-21T19:07:16  <wumpus> sipa: I think so, unless there are other issues reported I think that's all for 0.13 for this week
362 2016-07-21T19:07:38  <jtimon> jeremyrubin: seriously, don't be sorry, it helped me
363 2016-07-21T19:07:39  <sipa> ok
364 2016-07-21T19:07:55  <wumpus> #topic remove ISM
365 2016-07-21T19:08:12  <luke-jr> (https://github.com/bitcoin/bitcoin/pull/8388 needs a 0.13 tag I guess)
366 2016-07-21T19:08:47  <sipa> about removing ISM
367 2016-07-21T19:08:49  <sipa> how?
368 2016-07-21T19:09:04  <wumpus> ISM=IsSuperMajority?
369 2016-07-21T19:09:08  <instagibbs> yes
370 2016-07-21T19:09:08  <sipa> 1) just a height after which the previous softforks activate
371 2016-07-21T19:09:09  *** GAit has quit IRC
372 2016-07-21T19:09:09  <btcdrak> wumpus: yes
373 2016-07-21T19:09:13  <jtimon> well, my preference would be to introduce a getflags function first
374 2016-07-21T19:09:16  <gmaxwell> when are we branching? I've been holding off on patches until after the branch.
375 2016-07-21T19:09:27  <sipa> gmaxwell: branch was a few days ago
376 2016-07-21T19:09:28  *** GAit has joined #bitcoin-core-dev
377 2016-07-21T19:09:29  <btcdrak> gmaxwell: we branched already
378 2016-07-21T19:09:29  <wumpus> gmaxwell: we've already branched a few days ago
379 2016-07-21T19:09:31  <luke-jr> how many exceptional blocks violate softfork-added rules?
380 2016-07-21T19:09:50  <sdaftuar> i'm curious to know what you're thinking about doing for regtest
381 2016-07-21T19:10:01  <btcdrak> for some reason github didnt ping the channel on new branch creation
382 2016-07-21T19:10:23  <gmaxwell> oh I missed that.
383 2016-07-21T19:10:24  <instagibbs> sdaftuar, any issues you can think of?
384 2016-07-21T19:10:30  <sipa> sdaftuar: ugh... a command line option to enable the rules individually (from the start, over the entire chain)?
385 2016-07-21T19:10:33  <jtimon> but knowing that ISM is going to be reomved, just don't touch any ISM call and leave it all prepared for ISM calls to be simply removed from main and replaced with the new code inside versionbits::getflags()\
386 2016-07-21T19:10:57  <wumpus> luke-jr: 8388 is a pretty large change, isn't that a lot to do last-minute? also you don't have a description on the pull at all
387 2016-07-21T19:11:04  <gmaxwell> jtimon: ISM things are not versionbits.
388 2016-07-21T19:11:08  <gmaxwell> We went over this before.
389 2016-07-21T19:11:17  <btcdrak> yes we did
390 2016-07-21T19:11:19  *** Amnez777 has joined #bitcoin-core-dev
391 2016-07-21T19:11:21  <jtimon> I was previously of the opinion that a height was enough but I changed my mind, yes, block hash too
392 2016-07-21T19:11:39  <gmaxwell> sipa: see         consensus.BIP34Height = 227931;
393 2016-07-21T19:11:46  <gmaxwell> sipa: in chainparams.cpp
394 2016-07-21T19:11:47  <btcdrak> jtimon: gmaxwell said he is working on a ISM removal PR
395 2016-07-21T19:11:48  <gmaxwell> "like that"
396 2016-07-21T19:12:14  <luke-jr> wumpus: well, I didn't expect counting bytes to be used as an excuse to have the release notes pressure miners to use bad policy configs
397 2016-07-21T19:12:25  *** sipa has left #bitcoin-core-dev
398 2016-07-21T19:12:44  <jtimon> gmaxwell: agreed, I only want a getconsensusflags function, if it's defined in versionbits or consensus/header_verify.cpp or somewhere else I don't care so much
399 2016-07-21T19:12:53  <gmaxwell> sdaftuar: what I'd done is just set regtest to 0, but hadn't checked to see what tests doing that would break.
400 2016-07-21T19:13:00  *** dstadulis has joined #bitcoin-core-dev
401 2016-07-21T19:13:13  <jtimon> but I strongly oppose to define getflags in main.cpp
402 2016-07-21T19:13:22  <gmaxwell> jtimon: the things which are ISM should not be flags, becuase they're not optional anymore.
403 2016-07-21T19:13:22  <wumpus> luke-jr: ok, fair enough, I do think it requires more discussion
404 2016-07-21T19:13:40  <btcdrak> jtimon: but that doesnt mean you can stuff them into an unrelated unit
405 2016-07-21T19:13:44  <sdaftuar> gmaxwell: i guess we can just change the tests that test activation of ISM things
406 2016-07-21T19:14:00  <sdaftuar> gmaxwell: so maybe that will work fine?
407 2016-07-21T19:14:15  <morcos> gmaxwell: they still need flags right?  for when they are active and when they aren't?
408 2016-07-21T19:14:19  *** sipa has joined #bitcoin-core-dev
409 2016-07-21T19:14:34  <gmaxwell> sdaftuar: yea, thats what I was thinking. the obvious alternative is to set it to something not 0, like 5.. and let the tests handle it.
410 2016-07-21T19:14:36  <sdaftuar> i wonder if there are cases where we might want to test how a chain behaves when some blocks don't satisfy a rule (like bip34) and then later ones do.
411 2016-07-21T19:15:02  <gmaxwell> morcos: some of the things are not accomplished via flags like mechenisms, e.g. the version number checks. They're not a script feature.
412 2016-07-21T19:15:27  <jtimon> btcdrak: yep, I just want to coordinate with him, in fact, I believe NicolasDorier and I will benifit more than gmaxwell from this coordination, gmaxwell doesn't really need us and can do it all in main
413 2016-07-21T19:15:31  <sipa> sdaftuar: versionbits does not need that anymore, and i don't care strongly about testing that for purely historical features
414 2016-07-21T19:15:45  <sipa> jtimon: please
415 2016-07-21T19:16:22  <sdaftuar> sipa: yeah i think you're basically right, we can just enumerate each of the ISM soft forks and make a decision, there's only a handful
416 2016-07-21T19:16:29  <sipa> sdaftuar: exactly
417 2016-07-21T19:16:43  <wumpus> jtimon: where to put it and what solution to use are orthogonal issues
418 2016-07-21T19:18:04  * luke-jr observes that P2SH was actually more like BIP 9 than ISM was
419 2016-07-21T19:18:08  <gmaxwell> Some future softforks that get virtified might even have no violations anywhere in the chain, in which case, I'd propose just removing all conditional logic for them entirely.
420 2016-07-21T19:18:09  <jtimon> wumpus: agreed, but two people trying to complete verifyblock would benefit in sharing the most common refactors as possible
421 2016-07-21T19:18:26  *** jeremyrubin has quit IRC
422 2016-07-21T19:18:29  <gmaxwell> I believe CSV might be an example of that.
423 2016-07-21T19:18:46  <jtimon> gmaxwell: I agree, but I was talking much shorter term here
424 2016-07-21T19:18:58  <jtimon> as in, whithin the refactor window
425 2016-07-21T19:19:11  <gmaxwell> adding a bunch of additional 'flags' for things like height checks would be undesirable code smell.
426 2016-07-21T19:19:32  <gmaxwell> as would moving ISM logic into a file called versionbits.cpp.
427 2016-07-21T19:19:40  <sipa> agree
428 2016-07-21T19:19:47  <luke-jr> gmaxwell: GBT will likely pose a problem for that, but probably not insurmountable (worst case we can neuter GBT by removing the clients-can-modify-the-template aspect, since nobody much uses it afaik)
429 2016-07-21T19:19:54  <CodeShark> I had proposed a softforks unit to solve this a while back ;)
430 2016-07-21T19:20:32  <gmaxwell> To be honest, I am really frustrated right now with some of the pointless nitpicky behavior being driven by 'refactoring' all of a sudden. It's making me want to not be involved in the project.
431 2016-07-21T19:20:37  <NicolasDorier> btw, I'm almost done with the PR removing ISM
432 2016-07-21T19:21:01  <gmaxwell> I don't have the time to endlessly debate minutia with people who are being very tunnel vision about varrious things.
433 2016-07-21T19:21:26  <CodeShark> ?
434 2016-07-21T19:21:33  <GitHub128> [bitcoin] jonasschnelli opened pull request #8389: [0.13] Create a new HD seed after encrypting the wallet (0.13...2016/07/hd_enc) https://github.com/bitcoin/bitcoin/pull/8389
435 2016-07-21T19:21:37  <jtimon> gmaxwell: the movement of ISM to versionbits was only in preparation to more cleanly remove it later and not having to include main.h from consensus files, but yeah no need to move it, just delete it beforehand
436 2016-07-21T19:21:44  <wumpus> well code that is going away doesn't need to be moved
437 2016-07-21T19:21:55  *** netsin has joined #bitcoin-core-dev
438 2016-07-21T19:21:57  <jtimon> of course, agreed
439 2016-07-21T19:22:11  *** jeremyrubin has joined #bitcoin-core-dev
440 2016-07-21T19:22:30  <wumpus> but refactoring main.cpp is also important - we've held it off for so long now
441 2016-07-21T19:22:45  *** netsin has quit IRC
442 2016-07-21T19:22:57  <CodeShark> Making sure the code doesn't get cluttered in the long run and establishing good habits for this early on are not tunnel vision, imho
443 2016-07-21T19:22:58  <sipa> agree
444 2016-07-21T19:23:02  <wumpus> after all that time we still have that huge c++ file with so many different responsibilities
445 2016-07-21T19:23:02  <jtimon> all I want to agree is that is "going away" to getflags, and that getflags has some place to exist (it may not be versionbits.o)
446 2016-07-21T19:23:16  <jtimon> it won't go away
447 2016-07-21T19:23:29  <sipa> jtimon: is getflags the "one set of flags for everything"? if so, nack
448 2016-07-21T19:23:36  <kanzure> while we're busy refactoring everything i would like libconsensus and a pony
449 2016-07-21T19:24:07  <jtimon> it will be replaced and we can leave it all preapare for where it will be replaced with something like bip34 and that will simplify things, I believe
450 2016-07-21T19:24:24  <sipa> ok, can we move on?
451 2016-07-21T19:24:28  <wumpus> in any case, this doesn't seem to be a constructive topic in the meeting anymore
452 2016-07-21T19:24:35  <CodeShark> yes, let's move ob
453 2016-07-21T19:24:39  <sipa> or are there still things about ISM?
454 2016-07-21T19:24:40  <CodeShark> on
455 2016-07-21T19:24:49  <wumpus> #topic checkqueue.h optimization
456 2016-07-21T19:24:58  <btcdrak> ping jeremyrubin
457 2016-07-21T19:25:08  *** dstadulis has quit IRC
458 2016-07-21T19:25:20  *** dstadulis has joined #bitcoin-core-dev
459 2016-07-21T19:25:36  <jtimon> sipa: thank you for being so direct. After our discussions on the subject, I agree the script flags should be separated, but for now it should be libconsensus flags and script flags, yes
460 2016-07-21T19:25:40  <jeremyrubin> Hi
461 2016-07-21T19:26:07  <jeremyrubin> So all I wanted to say is that I am doing some refactoring of checkqueue, have some nice improvements preliminarily.
462 2016-07-21T19:26:25  <jeremyrubin> Will push something to my fork if you're particularly interested in it
463 2016-07-21T19:26:27  *** fengling has joined #bitcoin-core-dev
464 2016-07-21T19:26:34  <jtimon> sipa: I know you won't like non-script flags in script/interpreter even temporarily, I'm working on changing that, but that's just hwat I have right now
465 2016-07-21T19:26:35  *** d_t has joined #bitcoin-core-dev
466 2016-07-21T19:26:45  <wumpus> jeremyrubin: looking forward to the pull request :)
467 2016-07-21T19:26:51  <jonasschnelli> jeremyrubin: nice!
468 2016-07-21T19:26:58  *** netsin has joined #bitcoin-core-dev
469 2016-07-21T19:27:09  <sipa> jeremyrubin: looking forward to it, obviously
470 2016-07-21T19:27:23  <sipa> (as long as it doesn't rely on MIPS assembly)
471 2016-07-21T19:27:25  <jtimon> wumpus: well, it is constructive for me, I'm getting useful feedback
472 2016-07-21T19:27:26  <jeremyrubin> just wanted to note it as I've heard some other people looking at it, so don't want to duplicte work
473 2016-07-21T19:27:52  <jeremyrubin> that's all!
474 2016-07-21T19:28:31  <cfields> jeremyrubin: along those lines, I've been working on optimizing the sigcache, after morcos pointed out some cool speedups. maybe we should work together to come up with a good representative bench for testing improvements?
475 2016-07-21T19:28:33  <wumpus> jtimon: ok that's good; it didn't seem to be going the right way. Seems that gmaxwell wants to get rid of ISM as soon as possible, so refactoring the ISM part is just a waste of work
476 2016-07-21T19:28:41  *** GAit has quit IRC
477 2016-07-21T19:28:57  <cfields> morcos: or are you still hacking on that? ^^
478 2016-07-21T19:29:00  <NicolasDorier> I will propose a PR for removing ISM in one or two hours normally
479 2016-07-21T19:29:10  <gmaxwell> I wanted to remove it in 0.13 but didn't want to introduct a conflict with the SW merge so I held off.
480 2016-07-21T19:29:14  <morcos> cfields: yep, we're working on it together!
481 2016-07-21T19:29:29  <gmaxwell> It saves like two whole milliseconds from block connecting times. :P
482 2016-07-21T19:29:32  <wumpus> NicolasDorier: great
483 2016-07-21T19:29:59  <jeremyrubin> cfields: sounds good -- will msg out of meeting
484 2016-07-21T19:30:07  <CodeShark> wumpus: focusing too much on ISM given its impending death is probably not the most urgent thing - my concern is more ovet general habits
485 2016-07-21T19:30:18  <CodeShark> *over
486 2016-07-21T19:30:23  <cfields> morcos: ah, ok.
487 2016-07-21T19:30:23  <wumpus> CodeShark: well the topic was removing ISM
488 2016-07-21T19:30:29  <sipa> gmaxwell: that's 12 minites of sync time :o
489 2016-07-21T19:30:32  <morcos> gmaxwell: i think with the lock free stuff jeremy is working on, i can get validation times down from 200ms to sub 50ms on my machine
490 2016-07-21T19:30:43  <sipa> morcos: impressive
491 2016-07-21T19:30:54  <sdaftuar> he has a lot of cores :P
492 2016-07-21T19:31:03  <jonasschnelli> heh
493 2016-07-21T19:31:17  <BlueMatt> sdaftuar: but across 2 cpus, so numa :/
494 2016-07-21T19:31:26  *** fengling has quit IRC
495 2016-07-21T19:31:27  *** netsin has quit IRC
496 2016-07-21T19:31:36  <wumpus> oh no numa, is that still a thing
497 2016-07-21T19:31:38  <jtimon> wumpus: I also want ISM to go away as soon as possible and I'll rebase on top of the PR as soon as it appears, I was just asking for an agreed trivial plan on how to "just don't touch ISM, the replacement will go here" that we could work on in the meantime
498 2016-07-21T19:31:50  <gmaxwell> wumpus: any multisocket system is numa.
499 2016-07-21T19:32:04  <gmaxwell> (these days)
500 2016-07-21T19:32:09  <jtimon> wumpus: in my experience "will go here" can take a lot of time
501 2016-07-21T19:33:08  <wumpus> gmaxwell: I didn't know, haven't seen much multisocket systems in recent times, I was hoping it was a crippled thing from the past :)
502 2016-07-21T19:33:24  <jtimon> so we should totally not touch ISM in any consensus refactor PR, but where the replacement should go is something we can discuss after the meeting
503 2016-07-21T19:33:38  <wumpus> in any case optimizing bitcoind for numa is very much out of scope :p
504 2016-07-21T19:33:56  *** GAit has joined #bitcoin-core-dev
505 2016-07-21T19:34:11  <btcdrak> we seem to have drifted off topic
506 2016-07-21T19:34:13  <wumpus> anything else to discuss?
507 2016-07-21T19:34:18  <NicolasDorier> #topic Handling Dust on the wallet
508 2016-07-21T19:34:32  <wumpus> hey, I'm supposed to set the topic
509 2016-07-21T19:34:37  <NicolasDorier> oh sorry :D
510 2016-07-21T19:34:40  <NicolasDorier> noob here
511 2016-07-21T19:34:40  <wumpus> (but no problem with this one)
512 2016-07-21T19:34:51  <gmaxwell> Has anyone picked up that simulator work and improved it?
513 2016-07-21T19:34:57  <sipa> it also does not work (for logs) if someone else than the chair does it
514 2016-07-21T19:35:08  <wumpus> #topic Handling Dust on the wallet
515 2016-07-21T19:35:23  <NicolasDorier> so the problem is boring: wallet code is preventing to create output below dust using ::txminRelayFee
516 2016-07-21T19:35:30  <jtimon> I think the ISM removal topic is mostly finished, TODO adapt any refactor for ISM to be removed before-hand, TODO decide where the replacement need to go during the refactor
517 2016-07-21T19:35:50  <NicolasDorier> problem is that when we bumped it long time ago, some transaction could not be relayed anymore
518 2016-07-21T19:36:05  <NicolasDorier> causing some stress to users
519 2016-07-21T19:36:16  <NicolasDorier> several way to fix the problem
520 2016-07-21T19:36:19  <jonasschnelli> You can if you add new/fresh larger coins? right?
521 2016-07-21T19:36:25  <jonasschnelli> (econimical painful)
522 2016-07-21T19:36:26  <morcos> NicolasDorier: I dont' have a good sense for how to make this work properly and be something the at doesnt involve fiddlign with a bunch of variables
523 2016-07-21T19:36:34  *** spudowiar has quit IRC
524 2016-07-21T19:36:38  <sipa> NicolasDorier: if all wallets at all times would not create outputs that were uneconomical to spend, there would be no issue, i think
525 2016-07-21T19:36:40  <luke-jr> I thought the wallet avoided change below some number much larger than dust?
526 2016-07-21T19:36:57  <MarcoFalke> yes
527 2016-07-21T19:36:59  <morcos> But I think its clear we should have the MinimumOutput be higher than the dust level, so that when we raise the dust level, we know prev releases are still not generating dust
528 2016-07-21T19:37:01  <NicolasDorier> luke-jr: problem is that it is not "much larger"
529 2016-07-21T19:37:05  <NicolasDorier> it is "exactly"
530 2016-07-21T19:37:08  <MarcoFalke> but this does not affect when you pay someone dust
531 2016-07-21T19:37:08  <luke-jr> NicolasDorier: 0.01 BTC last I checked
532 2016-07-21T19:37:09  <gmaxwell> This was intentional; not the stress of course, but not relaying transactions with produce outputs which are a loss to consume. But it sounds like you're not talking about the wallet, but relay behavior.
533 2016-07-21T19:37:26  <sipa> gmaxwell: no, this is about wallet
534 2016-07-21T19:37:32  <luke-jr> MarcoFalke: sure, but that's user error
535 2016-07-21T19:37:40  <gmaxwell> The wallet tries to produce change >0.01 btc as luke mentions. (which is its own stupidity, see my earlier simulator question)
536 2016-07-21T19:38:09  <NicolasDorier> oh ? I am surprised I did https://github.com/bitcoin/bitcoin/pull/8356  recently and it seemed using the ::minTxRelayFee
537 2016-07-21T19:38:14  <NicolasDorier> for calculating the smallest output
538 2016-07-21T19:38:15  <MarcoFalke> gmaxwell: I asked murch to present his findings of his masters thesis in one of the meetings
539 2016-07-21T19:38:32  <jonasschnelli> I think it should try much higher min change outputs if possible.
540 2016-07-21T19:38:38  <jtimon> btw, GetDustThreshold and IsDust are still in primitives/transaction.h (libconsensus), unrelated, but maybe cheap to do both at the same time
541 2016-07-21T19:38:39  <morcos> NicolasDorier: i also forgot about that 0.01 btc thing
542 2016-07-21T19:38:44  <jonasschnelli> We don't know the fees in – lets say – 2 years.
543 2016-07-21T19:38:47  <luke-jr> jonasschnelli: how much higher? this could be a privacy problem
544 2016-07-21T19:38:57  <gmaxwell> NicolasDorier: if select coins does not make an exact match, it attempts again with amount + 0.01 btc as the target.
545 2016-07-21T19:39:02  <luke-jr> jonasschnelli: we have fee learning logic..
546 2016-07-21T19:39:07  <jonasschnelli> luke-jr:If possible 1:1 like the spend itself
547 2016-07-21T19:39:09  <jonasschnelli> :-)
548 2016-07-21T19:39:14  <luke-jr> jonasschnelli: that harms privacy
549 2016-07-21T19:39:26  <jonasschnelli> (and would also not be possible)
550 2016-07-21T19:39:39  <gmaxwell> luke-jr: it can be done in ways which don't. Please see my comments on the remove extranious inputs PR.
551 2016-07-21T19:39:42  <NicolasDorier> gmaxwell: this is coin selection, but it does not prevent the creation of an output below 0.01 right ?
552 2016-07-21T19:39:58  <MarcoFalke> no
553 2016-07-21T19:40:18  <jtimon> luke-jr: please tell me "fee learning logic" is in policy/fees.o and not consensus/deeplearning.o
554 2016-07-21T19:40:20  <MarcoFalke> Those are different objectives to optimize
555 2016-07-21T19:40:24  <gmaxwell> NicolasDorier: it may not be possible to prevent that except by turning small amounts into fees.
556 2016-07-21T19:40:35  <luke-jr> jtimon: afaik yes
557 2016-07-21T19:40:56  <luke-jr> gmaxwell: if both outputs have the same or near-same value, any observer can see the approximate tx value, no?
558 2016-07-21T19:41:06  <jtimon> luke-jr: cool :)
559 2016-07-21T19:41:27  <gmaxwell> luke-jr: I'll explain more outside of the meeting.
560 2016-07-21T19:41:30  <luke-jr> ok
561 2016-07-21T19:41:34  <NicolasDorier> ok I'll need to study more about this 0.01 thing and the implication, will catch up with morcos
562 2016-07-21T19:41:58  <gmaxwell> the whole logic with that stuff is braindamaged imo.
563 2016-07-21T19:42:32  <NicolasDorier> I heard someone is doing some work in that area (Xekyo)
564 2016-07-21T19:42:44  <gmaxwell> manages to fail under every kind of metric I can come up with, except for consistency with the existing code. (which, unsurprisingly, is the property the tests test for... :) )
565 2016-07-21T19:42:56  <murch> marcofalke: My thesis is still in the making, sorry.
566 2016-07-21T19:43:00  <MarcoFalke> NicolasDorier: it's murch in this channel
567 2016-07-21T19:43:05  <NicolasDorier> oh ok
568 2016-07-21T19:44:02  <gmaxwell> okay, is there anything else?
569 2016-07-21T19:44:16  <wumpus> no proposed topics at lesat
570 2016-07-21T19:44:49  <kanzure> well, i am assembling a list of things to talk about in person
571 2016-07-21T19:44:55  <kanzure> similar to https://gist.github.com/kanzure/8d193f82aabd85eeba78a61815d3038d
572 2016-07-21T19:45:06  <kanzure> so i will be heckling some or most of you regarding proposed subjects
573 2016-07-21T19:45:18  <jtimon> well, you could talk more about that to close the meeting, no?
574 2016-07-21T19:45:26  <gmaxwell> wumpus:  I have a topic.
575 2016-07-21T19:45:38  <gmaxwell> wumpus: sigops max size, and the sigops per byte limit.
576 2016-07-21T19:45:43  <kanzure> jtimon: what would you like to hear?
577 2016-07-21T19:46:02  <wumpus> #topic  sigops max size, and the sigops per byte limit
578 2016-07-21T19:46:15  <luke-jr> (gmaxwell: btw, I have no strong opinions on the coin selection stuff, if it's one of those minutia you'd rather not spend time on.)
579 2016-07-21T19:46:26  <jtimon> kanzure: nothing specifically just things to talk about in person, I didn't folloed your link yet
580 2016-07-21T19:46:32  <gmaxwell> We have ongoing complaints that the bytespersigops limit has made some bare multsig outputs difficult to spend (normal software behavior won't work)
581 2016-07-21T19:46:54  <wumpus> this is about https://github.com/bitcoin/bitcoin/pull/8365?
582 2016-07-21T19:47:00  <gmaxwell> This was an unintended side effect of the limits put in to stop the sigops exhaustion spam attack.
583 2016-07-21T19:47:16  <luke-jr> we have a fix for that, which introduces a new concern; and a fix for the new concern, that slightly complicates fee estimation
584 2016-07-21T19:47:21  <gmaxwell> https://github.com/bitcoin/bitcoin/pull/8365 and https://github.com/bitcoin/bitcoin/pull/8364
585 2016-07-21T19:47:33  <gmaxwell> I don't agree with the position luke is taking.
586 2016-07-21T19:47:46  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8365
587 2016-07-21T19:47:49  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8364
588 2016-07-21T19:47:55  <jonasschnelli> Shouldn't this be included in 0.13 then?
589 2016-07-21T19:48:15  <luke-jr> jonasschnelli: probably
590 2016-07-21T19:48:21  <gmaxwell> It's unambigious why the limit was introduced. There is was a consensus sigops exhaustion attack resulting in small blocks.
591 2016-07-21T19:48:24  <sipa> i think 8365 should be in 0.13; i think 8364 is needless complication
592 2016-07-21T19:48:34  <sdaftuar> sipa: i agree
593 2016-07-21T19:48:38  <gmaxwell> 8365 corrects it in the way I originally proposed (so I like it)
594 2016-07-21T19:48:43  <sipa> (but apart from that i'm not strongly against 8364)
595 2016-07-21T19:48:52  <luke-jr> gmaxwell: that isn't why the limit was introduced, though.. it was to filter spam
596 2016-07-21T19:49:02  <wumpus> for 0.13 we should prefer a simple solution
597 2016-07-21T19:49:02  <sipa> luke-jr: in your world view perhaps
598 2016-07-21T19:49:20  <jonasschnelli> Im in favor of #8365 (at least for 0.13)
599 2016-07-21T19:49:23  <luke-jr> sipa: considering I wrote it..
600 2016-07-21T19:49:24  <gmaxwell> Luke proposes 8364 in addition, driven by a concern that allowing high sigops transactions but with high fees is sending an implicit endorsement that it's okay for random transactions to burn up lots of actual signature operations needlessly if they pay for it.
601 2016-07-21T19:49:25  <sdaftuar> the PR that introduced the limit lacks explanation
602 2016-07-21T19:49:52  <sipa> luke-jr: sure  it may have been your intention; that was certainly noy clear to me (or many, i think)
603 2016-07-21T19:50:00  <jtimon> is this about #8362 ?
604 2016-07-21T19:50:09  <sipa> luke-jr: i disagree that it helps at all with preventing spam, and only encourages further bloating
605 2016-07-21T19:50:11  <wumpus> sdaftuar: because it was a DoS fix
606 2016-07-21T19:50:23  <luke-jr> jtimon: no, 8364 and 8365
607 2016-07-21T19:50:36  <gmaxwell> It was extensively discussed in here. It's revisionist to suggest that it was merged for any reason other than consensus sigops exhaustion.
608 2016-07-21T19:50:47  <jtimon> luke-jr: thanks, scrolling back
609 2016-07-21T19:51:08  <gmaxwell> I wouldn't have supported it otherwise.
610 2016-07-21T19:51:38  <gmaxwell> In any case, 8365 corrects the issue though sdaftuar expressed some concern that it also causes small miscosting of a small amount of transactions.
611 2016-07-21T19:51:52  <gmaxwell> (since most of the time no sigops flooding attack is happening)
612 2016-07-21T19:52:21  <sdaftuar> gmaxwell: in the current form, #8365 sets the conversion at 20, not 50
613 2016-07-21T19:52:31  <sdaftuar> by default
614 2016-07-21T19:52:32  <luke-jr> I don't think we can solve that without a much more complicated change..?
615 2016-07-21T19:52:34  <CodeShark> luke-jr: I still adhere to the view that "spam" lacks a technical definition here
616 2016-07-21T19:52:52  <sdaftuar> so i think it's fine as is.  if another sigops attack were to hit the network, miners could bump it up to 50 and avoid being attacked
617 2016-07-21T19:53:00  <luke-jr> CodeShark: in this context, it is non-pubkey data fed to sigops as a key
618 2016-07-21T19:53:07  <sdaftuar> in its current form, users affected by the old policy have a better alternative to bloating up their transactions
619 2016-07-21T19:53:16  <wumpus> CodeShark: storing unnecessary data in the utxo set counts as spam to me
620 2016-07-21T19:53:22  <sdaftuar> we can think about better policies in the long run later, imo -- this is good enough for now
621 2016-07-21T19:54:05  <wumpus> sdaftuar: for 0.13 that's the most important
622 2016-07-21T19:54:08  <luke-jr> 8365 as-is, is a regression of used behaviour
623 2016-07-21T19:54:42  <sdaftuar> wumpus: yep agreed
624 2016-07-21T19:54:47  <CodeShark> wumpus: if someone is willing to pay for it it's income to someone else
625 2016-07-21T19:54:54  <sipa> luke-jr: as-is, i think it will have as sole effect that some people who are now bloating their transactions to bypass the limit, will stop doing so
626 2016-07-21T19:54:55  <gmaxwell> luke-jr: I don't agree that it is. since the change manages to except the counterparty data storage transactions, I'm not aware of anything that could be classified as spam that exists now that it usefully blocks.
627 2016-07-21T19:55:08  <wumpus> CodeShark: everyone with a full node suffers from it, without being paid for it
628 2016-07-21T19:55:27  <CodeShark> wumpus: that's a problem with incentives, not spam
629 2016-07-21T19:55:31  <wumpus> CodeShark: that's just like e-mail spam - everyone with an email account has to handle the extra messages
630 2016-07-21T19:55:42  <sipa> can we keep philosophical discussions for elsewhere?
631 2016-07-21T19:55:43  <luke-jr> gmaxwell: can you rephrase?
632 2016-07-21T19:56:41  <wumpus> uhm, okay
633 2016-07-21T19:56:50  <gmaxwell> luke-jr: point me to a transaction that 8364 would block that should be blocked? the only thing the sigopsperbyte limit was blocking was the sigops exhaust transactions (blocked by 8365) and counterparty data storage transactions, which 8364 jumps though enormous hoops to not block.
634 2016-07-21T19:57:53  <GitHub86> [bitcoin] jonasschnelli opened pull request #8390: [Wallet] Correct hdmasterkeyid/hdmasterkey name confusion (master...2016/07/hd_masterkeyrename) https://github.com/bitcoin/bitcoin/pull/8390
635 2016-07-21T19:58:16  <sipa> wumpus, CodeShark: sorry for interrupting, but i don't think you guys disagree at all - only about what certain words meam
636 2016-07-21T19:58:23  <luke-jr> gmaxwell: both of those should be blocked, and AFAIK 8365 doesn't block anything at all?
637 2016-07-21T19:58:46  <luke-jr> gmaxwell: (to be clear, Counterparty should be using OP_RETURN only for their data)
638 2016-07-21T19:58:47  <gmaxwell> luke-jr: 8365 closes the sigops bloat attack vector.
639 2016-07-21T19:58:57  <wumpus> only roughly one minute to go
640 2016-07-21T19:59:05  *** spudowiar has joined #bitcoin-core-dev
641 2016-07-21T19:59:11  <gmaxwell> I think we should close the meeting.
642 2016-07-21T19:59:15  <wumpus> #closemeeting
643 2016-07-21T19:59:17  <wumpus> #endmeeting
644 2016-07-21T19:59:17  <lightningbot> Meeting ended Thu Jul 21 19:59:17 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
645 2016-07-21T19:59:17  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-21-18.59.html
646 2016-07-21T19:59:17  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-21-18.59.txt
647 2016-07-21T19:59:17  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-21-18.59.log.html
648 2016-07-21T19:59:22  <luke-jr> gmaxwell: it just costs more to perform the attack?
649 2016-07-21T19:59:35  <gmaxwell> luke-jr: no, jesus chrsit luke. It _eliminates_ the attack.
650 2016-07-21T19:59:36  <sipa> luke-jr: ideally, they are disincntivized to be produced at all. but the current code (which blocks them) has as only result that they bloat their transactions to bypass the restriction
651 2016-07-21T20:00:44  <gmaxwell> luke-jr: The attack is that someone make a few small transactions that use up all the block capacity, while paying less than all the other users who were left waiting.
652 2016-07-21T20:00:52  *** aaaaa_ has joined #bitcoin-core-dev
653 2016-07-21T20:01:13  *** aaaaa_ has quit IRC
654 2016-07-21T20:01:20  <gmaxwell> if someone actually wants to outbid the other users and use up the block capacity, they can do that-- and nothign can stop them (except for eventually running out of funds to blow), which is how open markets work. :)
655 2016-07-21T20:01:59  <gmaxwell> 8365 fixes things so that users making weirdly shaped transactions can't use up capacity in excess of what they've paid for.
656 2016-07-21T20:02:24  *** cryptapus has quit IRC
657 2016-07-21T20:02:27  <gmaxwell> Thus no reason to create a weirdly shaped transaction.
658 2016-07-21T20:02:43  <sipa> gmaxwell: that would only be the case if the factor were 50, not 20... but it is the best we can do today without potentially impacting transaction relay
659 2016-07-21T20:03:02  *** murch has quit IRC
660 2016-07-21T20:03:14  <sipa> ok, i'm going to catch some pokemon
661 2016-07-21T20:03:16  <sipa> i mean
662 2016-07-21T20:03:20  <BlueMatt> .........
663 2016-07-21T20:03:20  <sipa> i'm going for a walk
664 2016-07-21T20:03:23  <luke-jr> lol
665 2016-07-21T20:03:30  <dstadulis> lol
666 2016-07-21T20:04:08  <gmaxwell> did sdaftuar measure the impact? or did we just gimp the fix on conjecture?
667 2016-07-21T20:05:17  <gmaxwell> I guess at 20 it's no more gimped than the code currently in place.
668 2016-07-21T20:05:23  <jonasschnelli> sipa: haha..I tried that once on my speedbike. Almost crashed in a car...
669 2016-07-21T20:05:43  <luke-jr> gmaxwell: ok, so how does 8365 close the data storage abuse vector, that bytespersigop used to at least make clear was abuse?
670 2016-07-21T20:06:45  *** laurentmt has quit IRC
671 2016-07-21T20:08:53  <gmaxwell> luke-jr: none of these things have any impact on data storage abuse.
672 2016-07-21T20:09:07  <sipa> luke-jr: clearly people dom't care about whether we consider it abuse or not
673 2016-07-21T20:09:09  <gmaxwell> non the bytespersigops, not 8364, not 8365.
674 2016-07-21T20:10:00  *** dstadulis has quit IRC
675 2016-07-21T20:10:12  <gmaxwell> bytespersigops had a accdential and coincidental negative effect on counterparty data storage transactions, that 8364 introduces a bunch of code to avoid (by counting signature operations instead of consensus sigops)
676 2016-07-21T20:10:12  <luke-jr> sipa: the OP_RETURN fiasco suggests otherwise, no?
677 2016-07-21T20:10:26  <jtimon> yeah I heard that pockemon thing is awesome and they're going to make a mario kart version soon in collaboration with google and tesla, but I can't find it on gihub, I'm searching on bitbucket next...
678 2016-07-21T20:11:00  <jtimon> sorry, #bitcoin
679 2016-07-21T20:11:10  <sipa> luke-jr: but OP_RETURN was a deliberately created alternatove for data storage
680 2016-07-21T20:11:33  <sipa> luke-jr: not blocking something intended to be a dos fix, that people perceive as accidentally stopping some transactions
681 2016-07-21T20:11:45  <luke-jr> no, it was created for commitments to external data, not storage :/
682 2016-07-21T20:11:47  <sipa> in the long term, we can't rely on any of these techniques
683 2016-07-21T20:12:05  <sipa> we can't expect people to behave nicely
684 2016-07-21T20:12:23  <sipa> but we can design systems that make some behaviour expensive, regardless of intent
685 2016-07-21T20:12:38  <sipa> and in the long term, that should be enough
686 2016-07-21T20:12:43  <gmaxwell> 80 bytes wasn't needed for 'commitments to external data'...
687 2016-07-21T20:13:19  <jtimon> luke-jr: IMO "the right way" ie pay2contractOrHash should replace the rpc interface for op_return
688 2016-07-21T20:13:30  <gmaxwell> there is no rpc interface to op_return.
689 2016-07-21T20:13:32  <sipa> furthermore, OP_RETURN probably actually did help us get rid of stuff that would otherwise permanently have been added to the utxo set (though i thonk at least the increase to 80 bytes was a mistake)
690 2016-07-21T20:15:46  <jtimon> gmaxwell: I have probably misunderstood https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L426 one time I was around without deeply reading...
691 2016-07-21T20:17:06  <luke-jr> sipa: the problem isn't OP_RETURN itself, but people portraying it as us endorsing data storage on-chain
692 2016-07-21T20:17:07  <gmaxwell> jtimon: you were right, I had no clue that was there. wtf.
693 2016-07-21T20:17:27  *** murch has joined #bitcoin-core-dev
694 2016-07-21T20:18:09  <gmaxwell> jtimon: result of PR #6346
695 2016-07-21T20:18:57  <gmaxwell> I give up.
696 2016-07-21T20:18:59  *** gmaxwell has left #bitcoin-core-dev
697 2016-07-21T20:19:26  <jtimon> gmaxwell: oh, awesome, thanks, traceability++, shall you comment in 6346 ?
698 2016-07-21T20:19:59  <midnightmagic> he left.
699 2016-07-21T20:22:40  <midnightmagic> whoah
700 2016-07-21T20:22:59  <midnightmagic> how did commitid d7078533ebd32bb5071f4dba8e3d9c5a3b1f0d4c get merged
701 2016-07-21T20:24:38  <sipa> luke-jr: i'm aware
702 2016-07-21T20:25:31  <jtimon> I only saw that when doing a one old version of elements thing for assets, I assumed this was known by everyone since I was unfamiliar with rpc in general
703 2016-07-21T20:25:48  *** Ylbam has quit IRC
704 2016-07-21T20:26:33  <jtimon> I was mostly only familliar to the rawtx prc which I was modifying
705 2016-07-21T20:26:44  <jtimon> s/prc/rpc
706 2016-07-21T20:27:43  <jtimon> I just looked weird at the op_return and moved on
707 2016-07-21T20:28:00  *** fengling has joined #bitcoin-core-dev
708 2016-07-21T20:28:15  *** netsin has joined #bitcoin-core-dev
709 2016-07-21T20:28:24  <sipa> heh, i don't remember seeing that PR
710 2016-07-21T20:29:11  <midnightmagic> me neither. I can't tell people not to use OP_RETURN anymore.
711 2016-07-21T20:29:50  <btcdrak> Counterparty are about to stuff Ethereum contracts into them :-p
712 2016-07-21T20:30:08  <sipa> counterparty isn't using our rpc interface
713 2016-07-21T20:30:13  <midnightmagic> you reviewed it and ACK'd it
714 2016-07-21T20:30:29  * btcdrak sniggers at the back of the room
715 2016-07-21T20:31:24  *** sipa has left #bitcoin-core-dev
716 2016-07-21T20:32:46  *** fengling has quit IRC
717 2016-07-21T20:33:09  <jtimon> let's put effort in the fix before tha blame, please, even if git blame is the source of all fixes
718 2016-07-21T20:34:03  *** netsin has quit IRC
719 2016-07-21T20:34:15  *** murch has quit IRC
720 2016-07-21T20:36:23  *** MarcoFalke has left #bitcoin-core-dev
721 2016-07-21T20:38:35  *** TomMc has joined #bitcoin-core-dev
722 2016-07-21T20:39:02  *** sipa has joined #bitcoin-core-dev
723 2016-07-21T20:39:30  *** netsin has joined #bitcoin-core-dev
724 2016-07-21T20:43:47  <instagibbs> I'm guessing the amount of op_return data via that interface is really tiny...
725 2016-07-21T20:44:03  <instagibbs> I only found out about it last week
726 2016-07-21T20:44:12  <sipa> yes, seems nobody even knew about it...
727 2016-07-21T20:44:44  <jtimon> I guess so too, that's how I thought it was allowed, but if there's nobody agains, we should really get this out
728 2016-07-21T20:45:31  <jtimon> I mean, it's in the "standard" policy, but I consensus first, policy later
729 2016-07-21T20:52:11  *** netsin has quit IRC
730 2016-07-21T21:05:26  <sipa> wumpus: good news: yield() doesn't seem to affect performance noticable (i didn't do an extensive benchmark, but early in the chain but:
731 2016-07-21T21:05:29  <sipa> 2016-07-21 21:03:48 UpdateTip: new best=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2009-01-03 18:15:05' progr
732 2016-07-21T21:05:33  <sipa> ess=0.000000 cache=0.0MiB(0tx)
733 2016-07-21T21:05:44  <sipa> 2016-07-21 21:04:34 UpdateTip: new best=000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506 height=100000 version=0x00000001 log2_work=58.648173 tx=216577 date='2010-12-29 11:57:43' progress=0.000755 cache=23.4MiB(119863tx)
734 2016-07-21T21:06:38  <sipa> with 2173 blocks per second, i doubt we're losing much cpu time
735 2016-07-21T21:07:19  <sipa> wumpus: the bad news: it doesn't fix the 'Loading block index' message during activation
736 2016-07-21T21:07:26  <sipa> oh, wait, that's expected maybe
737 2016-07-21T21:07:33  <sipa> instead of showing something about banlist
738 2016-07-21T21:14:40  <sipa> bad news is that i can't reproduce the bug, i guess
739 2016-07-21T21:19:53  *** GAit has quit IRC
740 2016-07-21T21:19:55  *** gabridome has joined #bitcoin-core-dev
741 2016-07-21T21:20:23  *** GAit has joined #bitcoin-core-dev
742 2016-07-21T21:25:10  *** gabridome has quit IRC
743 2016-07-21T21:29:12  *** netsin has joined #bitcoin-core-dev
744 2016-07-21T21:29:30  *** fengling has joined #bitcoin-core-dev
745 2016-07-21T21:34:26  *** fengling has quit IRC
746 2016-07-21T21:52:22  *** netsin has quit IRC
747 2016-07-21T21:59:31  <NicolasDorier> I am trying to remove ISM right now... however, I'm hitting problems with tests testing the ISM logic for old soft fork. Especially, normal ISM have two phase, activation (at 75% new rules are enforced for block version X) and version enforcement (at 95% if nVersion < X, reject). However, the difference between both threshold is only relevant during  the
748 2016-07-21T21:59:31  <NicolasDorier> transition between the two thresholds and a few block afterward. We can safely replace the activations checks by enforcement checks.... Except that if I do that, then tests rightly break...
749 2016-07-21T21:59:48  <NicolasDorier> I'm tempted to just remove the old ISM sf tests
750 2016-07-21T22:00:08  <NicolasDorier> and make regnet with all the ISM SF activated from block 0
751 2016-07-21T22:00:15  <NicolasDorier> I mean block 1
752 2016-07-21T22:00:30  <NicolasDorier> thought ?
753 2016-07-21T22:01:24  <sipa> for regtest we probably need command line switches to set what is activated (and at what height?)
754 2016-07-21T22:01:59  <NicolasDorier> mh it seems rather bothersome for code going away
755 2016-07-21T22:03:24  <NicolasDorier> I'd like ideally to remove old ISM SF tests, and default regnet to have everything activated from block 1. Adding those command line switches just so the old tests continue to work seems like a waste
756 2016-07-21T22:04:32  <NicolasDorier> or maybe hard coding some number for regtest
757 2016-07-21T22:04:35  <NicolasDorier> and testing that
758 2016-07-21T22:04:48  <NicolasDorier> hard coding some heights
759 2016-07-21T22:06:32  <luke-jr> sipa: I knew about it, but didn't strongly oppose it on the basis that createrawtransaction is a low-level thing that users shouldn't be exposed to anyway. And I was hoping for the author to add more useful tools (contracthash-like), but that didn't get added. ☹
760 2016-07-21T22:08:55  <sipa> luke-jr: it would have been nice if it hashed the data first
761 2016-07-21T22:09:23  <sipa> luke-jr: but i guess it's hard to change now
762 2016-07-21T22:09:44  <sipa> NicolasDorier: i agree... old ISM tests can probably go away
763 2016-07-21T22:10:05  <sipa> NicolasDorier: though only those testing activation... not those testing the new behaviour
764 2016-07-21T22:10:21  <NicolasDorier> yes
765 2016-07-21T22:11:09  <luke-jr> sipa: yes, but then there'd be no marker possible for example
766 2016-07-21T22:12:49  <luke-jr> sipa: as soon as libsecp256k1 has contract-sign primitives though, I hope to put it to use to hopefully kill off proof-of-existence spam ;p
767 2016-07-21T22:15:36  <btcdrak> luke-jr: how would that work?
768 2016-07-21T22:16:37  <sipa> btcdrak: we can make a signature commit to data
769 2016-07-21T22:16:42  <sipa> like a hash
770 2016-07-21T22:16:53  <sipa> except it independently also remains a valid signature
771 2016-07-21T22:17:03  <sipa> and you can't even tell it commits to something
772 2016-07-21T22:17:10  <btcdrak> oh
773 2016-07-21T22:17:28  <btcdrak> this sounds like black magic...
774 2016-07-21T22:17:33  <sipa> the commitment is obvious to anyone who knows the data being committed to
775 2016-07-21T22:17:46  <luke-jr> add a merkle tree, and you can do unlimited proof-of-existence in the background when you send txs
776 2016-07-21T22:18:06  <luke-jr> even fingerprint your wallet so you can prove its state at any given point in history, if you want to
777 2016-07-21T22:18:57  <sipa> luke-jr: unfortunately, very few people seem interested in timestamping, and many seem to be interested in using the blockchain as a broadcast medium
778 2016-07-21T22:19:30  <luke-jr> well, maybe we should add a p2p mechanism that relays data along with tx so long as the tx fee pays for the data size too?
779 2016-07-21T22:20:40  <sipa> or find a way to actually make the payment protocol take off, so all that stuff can just remain between sender and receiver?
780 2016-07-21T22:20:56  <luke-jr> I'm not sure that stuff has a sender/receiver >_<
781 2016-07-21T22:22:15  <sipa> if it doesn't, then why does it belong in bitcoin?
782 2016-07-21T22:22:47  <sipa> either it's data needef for the world to verify the transaction, or it is private information between sender and receiver of a payment
783 2016-07-21T22:23:12  <luke-jr> it doesn't. :<
784 2016-07-21T22:24:35  *** frankenmint has joined #bitcoin-core-dev
785 2016-07-21T22:24:53  * luke-jr wonders what it would take to get p2sh^2 deployed and in use
786 2016-07-21T22:31:21  *** fengling has joined #bitcoin-core-dev
787 2016-07-21T22:34:21  <sipa> luke-jr: people would move to storing data in inputs
788 2016-07-21T22:35:04  *** frankenmint has quit IRC
789 2016-07-21T22:36:06  *** fengling has quit IRC
790 2016-07-21T22:36:31  *** frankenmint has joined #bitcoin-core-dev
791 2016-07-21T22:40:42  *** netsin has joined #bitcoin-core-dev
792 2016-07-21T22:41:22  *** frankenmint has quit IRC
793 2016-07-21T22:43:23  *** frankenmint has joined #bitcoin-core-dev
794 2016-07-21T22:54:48  *** CubicEarth has joined #bitcoin-core-dev
795 2016-07-21T22:55:40  <luke-jr> sipa: where in policy-accepted inputs can data be stored?
796 2016-07-21T22:56:05  <luke-jr> wait, forgot we allow any script now
797 2016-07-21T22:56:16  <luke-jr> we could potentially lock that down again?
798 2016-07-21T22:56:42  *** GAit has quit IRC
799 2016-07-21T22:59:34  *** d_t has quit IRC
800 2016-07-21T23:12:03  *** Guyver2 has quit IRC
801 2016-07-21T23:26:30  *** jtimon has quit IRC
802 2016-07-21T23:30:26  *** Giszmo has quit IRC
803 2016-07-21T23:32:37  *** fengling has joined #bitcoin-core-dev
804 2016-07-21T23:37:26  *** fengling has quit IRC
805 2016-07-21T23:40:30  <GitHub100> [bitcoin] NicolasDorier opened pull request #8391: Consensus: Remove ISM (master...remove-ism) https://github.com/bitcoin/bitcoin/pull/8391
806 2016-07-21T23:41:14  <NicolasDorier> lightly tested, surely as flaws... specially as I wasted my night on it. :o