1 2016-08-04T00:00:09  *** ennui has joined #bitcoin-core-dev
  2 2016-08-04T00:07:50  *** justanotheruser has quit IRC
  3 2016-08-04T00:12:13  *** justanotheruser has joined #bitcoin-core-dev
  4 2016-08-04T00:20:55  *** fengling has joined #bitcoin-core-dev
  5 2016-08-04T00:21:35  *** grubles has quit IRC
  6 2016-08-04T00:25:46  *** fengling has quit IRC
  7 2016-08-04T00:27:13  *** Guyver2 has quit IRC
  8 2016-08-04T00:36:01  *** Giszmo has quit IRC
  9 2016-08-04T00:38:02  *** ennui has quit IRC
 10 2016-08-04T00:39:29  *** ennui has joined #bitcoin-core-dev
 11 2016-08-04T00:47:01  *** Ylbam_ has joined #bitcoin-core-dev
 12 2016-08-04T00:47:33  *** Ylbam has quit IRC
 13 2016-08-04T00:47:33  *** Ylbam_ is now known as Ylbam
 14 2016-08-04T00:48:24  *** ennui has quit IRC
 15 2016-08-04T00:55:21  *** belcher has quit IRC
 16 2016-08-04T01:09:50  *** aureianimus_ has quit IRC
 17 2016-08-04T01:16:57  <GitHub184> [bitcoin] sipa opened pull request #8451: Get rid of the const field in CTransaction (master...noconsttx) https://github.com/bitcoin/bitcoin/pull/8451
 18 2016-08-04T01:22:36  *** fengling has joined #bitcoin-core-dev
 19 2016-08-04T01:25:50  *** Ylbam has quit IRC
 20 2016-08-04T01:27:26  *** fengling has quit IRC
 21 2016-08-04T01:45:08  *** spudowiar has quit IRC
 22 2016-08-04T01:48:00  *** spudowiar has joined #bitcoin-core-dev
 23 2016-08-04T02:06:24  *** jtimon has quit IRC
 24 2016-08-04T02:16:59  *** FNinTak has joined #bitcoin-core-dev
 25 2016-08-04T02:23:53  <GitHub106> [bitcoin] sipa opened pull request #8452: Code simplification: inline CTxInWitness inside CTxIn (master...segwitinline) https://github.com/bitcoin/bitcoin/pull/8452
 26 2016-08-04T02:24:10  *** fengling has joined #bitcoin-core-dev
 27 2016-08-04T02:28:26  *** fengling has quit IRC
 28 2016-08-04T02:43:36  *** spudowiar has quit IRC
 29 2016-08-04T02:51:07  *** spudowiar has joined #bitcoin-core-dev
 30 2016-08-04T02:51:27  *** spudowiar has joined #bitcoin-core-dev
 31 2016-08-04T02:53:45  *** JackH has joined #bitcoin-core-dev
 32 2016-08-04T02:59:18  <phantomcircuit> wumpus, replaced that wallet test with a python one
 33 2016-08-04T02:59:32  <phantomcircuit> i think it actually covers more of the behavior than it did before but im going to go and check
 34 2016-08-04T03:00:22  <phantomcircuit> hmm im not testing addmultisigaddress
 35 2016-08-04T03:00:36  *** NLNico has joined #bitcoin-core-dev
 36 2016-08-04T03:00:44  <phantomcircuit> but that's already being tested in other places
 37 2016-08-04T03:01:12  <phantomcircuit> although not that it works with accounts
 38 2016-08-04T03:04:18  *** Chris_Stewart_5 has quit IRC
 39 2016-08-04T03:06:25  *** hsmiths has quit IRC
 40 2016-08-04T03:06:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 41 2016-08-04T03:10:25  *** hsmiths has joined #bitcoin-core-dev
 42 2016-08-04T03:12:11  *** Alopex has quit IRC
 43 2016-08-04T03:13:19  *** Alopex has joined #bitcoin-core-dev
 44 2016-08-04T03:14:07  *** Chris_Stewart_5 has quit IRC
 45 2016-08-04T03:24:53  *** fengling has joined #bitcoin-core-dev
 46 2016-08-04T03:29:47  *** fengling has quit IRC
 47 2016-08-04T03:35:17  *** spudowiar has quit IRC
 48 2016-08-04T03:46:02  *** jgarzik has joined #bitcoin-core-dev
 49 2016-08-04T03:46:02  *** jgarzik has joined #bitcoin-core-dev
 50 2016-08-04T03:53:34  *** pmienk has quit IRC
 51 2016-08-04T04:06:15  *** pmienk has joined #bitcoin-core-dev
 52 2016-08-04T04:25:50  *** FNinTak has quit IRC
 53 2016-08-04T04:27:03  *** fengling has joined #bitcoin-core-dev
 54 2016-08-04T04:31:46  *** fengling has quit IRC
 55 2016-08-04T04:50:28  *** d_t has joined #bitcoin-core-dev
 56 2016-08-04T04:55:03  *** d_t has quit IRC
 57 2016-08-04T05:28:47  *** fengling has joined #bitcoin-core-dev
 58 2016-08-04T05:33:06  *** fengling has quit IRC
 59 2016-08-04T05:39:04  *** teslax has joined #bitcoin-core-dev
 60 2016-08-04T05:39:14  *** teslax has left #bitcoin-core-dev
 61 2016-08-04T05:48:15  *** opz has quit IRC
 62 2016-08-04T06:28:27  *** fengling has joined #bitcoin-core-dev
 63 2016-08-04T06:35:27  *** jgarzik has quit IRC
 64 2016-08-04T06:51:09  *** luke-jr has quit IRC
 65 2016-08-04T06:51:48  *** luke-jr has joined #bitcoin-core-dev
 66 2016-08-04T06:52:44  *** BashCo_ has quit IRC
 67 2016-08-04T06:53:20  *** d_t has joined #bitcoin-core-dev
 68 2016-08-04T07:13:52  *** BashCo has joined #bitcoin-core-dev
 69 2016-08-04T07:19:46  *** luke-jr has quit IRC
 70 2016-08-04T07:19:54  *** luke-jr has joined #bitcoin-core-dev
 71 2016-08-04T07:23:42  *** laurentmt has joined #bitcoin-core-dev
 72 2016-08-04T07:27:22  *** d_t has quit IRC
 73 2016-08-04T07:36:20  *** jgarzik has joined #bitcoin-core-dev
 74 2016-08-04T08:13:18  *** d_t has joined #bitcoin-core-dev
 75 2016-08-04T08:25:52  *** MarcoFalke has joined #bitcoin-core-dev
 76 2016-08-04T08:50:45  <wumpus> phantomcircuit: nice!
 77 2016-08-04T08:53:41  <wumpus> sipa: the last update of secp256k1 has been ~9 months ago (6c527ec), is it maybe time to update the subtree again? At least the (experimental) ARM assembly has been merged since
 78 2016-08-04T08:54:50  <sipa> wumpus: good idea
 79 2016-08-04T08:55:26  <sipa> there are certainly no regressions known that would make the current master less appropriate than the subtree in bitcoin currently
 80 2016-08-04T08:56:07  <wumpus> exactly, I did mean for master, not 0.13
 81 2016-08-04T08:57:05  <sipa> sure
 82 2016-08-04T08:58:47  *** Ayhan has joined #bitcoin-core-dev
 83 2016-08-04T09:03:44  *** Giszmo has joined #bitcoin-core-dev
 84 2016-08-04T09:04:02  *** Ayhan has quit IRC
 85 2016-08-04T09:08:38  *** Guyver2 has joined #bitcoin-core-dev
 86 2016-08-04T09:18:39  *** Lauda has quit IRC
 87 2016-08-04T09:19:06  *** Lauda has joined #bitcoin-core-dev
 88 2016-08-04T09:25:45  <GitHub30> [bitcoin] laanwj opened pull request #8453: Bring secp256k1 subtree up to date with master (master...2016_08_update_secp256k1) https://github.com/bitcoin/bitcoin/pull/8453
 89 2016-08-04T09:43:59  *** berndj has quit IRC
 90 2016-08-04T09:44:32  *** NLNico has quit IRC
 91 2016-08-04T09:48:12  *** aureianimus_ has joined #bitcoin-core-dev
 92 2016-08-04T10:07:01  *** spudowiar has joined #bitcoin-core-dev
 93 2016-08-04T10:21:19  <GitHub18> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5c7a5e1f66d8...37d83bb0a980
 94 2016-08-04T10:21:19  <GitHub18> bitcoin/master 122786d NicolasDorier: Consensus: Remove ISM
 95 2016-08-04T10:21:20  <GitHub18> bitcoin/master 37d83bb Wladimir J. van der Laan: Merge #8391: Consensus: Remove ISM...
 96 2016-08-04T10:21:25  <GitHub105> [bitcoin] laanwj closed pull request #8391: Consensus: Remove ISM (master...remove-ism) https://github.com/bitcoin/bitcoin/pull/8391
 97 2016-08-04T10:22:36  *** spudowiar has quit IRC
 98 2016-08-04T10:26:32  *** MarcoFalke has left #bitcoin-core-dev
 99 2016-08-04T10:34:02  <GitHub46> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/37d83bb0a980...f97d335942ae
100 2016-08-04T10:34:03  <GitHub46> bitcoin/master 0fd2a33 Pieter Wuille: Use a signal to continue init after genesis activation
101 2016-08-04T10:34:03  <GitHub46> bitcoin/master aa59f2e Pieter Wuille: Add extra message to avoid a long 'Loading banlist'
102 2016-08-04T10:34:04  <GitHub46> bitcoin/master 9d4eb9a Pieter Wuille: Do diskspace check before import thread is started
103 2016-08-04T10:34:11  <GitHub154> [bitcoin] laanwj closed pull request #8392: Fix several node initialization issues (master...fixactivatewait) https://github.com/bitcoin/bitcoin/pull/8392
104 2016-08-04T10:42:47  *** d_t has quit IRC
105 2016-08-04T10:46:53  *** rubensayshi has joined #bitcoin-core-dev
106 2016-08-04T10:49:58  *** laurentmt has quit IRC
107 2016-08-04T10:52:53  *** Cory has quit IRC
108 2016-08-04T10:53:32  <paveljanik> wumpus, do you use gmp? string.h is included in num_gmp_impl.h... This could be difference.
109 2016-08-04T10:54:57  <wumpus> yes, that could be it
110 2016-08-04T10:55:45  <wumpus> will try with bignum=no
111 2016-08-04T10:55:59  <wumpus> yes, that does it
112 2016-08-04T10:56:29  *** laurentmt has joined #bitcoin-core-dev
113 2016-08-04T10:57:32  *** Cory has joined #bitcoin-core-dev
114 2016-08-04T11:02:14  <wumpus> paveljanik: https://github.com/bitcoin-core/secp256k1/pull/410
115 2016-08-04T11:12:09  *** randy-waterhouse has quit IRC
116 2016-08-04T11:14:40  *** laurentmt has quit IRC
117 2016-08-04T11:15:11  *** laurentmt has joined #bitcoin-core-dev
118 2016-08-04T11:17:20  <paveljanik> thanks!
119 2016-08-04T11:31:30  <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f97d335942ae...6e6ab2c32382
120 2016-08-04T11:31:31  <GitHub189> bitcoin/master 2c517b3 Suhas Daftuar: Fix p2p-feefilter.py for changed tx relay behavior
121 2016-08-04T11:31:31  <GitHub189> bitcoin/master 6e6ab2c Wladimir J. van der Laan: Merge #8444: Fix p2p-feefilter.py for changed tx relay behavior...
122 2016-08-04T11:31:40  <GitHub87> [bitcoin] laanwj closed pull request #8444: Fix p2p-feefilter.py for changed tx relay behavior (master...fix-feefilter-test) https://github.com/bitcoin/bitcoin/pull/8444
123 2016-08-04T11:35:06  <paveljanik> wumpus, in fact, the fix is not upstream, but side-stream ;-)
124 2016-08-04T11:35:42  <wumpus> well I hope it can be merged soon, I'll update #8453 after that
125 2016-08-04T11:36:19  <wumpus> bah I'd really feel better without expat in the depends :)
126 2016-08-04T11:37:36  *** cjcj has joined #bitcoin-core-dev
127 2016-08-04T11:43:11  *** cryptapus has joined #bitcoin-core-dev
128 2016-08-04T11:43:11  *** cryptapus has joined #bitcoin-core-dev
129 2016-08-04T11:54:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
130 2016-08-04T12:02:55  *** berndj has joined #bitcoin-core-dev
131 2016-08-04T12:26:06  *** fengling has quit IRC
132 2016-08-04T12:26:08  <GitHub129> [bitcoin] MarcoFalke opened pull request #8454: [0.13.1] Fix p2p-feefilter.py for changed tx relay behavior (0.13...Mf1608-qaFeeFilter013) https://github.com/bitcoin/bitcoin/pull/8454
133 2016-08-04T12:40:45  <GitHub71> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/d485a6c5a8d238cac5ad732ce9e744f4b121143c
134 2016-08-04T12:40:45  <GitHub71> bitcoin/0.13 d485a6c Wladimir J. van der Laan: doc: Add list of new and removed RPC commands to release notes...
135 2016-08-04T12:41:43  <wumpus> sipa: do you still plan on writing something for the release notes about -reindex-chainstate?
136 2016-08-04T12:45:55  <wumpus> I've added a list of added and removed and changed RPC calls, which means that #7678 can almost be closed, leaving -maxtimeadjust and -reindex-chainstate, of which I think reindex-chainstate (and the changed reindexing in general) is most relevant
137 2016-08-04T12:56:46  *** Guyver2 has quit IRC
138 2016-08-04T12:59:13  *** fengling has joined #bitcoin-core-dev
139 2016-08-04T12:59:33  *** Chris_Stewart_5 has quit IRC
140 2016-08-04T13:04:06  *** fengling has quit IRC
141 2016-08-04T13:06:49  *** BashCo has quit IRC
142 2016-08-04T13:06:55  *** BashCo_ has joined #bitcoin-core-dev
143 2016-08-04T13:29:29  *** zooko has joined #bitcoin-core-dev
144 2016-08-04T13:33:30  *** laurentmt1 has joined #bitcoin-core-dev
145 2016-08-04T13:34:36  *** laurentmt has quit IRC
146 2016-08-04T13:34:36  *** laurentmt1 is now known as laurentmt
147 2016-08-04T13:52:38  <GitHub198> [bitcoin] mrbandrews opened pull request #8456: [RPC] Simplified bumpfee command. (master...ba-rpcbumpfee) https://github.com/bitcoin/bitcoin/pull/8456
148 2016-08-04T14:00:26  *** mkarrer has quit IRC
149 2016-08-04T14:00:34  *** fengling has joined #bitcoin-core-dev
150 2016-08-04T14:01:11  *** mkarrer has joined #bitcoin-core-dev
151 2016-08-04T14:05:26  *** fengling has quit IRC
152 2016-08-04T14:20:29  *** spudowiar has joined #bitcoin-core-dev
153 2016-08-04T14:33:02  *** Guyver2 has joined #bitcoin-core-dev
154 2016-08-04T15:00:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
155 2016-08-04T15:02:07  *** fengling has joined #bitcoin-core-dev
156 2016-08-04T15:07:06  *** fengling has quit IRC
157 2016-08-04T15:35:01  *** aalex has joined #bitcoin-core-dev
158 2016-08-04T15:53:26  *** BashCo_ has quit IRC
159 2016-08-04T15:54:06  *** BashCo has joined #bitcoin-core-dev
160 2016-08-04T16:02:45  *** Chris_Stewart_5 has quit IRC
161 2016-08-04T16:03:39  *** fengling has joined #bitcoin-core-dev
162 2016-08-04T16:04:09  *** BashCo has quit IRC
163 2016-08-04T16:08:26  *** fengling has quit IRC
164 2016-08-04T16:17:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
165 2016-08-04T16:24:52  <GitHub160> [bitcoin] pedrobranco opened pull request #8457: Add block height support in rpc call getblock (master...feature/add-get-block-by-number) https://github.com/bitcoin/bitcoin/pull/8457
166 2016-08-04T16:30:42  *** rubensayshi has quit IRC
167 2016-08-04T16:30:45  *** BashCo has joined #bitcoin-core-dev
168 2016-08-04T16:32:38  *** saurb has joined #bitcoin-core-dev
169 2016-08-04T16:33:47  *** saurb has quit IRC
170 2016-08-04T16:41:58  *** jtimon has joined #bitcoin-core-dev
171 2016-08-04T16:45:55  <sipa> wumpus: ack, will write
172 2016-08-04T16:46:05  *** laurentmt has quit IRC
173 2016-08-04T17:03:21  *** Guyver2 has quit IRC
174 2016-08-04T17:05:09  *** fengling has joined #bitcoin-core-dev
175 2016-08-04T17:06:00  *** zooko has quit IRC
176 2016-08-04T17:08:34  *** Guyver2 has joined #bitcoin-core-dev
177 2016-08-04T17:10:06  *** fengling has quit IRC
178 2016-08-04T17:26:46  *** laurentmt has joined #bitcoin-core-dev
179 2016-08-04T17:27:46  *** shaiguit1r has joined #bitcoin-core-dev
180 2016-08-04T17:30:04  *** shaiguitar has quit IRC
181 2016-08-04T17:46:40  *** Chris_Stewart_5 has quit IRC
182 2016-08-04T17:52:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
183 2016-08-04T18:07:25  *** fengling has joined #bitcoin-core-dev
184 2016-08-04T18:08:12  <instagibbs> during salvage on an unbroken wallet.dat file I'm seeing keys getting skipped
185 2016-08-04T18:08:16  <instagibbs> on master
186 2016-08-04T18:08:49  <instagibbs> 0-4 keys on a fresh wallet with keypool 100, randomly
187 2016-08-04T18:09:21  <gmaxwell> I've said before that salvagewallet should be called "savagewallet".
188 2016-08-04T18:09:29  <gmaxwell> instagibbs: can you figure out why?
189 2016-08-04T18:09:40  <instagibbs> no ive been trying to chase it down all day
190 2016-08-04T18:10:19  <instagibbs> it's very random, and only happens once every 25+ keys
191 2016-08-04T18:10:51  <gmaxwell> presumably you've filled up the salvage code with instrumentation to see where they're getting dropped? (e.g. does bdb just never hand them to us?)
192 2016-08-04T18:11:11  *** gabridome has joined #bitcoin-core-dev
193 2016-08-04T18:11:11  <instagibbs> it's an error thrown when doing >> for private key
194 2016-08-04T18:11:22  <instagibbs> "key" type, trying to deserialize the key
195 2016-08-04T18:11:26  <instagibbs> priv*
196 2016-08-04T18:11:32  <sipa> is it trying to deserialize master key data as the wrong type?
197 2016-08-04T18:11:46  *** fengling has quit IRC
198 2016-08-04T18:13:48  <instagibbs> I don't think so, as keypool=1 almost never has it happen
199 2016-08-04T18:14:06  <instagibbs> I've never had it happen with keypool 1, that is to say
200 2016-08-04T18:16:13  *** Chris_Stewart_5 has quit IRC
201 2016-08-04T18:19:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
202 2016-08-04T18:20:14  *** jtimon has quit IRC
203 2016-08-04T18:20:23  *** gabridome has quit IRC
204 2016-08-04T18:20:36  *** telelvis has joined #bitcoin-core-dev
205 2016-08-04T18:22:07  <wumpus> instagibbs: can you upload the wallet somewhere that it happens with?
206 2016-08-04T18:23:15  <instagibbs> it's literally a fresh wallet, start up bitcoind in regtest, stop, start back up with salvagewallet. Some not small % of time i get those messages
207 2016-08-04T18:23:25  <instagibbs> but yes I can upload one
208 2016-08-04T18:23:28  <wumpus> it's a known issue btw: salvagewallet drops valid keys #7379   but I've never had it happen to me
209 2016-08-04T18:24:10  <wumpus> another similar problem is salvagewallet fails verification #7463 , salvagewallet on an uncorrupted wallet sometimes makes bdb return errors
210 2016-08-04T18:24:35  <wumpus> so what you are seeing may be similar, I noticed that problem, just never saw keys being dropped
211 2016-08-04T18:25:04  <instagibbs> 2016-08-04 18:07:42 Salvage(aggressive) found 439 records
212 2016-08-04T18:25:04  <instagibbs> 2016-08-04 18:07:42 WARNING: CWalletDB::Recover skipping key:
213 2016-08-04T18:25:07  <wumpus> I would not be surprised if bdb's "aggressive" salvage sometimes returns crap or misses records
214 2016-08-04T18:25:35  <instagibbs> oh is it an actual bdb mode? That might explain the difference
215 2016-08-04T18:27:03  <gmaxwell> maybe it should run twice, once normally without any bdb magig, and then again in agressive mode?
216 2016-08-04T18:27:25  <gmaxwell> "never do worse than simply reading it."
217 2016-08-04T18:27:28  <wumpus> I don't know if that makes a difference, but worth a try
218 2016-08-04T18:27:43  <instagibbs> i can try that, if i figure out the settings
219 2016-08-04T18:27:56  <gmaxwell> well presumably it must, after all we don't miss those keys during normal reads without salvaging.
220 2016-08-04T18:29:09  <wumpus> ooh! those may be ghost keys instagibbs
221 2016-08-04T18:29:12  <wumpus> "Output all the key/data pairs in the file that can be found. By default, DB->verify() does not assume corruption. For example, if a key/data pair on a page is marked as deleted, it is not then written to the output file. When DB_AGGRESSIVE is specified, corruption is assumed, and any key/data pair that can be found is written. In this case, key/data pairs that are corrupted or have been deleted may appear in the output (even
222 2016-08-04T18:29:13  <wumpus> if the file being salvaged is in no way corrupt), and the output will almost certainly require editing before being loaded into a database."
223 2016-08-04T18:29:34  <instagibbs> i aint afraid of no ghost
224 2016-08-04T18:29:34  <wumpus> aggressive should return *more* records, but some of them may be deleted, or not really exist at all
225 2016-08-04T18:29:55  <cfields> sipa: mm, I just noticed that 0.13 doesn't enable asm for osx due to secp256k1 #373 :\
226 2016-08-04T18:30:44  <wumpus> *even if the file being salvaged is in no way corrupt* is the important part there
227 2016-08-04T18:30:56  <instagibbs> so how can we test that
228 2016-08-04T18:31:04  <wumpus> so yes, trying to salvage without aggressive makes sense first
229 2016-08-04T18:32:20  <wumpus> but how can we detect if keys have been dropped due to corruption, which would appear with salvage aggressive? I don't know
230 2016-08-04T18:32:41  <wumpus> yes you don't really know, that's the problem
231 2016-08-04T18:32:53  <wumpus> was it a real key or just a corrupted echo?
232 2016-08-04T18:33:46  <wumpus> cfields: maybe do the secp256k1 update for 0.13.1 too then
233 2016-08-04T18:34:02  <instagibbs> so worst case with "ghost" keys would be having keys you didn't actually generate? or?
234 2016-08-04T18:34:17  <wumpus> instagibbs: or partial old records
235 2016-08-04T18:34:25  *** telelvis1 has joined #bitcoin-core-dev
236 2016-08-04T18:34:26  <cfields> wumpus: probably makes sense, yes. I'm running a bench with/without atm.
237 2016-08-04T18:34:53  <wumpus> instagibbs: it does a linear scan over the file and everything that looks like a key/value is returned
238 2016-08-04T18:35:18  <instagibbs> so aggressive will indeed return more, but we toss anything that looks wrong
239 2016-08-04T18:35:20  <paveljanik> Trivial -Wshadow PRs for review: 8109, 8163, 8191, 8449. I'd be glad to get some ACKs. Thank you.
240 2016-08-04T18:35:59  <wumpus> instagibbs: yes, we do, we're fairly robust there. But it means possible false positives inthe log
241 2016-08-04T18:35:59  *** telelvis has quit IRC
242 2016-08-04T18:36:13  <instagibbs> wumpus, ok, well that's less scary, thanks
243 2016-08-04T18:36:47  <wumpus> instagibbs: I hope that's it! but you can only find out by analysing that wallet\
244 2016-08-04T18:37:08  <wumpus> see if the keys that are in the original wallet and post-salvage wallet are the same, despite the WARNING
245 2016-08-04T18:37:50  <sipa> wumpus: i'll merge the strings include in secp
246 2016-08-04T18:37:59  <wumpus> sipa: thanks
247 2016-08-04T18:38:07  <sipa> so that can be included in the subtree
248 2016-08-04T18:38:14  <wumpus> right, I'll update the pr
249 2016-08-04T18:38:25  *** spudowiar has quit IRC
250 2016-08-04T18:38:38  <cfields> 116us vs 124us. not the end of the world.
251 2016-08-04T18:38:39  *** telelvis has joined #bitcoin-core-dev
252 2016-08-04T18:39:01  *** telelvis1 has quit IRC
253 2016-08-04T18:39:01  <wumpus> don't think that'd be worth it for any random warning, but missing prototypes are pretty serious business
254 2016-08-04T18:40:02  <sipa> cfields: that's the output of bench_verify ?
255 2016-08-04T18:40:22  <gmaxwell> cfields: I'm surprised by that.
256 2016-08-04T18:40:29  <gmaxwell> the difference is smaller than I expected.
257 2016-08-04T18:40:29  <sipa> likewise
258 2016-08-04T18:40:31  <cfields> sipa: yes
259 2016-08-04T18:41:44  <sipa> what compilation flags?
260 2016-08-04T18:41:58  <cfields> sipa: default passed down from bitcoin
261 2016-08-04T18:42:37  <wumpus> 116 versus 124 seems in the error margin, are you sure something changed at all?
262 2016-08-04T18:42:42  <cfields> sipa: http://pastebin.com/raw/VbmBERA8
263 2016-08-04T18:43:18  <cfields> ran a few times of each, didn't deviate much. double-checking.
264 2016-08-04T18:43:23  <wumpus> okay
265 2016-08-04T18:44:53  <gmaxwell> cfields: what cpu is this?
266 2016-08-04T18:46:38  <cfields> gmaxwell: i5, 2.4ghz. there's no /proc/cpuinfo in osx, i can dig around and find it if you'd like the gen
267 2016-08-04T18:47:57  *** MarcoFalke has joined #bitcoin-core-dev
268 2016-08-04T18:48:04  <sipa> cfields: reproduced
269 2016-08-04T18:48:13  <cfields> there we go. 4258U. haswell.
270 2016-08-04T18:48:36  <sipa> 112us vs 117us here
271 2016-08-04T18:48:46  <sipa> ecdsa_verify: min 117us / avg 117us / max 117us
272 2016-08-04T18:48:54  <sipa> ecdsa_verify: min 112us / avg 113us / max 113us
273 2016-08-04T18:49:11  <jonasschnelli> cfields: OSX: use "sysctl -n machdep.cpu.brand_string" instead cat /proc/cpuinfo
274 2016-08-04T18:49:15  <cfields> sipa: in linux? or reproduced on mac?
275 2016-08-04T18:49:23  <sipa> linux
276 2016-08-04T18:49:36  <sipa> with cpu clock pinned to a single frequency
277 2016-08-04T18:49:44  <GitHub127> [bitcoin] MarcoFalke pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/d485a6c5a8d2...114f7e944b1c
278 2016-08-04T18:49:45  <GitHub127> bitcoin/0.13 cd0910b Suhas Daftuar: Fix p2p-feefilter.py for changed tx relay behavior...
279 2016-08-04T18:49:45  <GitHub127> bitcoin/0.13 114f7e9 MarcoFalke: Merge #8454: [0.13.1] Fix p2p-feefilter.py for changed tx relay behavior...
280 2016-08-04T18:49:46  <GitHub182> [bitcoin] MarcoFalke closed pull request #8454: [0.13.1] Fix p2p-feefilter.py for changed tx relay behavior (0.13...Mf1608-qaFeeFilter013) https://github.com/bitcoin/bitcoin/pull/8454
281 2016-08-04T18:50:00  <cfields> huh.
282 2016-08-04T18:50:02  <gmaxwell> sipa: that looks broken, those numbers are much higher than I expect.
283 2016-08-04T18:50:09  <gmaxwell> (for both of you)
284 2016-08-04T18:50:28  <sipa> that's without gmp or endomorphism, at 2.6 GHz
285 2016-08-04T18:50:33  <cfields> gmaxwell: remember no bignum or endo
286 2016-08-04T18:50:37  <gmaxwell> I normally expect a verify to be more like 70us. but maybe thats all gmp.
287 2016-08-04T18:51:42  <cfields> jonasschnelli: thanks
288 2016-08-04T18:52:02  <wumpus> MarcoFalke: please don't merge anything for 0.13 now, we have to decide on the meeting whether to release final, this is a test change but I don't want to have to trigger a new rc without good reason
289 2016-08-04T18:52:29  <MarcoFalke> This should not be enough for a new rc
290 2016-08-04T18:52:57  <wumpus> I know, but you named it 0.13.1, and it's not time to merge for 0.13.1 yet, just clarifying
291 2016-08-04T18:53:10  <MarcoFalke> oops
292 2016-08-04T18:53:27  * gmaxwell predicts a build system problem.
293 2016-08-04T18:53:35  <gmaxwell> (in libsecp256k1)
294 2016-08-04T18:53:37  <wumpus> (people may still want to do e.g. changelog changes before tagging final)
295 2016-08-04T18:53:44  <gmaxwell> cd ~
296 2016-08-04T18:54:07  <cfields> gmaxwell: for which?
297 2016-08-04T18:54:11  <wumpus> bitcoin is always without gmp
298 2016-08-04T18:54:20  <sipa> gmaxwell: sounds likely... with endo and gmp enabled is see no statistically significant performance difference between asm enabled and disabled
299 2016-08-04T18:54:44  <sipa> 71.2us vs 71.4us
300 2016-08-04T18:55:02  <sipa> (with variance between tests exceeding 0.2us)
301 2016-08-04T18:57:32  <gmaxwell> Aside, I think in the GUI and logs we should display the verification performance... so people will better realize how radically difference in speed different machines are. :)
302 2016-08-04T18:58:22  <wumpus> yes, a graph of verification performance in the gui would be nice
303 2016-08-04T18:59:02  <wumpus> similar to the bandwidth one
304 2016-08-04T18:59:19  <wumpus> with part spent in i/o secp256k1 etc
305 2016-08-04T18:59:20  <jonasschnelli> heh.. currently working on a mempool graph
306 2016-08-04T18:59:44  <wumpus> nice
307 2016-08-04T19:00:10  <jonasschnelli> http://i.imgur.com/G6yi9UR.png (very basic atm)
308 2016-08-04T19:00:14  <gmaxwell> wumpus: Well I meant as a static this computer x faster than that computer. not usage.
309 2016-08-04T19:00:24  <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
310 2016-08-04T19:00:43  <wumpus> #startmeeting
311 2016-08-04T19:00:43  <lightningbot> Meeting started Thu Aug  4 19:00:43 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
312 2016-08-04T19:00:43  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
313 2016-08-04T19:01:01  <cfields> gmaxwell: mm, i just stuck some "#error foo" in the asm paths, it blows up as expected.
314 2016-08-04T19:01:06  <cfields> whoops, will continue after meeting
315 2016-08-04T19:01:15  <MarcoFalke> topic 0.13.0, I guess?
316 2016-08-04T19:01:22  <wumpus> #topic 0.13.0 final?
317 2016-08-04T19:01:33  <wumpus> did anyone hear of any critical problems with rc2?
318 2016-08-04T19:01:54  <gmaxwell> I haven't heard much on it. Been quiet.
319 2016-08-04T19:02:03  <sipa> we forgot to backport 8438/8365 into 0.13...
320 2016-08-04T19:02:16  <wumpus> sipa something for 0.13.1?
321 2016-08-04T19:02:29  <kanzure> hi. greetings.
322 2016-08-04T19:02:39  <luke-jr> wumpus: the release notes are still inappropriate AFAIK
323 2016-08-04T19:03:07  <luke-jr> also gmaxwell was going to add a section I believe, covering the new relay policy influences (maybe I missed that being added)
324 2016-08-04T19:03:11  <jeremyrubin> hi
325 2016-08-04T19:03:12  <gmaxwell> I think I owed some release note text which I haven't done yet re max blocksize settings.
326 2016-08-04T19:03:12  <kanzure> this isn't short-term development related but it's high signal-noise crypto content that a few developers recently participated in, http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/
327 2016-08-04T19:03:16  <MarcoFalke> Wouldn't 8438 require rc3?
328 2016-08-04T19:03:16  <wumpus> luke-jr: then update them, sipa also still wants to add something
329 2016-08-04T19:03:22  <wumpus> MarcoFalke: yes
330 2016-08-04T19:03:28  <luke-jr> wumpus: my PR to update them is still open.
331 2016-08-04T19:03:35  <wumpus> luke-jr: it also updates code
332 2016-08-04T19:03:43  <jonasschnelli> luke-jr: does the PR still contain code changes?
333 2016-08-04T19:03:46  *** telelvis has quit IRC
334 2016-08-04T19:03:46  <luke-jr> so you want a version without code changes?
335 2016-08-04T19:04:06  <wumpus> luke-jr: if you make a PR that just updates the changelog, and it's accepted by others, it would have been merged a long time ago
336 2016-08-04T19:04:47  <luke-jr> wumpus: the current language was not accepted.
337 2016-08-04T19:04:59  <jonasschnelli> sipa: do you think https://github.com/bitcoin/bitcoin/pull/8438 can wait for 0.13.1?
338 2016-08-04T19:05:06  <luke-jr> I find this double-standard somewhat annoying.
339 2016-08-04T19:05:12  <morcos> sigh, if this is another meeting of us all arguing against luke-jr then i'm going to find something else to do
340 2016-08-04T19:05:20  *** telelvis1 has joined #bitcoin-core-dev
341 2016-08-04T19:05:29  <jonasschnelli> heh. Yes. Finish this. luke-jr can open a pr (action)
342 2016-08-04T19:05:40  <wumpus> I'm not arguing against luke-jr
343 2016-08-04T19:06:08  <wumpus> anyhow that derailed my question - so no one had any critical problems with 0.13.0rc2?
344 2016-08-04T19:06:22  <wumpus> and I don't mean with the release notes
345 2016-08-04T19:06:30  <sipa> is there any fear of instagibbs' problem being due to a code error?
346 2016-08-04T19:06:38  <wumpus> what problem?
347 2016-08-04T19:06:41  <instagibbs> sipa, fwiw it's showing up on older fork...
348 2016-08-04T19:06:58  <instagibbs> it's not HD-related, or anything fairly recent
349 2016-08-04T19:07:00  <gmaxwell> instagibbs: so without the bip32 changes?
350 2016-08-04T19:07:04  <instagibbs> correct
351 2016-08-04T19:07:05  <wumpus> you mean the salvagewallet problem? that's old hat, there's two issues open with salvagewallet problems
352 2016-08-04T19:07:09  <sipa> instagibbs: ok, good to know
353 2016-08-04T19:07:11  <wumpus> as I mentioned
354 2016-08-04T19:07:19  <sipa> sorry, i didn't follow the whole discussion
355 2016-08-04T19:07:19  <wumpus> this is not a last minute problem
356 2016-08-04T19:07:21  <luke-jr> wumpus: earlier we were discussing 0.13.0's failure mode downgrading from 0.13.1; I am not clear what the status of that is, or if we need changes for it
357 2016-08-04T19:07:22  <instagibbs> yes I'll double-check that keys aren't actually going away
358 2016-08-04T19:07:26  <instagibbs> but not worried now
359 2016-08-04T19:07:31  <gmaxwell> OK.
360 2016-08-04T19:07:36  <instagibbs> LoadWallet works anyhoo :P
361 2016-08-04T19:07:39  <wumpus> yes
362 2016-08-04T19:08:23  *** fengling has joined #bitcoin-core-dev
363 2016-08-04T19:08:26  <wumpus> so, all agree that it is time to release 0.13.0 final?
364 2016-08-04T19:08:34  <wumpus> (after say, a day of updating the release notes)
365 2016-08-04T19:09:06  <sipa> do we care about what happens when someone downgrades 0.13.1 to 0.13.0 after segwit activates?
366 2016-08-04T19:09:08  <jonasschnelli> ACK, I can live with https://github.com/bitcoin/bitcoin/pull/8438  for 0.13.1 but don't know about others opinions.
367 2016-08-04T19:09:09  <sdaftuar> i think we can just tell users who want to downgrade to 0.13.0 after segwit activates to do a reindex?
368 2016-08-04T19:09:27  <sdaftuar> they'll end up redownloading blocks, without witnesses, but that seems fine
369 2016-08-04T19:09:30  <luke-jr> sipa: I care only to the extent that it shouldn't make a "working" node that doesn't match consensus
370 2016-08-04T19:09:32  <sdaftuar> kind of a weird case to try to optimize
371 2016-08-04T19:09:45  <wumpus> agree with luke-jr - it should give a clear error
372 2016-08-04T19:09:49  <luke-jr> ie, it should give a hard error or reindex or something
373 2016-08-04T19:09:54  <wumpus> it should not seem to work, but if it requires a reindex that's fine
374 2016-08-04T19:10:04  <jonasschnelli> sdaftuar: Yes. I think this would be good. I don't think we need to cover the downgrade case.
375 2016-08-04T19:10:05  <sipa> luke-jr: i think the only risk (but i haven't tried) is that it either works fine or crashes
376 2016-08-04T19:10:11  <gmaxwell> Loss of #8438 is unfortunate but if including it would mean delaying the release I don't think it would be good to do so.
377 2016-08-04T19:10:15  <sipa> luke-jr: the UTXO set is identical across the two
378 2016-08-04T19:10:42  <luke-jr> I suggest someone should try it before final 0.13.0
379 2016-08-04T19:10:53  <luke-jr> probably not difficult using testnet?
380 2016-08-04T19:10:56  <sdaftuar> sipa: i guess its somewhat unfortunate that it will seem to work fine.
381 2016-08-04T19:10:57  <sipa> luke-jr: ack
382 2016-08-04T19:11:00  <gmaxwell> it can be tested by changing the testnet parameters.
383 2016-08-04T19:11:10  <sipa> detecting this situation is not hard, btw
384 2016-08-04T19:11:24  <sdaftuar> oh because 0.13.1 will use OPT_WITNESS?
385 2016-08-04T19:11:27  *** pmienk has quit IRC
386 2016-08-04T19:11:32  <sipa> sdaftuar: yes
387 2016-08-04T19:12:03  <sdaftuar> hm so maybe we should add code then to look for that, hmm
388 2016-08-04T19:12:16  <sipa> it's very last minute though...
389 2016-08-04T19:12:23  <sdaftuar> i agree. and seemingly not that important
390 2016-08-04T19:12:25  <sipa> i wish we thought of this before
391 2016-08-04T19:12:35  <sipa> but i don't think it's worth holding up the release for
392 2016-08-04T19:12:56  <luke-jr> it's trivial to test I think; if everyone else is too busy, I will try to do it today
393 2016-08-04T19:13:02  <wumpus> gmaxwell: it would mean doing another rc, we could do final next week
394 2016-08-04T19:13:06  *** fengling has quit IRC
395 2016-08-04T19:13:58  <gmaxwell> that woudl also allow adding segwit downgrade protection sipa is currently discussing. (should be 3loc or so)
396 2016-08-04T19:14:10  <wumpus> I don't know if it is that critical though, at some point we should just make the cut and stop slipping
397 2016-08-04T19:14:32  <wumpus> yes that is true
398 2016-08-04T19:15:06  * sipa notes that we're only 3 days past the date in https://github.com/bitcoin/bitcoin/issues/7679
399 2016-08-04T19:15:36  <sipa> ideally deadlines don't slip, but iirc we're much more on track than for earlier major releases
400 2016-08-04T19:15:37  <jonasschnelli> Yes. Maybe https://github.com/bitcoin/bitcoin/pull/8438  + SW0.13 downgrade compatibility is worth a week delay
401 2016-08-04T19:15:40  <wumpus> yes, we've caught up a bit with the rc1 slip by doing a fast rc phase
402 2016-08-04T19:15:48  <GitHub107> [bitcoin] luke-jr opened pull request #8458: [0.13] release notes: remove bad advice to switch to blockmaxweight prematurely (master...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8458
403 2016-08-04T19:15:51  <btcdrak> 0.13.1 shouldnt be too far behind at least, but my preference is to include it and do another rc
404 2016-08-04T19:15:54  <wumpus> note that I planned amonth for the rc1 phase
405 2016-08-04T19:15:59  <wumpus> eh for the rc phase
406 2016-08-04T19:16:31  <wumpus> well the downgrade protection cna't be postponed to 0.13.1
407 2016-08-04T19:16:34  <wumpus> that'd defeat the point
408 2016-08-04T19:16:38  <wumpus> otherwise that'd be my preference
409 2016-08-04T19:16:45  <luke-jr> 8458 also mentions an idea I had for a 3-liner to make blockmaxsize perform identical to blockmaxweight, if we do another rc.. if that's desired, someone please say so and I'll do it now
410 2016-08-04T19:17:01  <sipa> luke-jr: i think you included a few commits too many
411 2016-08-04T19:17:01  <wumpus> yes now everyone starts with last minute ideas
412 2016-08-04T19:17:02  <wumpus> great
413 2016-08-04T19:17:11  <luke-jr> oh crap, I made it against master
414 2016-08-04T19:17:34  <GitHub168> [bitcoin] luke-jr closed pull request #8458: [0.13] release notes: remove bad advice to switch to blockmaxweight prematurely (master...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8458
415 2016-08-04T19:17:38  <gmaxwell> luke-jr: nah, something changing transaction selection.. not a good thing now.
416 2016-08-04T19:17:41  <luke-jr> wumpus: well, it's trivial and probably unnecessary; fine if we don't do it
417 2016-08-04T19:18:28  <wumpus> #action check if downgrade protection is really needed, or whether it already fails
418 2016-08-04T19:18:52  <GitHub10> [bitcoin] luke-jr opened pull request #8459: [0.13] release-notes: Do not encourage changing blockmaxsize to blockmaxweight (0.13...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8459
419 2016-08-04T19:19:40  <wumpus> other topics?
420 2016-08-04T19:19:59  <cfields> oh
421 2016-08-04T19:20:29  <sipa> segwit mempool malleability dos (#8279)
422 2016-08-04T19:20:33  <cfields> (sec, someone else feel free to go ahead)
423 2016-08-04T19:20:52  <wumpus> #topic segwit mempool malleability dos
424 2016-08-04T19:21:51  <wumpus> wasn't that supposed to be solved in #8312?
425 2016-08-04T19:21:57  <sdaftuar> no, it was only solved for 0.13.0
426 2016-08-04T19:22:01  *** pmienk has joined #bitcoin-core-dev
427 2016-08-04T19:22:04  <sdaftuar> we need to decide what to do in our first segwit release
428 2016-08-04T19:22:08  <sipa> so i suggested removing the "transaction failure purely due to witness does not cause rejection cache entry"
429 2016-08-04T19:22:42  <sipa> with the rationale that all it does it prevent an attacker from hiding a valid transaction from you in some cases
430 2016-08-04T19:23:04  <sipa> but it doesn't prevent it entirely (they can announce and just never send the transaction)
431 2016-08-04T19:23:35  <sipa> sdaftuar notes that the mempool malleability attack only needs a short lived connection, while the never send tx data attack needs a persistent one
432 2016-08-04T19:23:53  <sdaftuar> and it needs more than one persistent one -- you need several, as we retry tx download from other peers
433 2016-08-04T19:24:18  <sipa> sdaftuar: rejection cache is also temporary, but a node won't just re-request...
434 2016-08-04T19:24:31  <morcos> i think i'm coming around to the idea of full verification of all txs
435 2016-08-04T19:24:39  <gmaxwell> morcos: hah
436 2016-08-04T19:24:51  <BlueMatt> was there rationale to inv'ing with txid instead of wtxid for segwit nodes?
437 2016-08-04T19:25:31  <BlueMatt> (just noting that wtxid would be Keep The Same Behavior As Pre SegWit (tm))
438 2016-08-04T19:26:38  <sipa> BlueMatt: duplicating a lot of logic (mempool, orphan, caches, ...), and causes at least a potential doubling anyway (you could be inved the same tx from a pre-segwit and post-segwit node once with txid and once with wtxid, without being able to tell they're the same)
439 2016-08-04T19:27:24  <gmaxwell> also in the long term, the high malleability of witnesses would let an attacker waste lots of bandwidth. with nodes relaying different witness versions of the same txn among each other.
440 2016-08-04T19:27:42  <BlueMatt> sipa: if you're inved a tx with a witness from a pre-segwit node we get a double anyway since its garbage to us
441 2016-08-04T19:28:19  <BlueMatt> gmaxwell: same is true for scriptSigs...up to IsStandard limits (which could, in fact, be more easily enforced on witnesses)
442 2016-08-04T19:28:22  <sdaftuar> BlueMatt: that's true but shouldn't happen, as pre-segwit nodes shouldn't be accepting segwit transactions unless they're running with an unusual policy
443 2016-08-04T19:28:29  <sipa> also, if you have a tx with malleable witness (say, op_drop argument), nodes on the network could modify the witness without invalidating, and you wouldn't even be able to tell you already had the transaction before download
444 2016-08-04T19:28:59  <sipa> and you couldn't ban them for it, because they're all valid transactions
445 2016-08-04T19:30:00  <gmaxwell> BlueMatt: the kind of isstandard restriction against malleability only works great for limited classes of transactions, at least in the long term that isn't great.
446 2016-08-04T19:30:10  <BlueMatt> I'm aware
447 2016-08-04T19:30:18  <sipa> a solution is inving with both txid and wtxid... but if we go that way, we should also adds resource information to all invs (fees, size, sigops, ...)
448 2016-08-04T19:30:35  <BlueMatt> sipa: I was about to say that...seems like a real solution is inving both...
449 2016-08-04T19:30:41  <morcos> aren't we approachign the size of the tx at that point
450 2016-08-04T19:31:04  <sipa> morcos: certainly within an order of magnitude
451 2016-08-04T19:31:07  <BlueMatt> gmaxwell: but IsStandard is allowed to serve the same purpose as always - enforce reasonable limits to ensure code sanity until we've explored edge cases thouroughly
452 2016-08-04T19:31:20  <gmaxwell> the txid is within an order of magnitude. :P
453 2016-08-04T19:31:30  <sdaftuar> sipa: i think we might we just end up overfitting current policy rules by adding resource information
454 2016-08-04T19:31:32  <gmaxwell> (for the median size)
455 2016-08-04T19:31:50  <sipa> sdaftuar: 'overfitting' ?
456 2016-08-04T19:31:51  <gmaxwell> but future mempool sync these sizes will matter less.
457 2016-08-04T19:32:03  <gmaxwell> sdaftuar: feerate is pretty fundimental, however.
458 2016-08-04T19:32:04  <sdaftuar> ie policy will change, and the information will be insufficient
459 2016-08-04T19:32:08  <gmaxwell> I think including sigops would be dumb.
460 2016-08-04T19:32:22  <sdaftuar> gmaxwell: yes, but already handled with less bandwidth by feefilter
461 2016-08-04T19:32:29  <gmaxwell> if sigops really matter, something is wrong.
462 2016-08-04T19:32:48  <gmaxwell> sdaftuar: indeed. feefilter makes it implicit.
463 2016-08-04T19:32:53  <sipa> well, ok... we could send size and fee
464 2016-08-04T19:33:05  <sipa> but that's not much better than making feefilter mandatory
465 2016-08-04T19:33:12  <sipa> except slightly more flexible
466 2016-08-04T19:33:20  <sipa> and sending two hashes is annoying
467 2016-08-04T19:33:24  <gmaxwell> we're in the weeds for this right now.
468 2016-08-04T19:33:31  <sipa> agree
469 2016-08-04T19:33:45  <sipa> i think there is no simple clear cut solution for this
470 2016-08-04T19:34:08  <gmaxwell> if we're doing set recon it doesn't really matter that much how long the identifiers are.
471 2016-08-04T19:34:16  <sipa> but that's much further out
472 2016-08-04T19:34:20  <BlueMatt> if inv'ing both hashes werent stupid for bandwidth, Id say that was a pretty great solution
473 2016-08-04T19:34:29  <BlueMatt> true
474 2016-08-04T19:34:57  <gmaxwell> sipa: depends on how long it takes me to convince you to implement the relevant number theory code. :P
475 2016-08-04T19:35:52  <gmaxwell> In any case, the witnessID really doesn't matter for much of anything except rejection here.
476 2016-08-04T19:36:00  <sipa> alternative idea: make feefilter mandatory for segwit, and just disable rejectioncache...
477 2016-08-04T19:36:16  <sipa> rejectioncache only helps in practice against repeated announcements of transactions below your threshold
478 2016-08-04T19:36:28  <sipa> it's not a protection against attacks
479 2016-08-04T19:38:01  <sdaftuar> hm, not a bad idea
480 2016-08-04T19:38:03  <luke-jr> feefilter isn't even used by default last I knew? (because there is no min fee until the mempool fills)
481 2016-08-04T19:38:15  <sipa> luke-jr: good point
482 2016-08-04T19:38:40  <BlueMatt> damn, mem^H^H^Hdiskpool was too late :(
483 2016-08-04T19:38:47  <morcos> i'm all for making fee filter mandatory, if i'd known people would have liked it this much, we should have designed it that way from teh beginning
484 2016-08-04T19:39:06  <morcos> i'm a bit worried about removing the rejection cache entirely
485 2016-08-04T19:39:16  <gmaxwell> luke-jr: there is a minrelayfee.
486 2016-08-04T19:39:27  <gmaxwell> Do we not feefilter on that?
487 2016-08-04T19:39:29  <sdaftuar> gmaxwell: but we let in free transactions still
488 2016-08-04T19:39:35  <gmaxwell> oh right.
489 2016-08-04T19:39:58  <morcos> anytime there is any policy difference between nodes (such as a change in minrelay fee change isDust) then you get txs bouncing aroudn the network between the sets of nodes with different policies
490 2016-08-04T19:40:06  <gmaxwell> full validation and distinguishing why rejection happened would help.
491 2016-08-04T19:40:11  <morcos> i think its nice to have a sort of protection against that
492 2016-08-04T19:42:12  <gmaxwell> we could just have one rejection filter per peer type.
493 2016-08-04T19:42:25  <gmaxwell> e.g. rejection filter for non-sw peers and a rejection filter for sw peers.
494 2016-08-04T19:43:03  <sdaftuar> with sw peers using wtxid invs?
495 2016-08-04T19:43:30  <sipa> sdaftuar: still not enough... you need to be able to tell whether you already have another version of the same tx
496 2016-08-04T19:43:35  <sipa> even with only sw peers
497 2016-08-04T19:43:58  <gmaxwell> +full validation.
498 2016-08-04T19:44:39  *** jtimon has joined #bitcoin-core-dev
499 2016-08-04T19:44:44  <sdaftuar> sipa: i don't see why that's needed, any more than we have today with not knowing a tx is a double-spend before processing
500 2016-08-04T19:45:50  <sipa> sdaftuar: someone connects to a 1000 nodes on the network, and relays a different version of the same valid transaction to each
501 2016-08-04T19:45:59  <sipa> sdaftuar: now you potentially need to download 1000 transactions
502 2016-08-04T19:46:14  <sipa> only one of which pays fees
503 2016-08-04T19:46:20  <morcos> proposal: make feefilter mandatory. fully validate txs so we can punish peers who send us invalid stuff. don't put any witness tx in the rejection cache.  then evaluate how useful rejection cache continues to be or whether we have policy violating segwit txs bouncing around
504 2016-08-04T19:46:21  <sdaftuar> so you mean a 3rd party uses signature malleability to do this?
505 2016-08-04T19:46:32  <sdaftuar> because the tx originator can already do that
506 2016-08-04T19:46:59  <sipa> sdaftuar: right, the distinction isn't all that big
507 2016-08-04T19:47:34  <sipa> morcos: i like that... but i think it's a big change for 0.13.1
508 2016-08-04T19:47:34  <gmaxwell> the distinction though is that an attacker doing it pays fees, eventually runs out of funds, vs an attacker doing it to other peoples' txn does not ever run out of funds.
509 2016-08-04T19:48:02  *** d_t has joined #bitcoin-core-dev
510 2016-08-04T19:48:10  <morcos> sipa: i think if we start with " don't put any witness tx in the rejection cache" then we'll be ok
511 2016-08-04T19:48:27  <sipa> morcos: ack
512 2016-08-04T19:48:32  <morcos> we can see how easy and short he other 2 are
513 2016-08-04T19:50:18  <wumpus> that concludes the topic for this meeting?
514 2016-08-04T19:50:27  <wumpus> any other topic proposals? cfields?
515 2016-08-04T19:50:29  <NicolasDorier> for information, I created ##libconsensus bikeshedding room about how to handle libconsensus for anybody interested.
516 2016-08-04T19:50:48  <cfields> NicolasDorier: haha, i was just about to paste a blurb for that
517 2016-08-04T19:51:06  <NicolasDorier> aha I just woke up for that, will go back bed :D
518 2016-08-04T19:51:22  <instagibbs> I have to leave now, but just letting you know salvage is finding lots of "extra" keys vs keys actually in wallet. *shrug*
519 2016-08-04T19:52:02  <cfields> NicolasDorier and I discussed libconsensus a bit this weekend. We're hoping to discuss amongst ourselves, come up with some goals, and present them clearly for easier review
520 2016-08-04T19:52:12  <morcos> +100
521 2016-08-04T19:52:16  <cfields> jtimon: ^^
522 2016-08-04T19:52:25  <wumpus> #topic libconsensus
523 2016-08-04T19:52:37  <cfields> that was it :)
524 2016-08-04T19:52:54  <NicolasDorier> wumpus: we have not started the bikeshedding yet, expect longer fight about it soon :p
525 2016-08-04T19:53:08  <luke-jr> NicolasDorier: IMO just discuss it here
526 2016-08-04T19:53:14  <luke-jr> way too many channels already
527 2016-08-04T19:53:31  <NicolasDorier> the reason I prefer a separate channel is so we can keep history and review it more easily
528 2016-08-04T19:53:46  <wumpus> it's not like this channel is very busy\
529 2016-08-04T19:53:47  <NicolasDorier> things said here get lost quickly enough in the sea of discussion
530 2016-08-04T19:54:25  <wumpus> that always happens on IRC, if you want discussions with good history/memory then it may be better to use a different discussion mechanism, or keep summaries or such
531 2016-08-04T19:54:36  <sipa> i think having a separate place to 'form' a proposal makes sense
532 2016-08-04T19:55:00  <luke-jr> #bitcoin-dev is also fairly quiet
533 2016-08-04T19:55:08  <sipa> involving the whole world in a design rarely leads to something useful
534 2016-08-04T19:55:19  *** cryptapus has quit IRC
535 2016-08-04T19:55:27  <jtimon> from what I talked with NicolasDorier in previous times, the current goal is to complete a verifyBlock without necessarily exposing it in libconsensus at first
536 2016-08-04T19:55:28  <wumpus> that's true, as long as you can get the people you want to pay attention to join it's fine
537 2016-08-04T19:55:41  <wumpus> sometimes it's good to not have too many people there
538 2016-08-04T19:55:51  <wumpus> but speaking for myself, I'm already in so many channels, I have a hard time following more
539 2016-08-04T19:55:52  <morcos> to be clear, the design will be presented to the bigger group for feedback and not set in stone
540 2016-08-04T19:55:57  <btcdrak> yeah ack on limiting channel proliferation, also it is more open in a logged channel
541 2016-08-04T19:56:34  <morcos> i don't plan on joining the libconsensus subgroup, but i think having a focused small group will make progress actually happen
542 2016-08-04T19:56:37  <BlueMatt> I'm with wumpus...too many channels these days (not that I've been paying enough attention to have much of a voice, but still)
543 2016-08-04T19:56:43  <wumpus> then again that's up to you, doesn't need to be a discussion topic here to decide onthat.
544 2016-08-04T19:56:48  <jtimon> I don't think creating a new channel or not is going to be important either way...
545 2016-08-04T19:56:59  <cfields> morcos: sure. doesn't matter to me where the discussion takes place, just hoping to organize the discussion/planning a bit.
546 2016-08-04T19:57:03  <wumpus> any other topics? 4 minutes to go
547 2016-08-04T19:57:14  <sipa> i'm in favor of having it in a separate channel because i prefer not to see all discussions around it before there is clean design :)
548 2016-08-04T19:57:33  <NicolasDorier> bikeshedding about the creation of the channel libconsensus announce the color of the future bikeshedding on the actual code ;)
549 2016-08-04T19:57:40  <wumpus> NicolasDorier: exactly
550 2016-08-04T19:57:47  <wumpus> let's stop that
551 2016-08-04T19:57:49  <cfields> heh
552 2016-08-04T19:57:50  <sipa> haha
553 2016-08-04T19:58:01  <sipa> 3 minutes
554 2016-08-04T19:58:17  <jtimon> cfields: NicolasDorier if you can share the goals
555 2016-08-04T19:58:23  <wumpus> looks like we're done
556 2016-08-04T19:58:24  <wumpus> #endmeeting
557 2016-08-04T19:58:24  <lightningbot> Meeting ended Thu Aug  4 19:58:24 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
558 2016-08-04T19:58:24  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-04-19.00.html
559 2016-08-04T19:58:24  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-04-19.00.txt
560 2016-08-04T19:58:24  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-04-19.00.log.html
561 2016-08-04T19:59:48  <NicolasDorier> I have a code question: I'm working on a commit similar to one from jtimon, he is removing one check here https://github.com/jtimon/bitcoin/compare/remove-ism...consensus-post-remove-ism#diff-7ec3c68a81efff79b6ca22ac1f1eabbaL2353 about BIP30, does somebody know if it is actually safe to do so ?
562 2016-08-04T20:00:23  <cfields> jtimon: i think everyone has different goals in mind. the point of organizing is to settle on something and work towards it. i can catch you up on our discussions this weekend, though ofc you've spent more time on it than anyone
563 2016-08-04T20:01:10  <jtimon> cfields: well, a small summary of the "goals in common" or "easy to achieve" goals or something would be something
564 2016-08-04T20:02:48  <NicolasDorier> jtimon: I think we still have also to discover what the goals in common are. Which is why I think we can discuss it in the channel. I guess if the three of us agree (plus anybody in the channel), there is good chance the rest agree too
565 2016-08-04T20:02:52  *** telelvis1 has quit IRC
566 2016-08-04T20:02:59  <morcos> NicolasDorier: See this comment from sdaftuar: https://github.com/bitcoin/bitcoin/pull/8391#issuecomment-237584871
567 2016-08-04T20:03:31  <NicolasDorier> correct, I'll write a bip
568 2016-08-04T20:04:33  <jtimon> NicolasDorier: I may not be so optimist, but fair enough, I mean, great. do you guys have time now to give me a little summary of your discussions so far now (in the other channel)?
569 2016-08-04T20:04:44  <morcos> It's related.  The point is once you are enforcing BIP34 then BIP30 is unnecessary except for historical violations.  We're changing the rule to have BIP34 be enforced as of a certain height, however, it kind of requires that the chain be the same otherwise we dont' know what the historical violations are or might be
570 2016-08-04T20:04:58  <NicolasDorier> yes, I will jtimon, but later I'll go back bed soon (5am here)
571 2016-08-04T20:05:12  <jtimon> yeah, I say so in my commit, it is unnecessary because we're not using ISM anymore
572 2016-08-04T20:06:19  <jtimon> oh, no worries, another time will be fine
573 2016-08-04T20:06:37  *** gabridome has joined #bitcoin-core-dev
574 2016-08-04T20:07:00  <cfields> jtimon: same, in the middle of several things atm. maybe some time tomorrow?
575 2016-08-04T20:07:14  <jtimon> sure, no problem
576 2016-08-04T20:07:55  <NicolasDorier> morcos: so basically we could remove BIP30 altogether as this is unlikely another chain manage to catch up the amount of work of the current one
577 2016-08-04T20:08:36  <sipa> isn't there some interaction between BIP30 and the no-overwrite optimization in coinscache?
578 2016-08-04T20:08:49  <sipa> which needs a BIP30 check during IBD
579 2016-08-04T20:09:23  <NicolasDorier> mmh I think I won't make any change about it after all... I'm not confident of this thing
580 2016-08-04T20:09:25  <morcos> NicolasDorier: yeah we need it on IBD
581 2016-08-04T20:09:31  <morcos> hmm this brings up a kind of good point
582 2016-08-04T20:09:44  *** fengling has joined #bitcoin-core-dev
583 2016-08-04T20:09:47  <morcos> you can't remove the BIP34Hash unless you are going to checkpoint the chain at that point
584 2016-08-04T20:10:42  <NicolasDorier> ok, so I will not touch it
585 2016-08-04T20:10:49  *** pmienk has quit IRC
586 2016-08-04T20:11:09  <jtimon> you cannot remove it completely, but when you use bip34 you don't need to do it (this is current behaviour)
587 2016-08-04T20:11:28  <morcos> jtimon: no, when you use BIP34 on the existing BIP34 hash then you dont' need to do it
588 2016-08-04T20:11:46  <morcos> if you activated BIP34 at the same height on a different chain, it would be unclear whether yous till needed to do BIP30
589 2016-08-04T20:11:50  <jtimon> morcos: only one block?
590 2016-08-04T20:11:57  <morcos> depends on the status of historical violations on that chain
591 2016-08-04T20:12:01  <morcos> no on all future blocks
592 2016-08-04T20:13:29  <jtimon> https://github.com/jtimon/bitcoin/commit/273e27bd0c086f5ba20cebc2f5ec9e24f9d79015
593 2016-08-04T20:13:31  <morcos> i can't remember off the top of my head, but if in an alternate chain you spent coinbase A before you generate coinbase A' then you activated BIP34, then you still need BIP30 to make sure the spend of A' doesn't conflict with the spend of A
594 2016-08-04T20:13:49  <morcos> but in the BIP34hash chain we know that didn't happen
595 2016-08-04T20:13:50  <jtimon> do you think that commit is incorrect after removing ISM?
596 2016-08-04T20:14:19  <morcos> jtimon: its incorrect in that it'll be broken code on a mainnet chain that doesn't contain BIP34hash
597 2016-08-04T20:14:26  *** fengling has quit IRC
598 2016-08-04T20:14:32  <morcos> so who knows what happens if someone feeds you such a chain on startup
599 2016-08-04T20:15:07  <jtimon> I think it will only fail if we reorg below BIP34Height (227931)
600 2016-08-04T20:15:13  <morcos> oh wait
601 2016-08-04T20:15:46  <morcos> maybe because BIP30 is enforced for everythign except those two exceptions you're ok
602 2016-08-04T20:15:49  <jtimon> and what we have now, if it reorgs that long, without code for ISM...what? bip34 is going to be activated at that height no matter what
603 2016-08-04T20:15:55  *** MarcoFalke has left #bitcoin-core-dev
604 2016-08-04T20:16:17  <jtimon> well, I wouldn't call them exceptions
605 2016-08-04T20:17:02  <jtimon> pindexBIP34height will only be NULL if pindex->pprev->GetAncestor(227931) returns null
606 2016-08-04T20:17:42  *** JackH_ has joined #bitcoin-core-dev
607 2016-08-04T20:18:01  <jtimon> what is doing now is that if you are above that height and the block you activated bip34 in is 227931, then don't enforce bip30 since bip34 is enforced
608 2016-08-04T20:19:11  <jtimon> in a reorg that deep, if it was activated with another block, then bip30 will be checked always regardless of bip34 activation (no optimization, never)
609 2016-08-04T20:19:12  <morcos> jtimon: i honestly don't think its worth doing.  but if you really want to, i will take the time to think about it.  there are a lot of issues, down to when you flush your cache.  but please make an actual PR for me to review that other people also want to merge
610 2016-08-04T20:19:41  <jtimon> with my suggested change, it would always do the optimization after bip34 activation height, even after such a long reorg
611 2016-08-04T20:20:22  <jtimon> morcos: absolutely, no problem
612 2016-08-04T20:20:38  *** Ylbam has joined #bitcoin-core-dev
613 2016-08-04T20:21:22  <morcos> jtimon: ok, i think i got the problem
614 2016-08-04T20:21:42  <jtimon> well, if you tell me now I won't open the PR :)
615 2016-08-04T20:21:47  <morcos> imagine that you reorg to height 90000 (or are just fed an alternate chain on startup)
616 2016-08-04T20:22:09  <morcos> ah shoot....
617 2016-08-04T20:22:10  <morcos> nm
618 2016-08-04T20:22:23  <morcos> wait
619 2016-08-04T20:22:24  <morcos> yes
620 2016-08-04T20:22:25  <morcos> thats it
621 2016-08-04T20:22:31  <morcos> so confusing
622 2016-08-04T20:22:44  <jtimon> let's do one thing at a time, yep, you reorg to 9000 or you fed an alternate chain?
623 2016-08-04T20:23:03  <morcos> either, same affect you start processing different blocks starting at 90000
624 2016-08-04T20:23:05  <jtimon> think the worse case: you reorg to block 1
625 2016-08-04T20:23:17  *** pmienk has joined #bitcoin-core-dev
626 2016-08-04T20:23:27  <morcos> thats after coinbase A was created but before its duplicate A' was created
627 2016-08-04T20:23:32  <morcos> now you spend coinbase A
628 2016-08-04T20:24:13  <jtimon> bip 30 is checked before bip34 always except the exceptions
629 2016-08-04T20:24:29  <jtimon> after bip34 activation, it is no longer necessary
630 2016-08-04T20:24:35  <morcos> then you create coinbase A'  (allowed b/c it doesn't violate BIP30 , A is spent, and BIP34 is not active yet)
631 2016-08-04T20:24:49  <morcos> now you activate BIP34 at height 227931
632 2016-08-04T20:25:02  *** JackH_ has quit IRC
633 2016-08-04T20:25:09  <morcos> then you can spend A' and create the same txid as your spend of A b/c you aren't enforcing BIP30 any more
634 2016-08-04T20:25:18  <jtimon> yes, from now on you can stop checking bip30 in new blocks
635 2016-08-04T20:25:24  <morcos> no you can't
636 2016-08-04T20:25:42  <morcos> spending A' would be allowed and would create a duplicate txid of the spend of A
637 2016-08-04T20:27:06  <jtimon> mhmm, whay they cannot today?
638 2016-08-04T20:27:10  <jtimon> why
639 2016-08-04T20:27:41  <morcos> because A' the coinbase was created before A was spent
640 2016-08-04T20:27:50  <morcos> so A' overwrote A already
641 2016-08-04T20:28:15  <morcos> but if in an alternate history you spent A to B first
642 2016-08-04T20:28:21  <jtimon> doesn't include the height make it very difficult to collide with coinbases before 227931 ?
643 2016-08-04T20:28:23  <morcos> then you have to worry about B' and B
644 2016-08-04T20:28:45  <jtimon> instead of A'
645 2016-08-04T20:28:59  <jtimon> think of all the coinbases before 227931
646 2016-08-04T20:29:29  <jtimon> no? you don't want the same as neither of those
647 2016-08-04T20:29:39  <morcos> you can try this on regtest..   enforce BIP30 only up to height 100 and BIP34 only starting at height 100.   create some coinbases, spend them and then create duplicates before 100.
648 2016-08-04T20:29:42  <jtimon> that's with or without a reorg
649 2016-08-04T20:29:44  <morcos> then after 100 make them colide
650 2016-08-04T20:29:56  <Chris_Stewart_5> Is there a simple way to serialize a CKey? Doesn't seem to have the SERIALIZE_METHODS macro
651 2016-08-04T20:30:44  <jtimon> morcos: yeah, you could "attack regtest" that way...
652 2016-08-04T20:31:07  <morcos> well if you change the code, someone could feed you a messed up mainnet chain that way
653 2016-08-04T20:31:09  <sipa> Chris_Stewart_5: historically, it's converted from/to a CPrivKey for serialization
654 2016-08-04T20:31:13  <jtimon> I thought we were talking about mainnet
655 2016-08-04T20:32:24  <morcos> jtimon: yes so on mainnet, you'd have to have a REALLY deep reorg, below 227931
656 2016-08-04T20:32:49  <Chris_Stewart_5> sipa: Is there a simple utility function serialize CPrivKey? Can it just be passed to HexStr?
657 2016-08-04T20:33:05  <morcos> or if somoene just fed you an alternate low work chain then i'm not really sure what would happen, its possible that your utxo could get into a messed up state than you wouldn't be able to fix when you found out about the real chain
658 2016-08-04T20:33:17  <jtimon> and then a node without my change would always check bip30, even after bip34 activation, is that the desired behaviour?
659 2016-08-04T20:33:30  <sipa> Chris_Stewart_5: CKey also has begin() and end(), to it can be passed to HexStr directly
660 2016-08-04T20:33:39  <sipa> Chris_Stewart_5: and has a constructor that takes a byte array
661 2016-08-04T20:33:50  <jtimon> my node would not check bip30 after bip34, even after the reorg
662 2016-08-04T20:34:48  <morcos> jtimon: yes you can either always check BIP30 even after BIP34, or you can examine the chain you're on pre BIP34 and decide whether you can now skip BIP30 checks (which is what we decided to do with mainnet, but requires manual intervention)
663 2016-08-04T20:34:56  <morcos> are you opposed to leaving in the BIP34 hash
664 2016-08-04T20:35:14  <morcos> checking BIP30 is exteremely slow
665 2016-08-04T20:35:38  <morcos> that's why we put in the ability to skip it
666 2016-08-04T20:36:58  <jtimon> so, yes, theoretically always checking bip30 after bip34 has certain risk if there's that reorg...but aren't we screwed if that happens anyway?
667 2016-08-04T20:37:16  <jtimon> like, really screwed
668 2016-08-04T20:37:50  <jtimon> I don't know, maybe it's not worth it
669 2016-08-04T20:38:03  <Chris_Stewart_5> sipa: Thanks
670 2016-08-04T20:39:08  <jtimon> the advantages are code simplification and a slight optimization (really no need to call GetAncestor if you don't care about the hash), and keep the optimization in case of pre-bip34 reorg, which is arguably a disadvantage
671 2016-08-04T20:39:35  <jtimon> no, not opposed, removing it is just a suggestion
672 2016-08-04T20:40:46  <jtimon> if we knew we weren't doing it, we could have made https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5 without bip34 directly in #8391...
673 2016-08-04T20:41:02  <jtimon> now I'm afraid the right time to do that will be...never
674 2016-08-04T20:41:07  <morcos> jtimon: i think the issue is less a reorg than that someone might feed you an alternate chain on startup and get your utxo into a permanently messed up state b/c you don't know how to reorg back
675 2016-08-04T20:41:37  <jtimon> oh, I see
676 2016-08-04T20:41:55  <morcos> i'm not positive that would happen, but seems more likely than not, and also seems like it could be affected by future changes to the way coins work that we might not anticipate
677 2016-08-04T20:41:55  <jtimon> yeah, makes sense, thanks
678 2016-08-04T20:44:14  <jtimon> yeah, I wasn't properly thinking about an isolated node doing initial synchornization, that's what you meant by fed up with the wrong chain from the beginning, sorry
679 2016-08-04T20:44:44  <jtimon> nah, better to avoid that risk, definitely not worth it
680 2016-08-04T20:44:51  <jtimon> thansk
681 2016-08-04T20:44:52  <morcos> jtimon: yeah
682 2016-08-04T20:44:54  <morcos> sure
683 2016-08-04T20:47:34  <jtimon> well, maybe the time for https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5 is whenever bip113 activation is simplified from bip9 in the same way
684 2016-08-04T20:47:38  *** gabridome has quit IRC
685 2016-08-04T20:48:59  <jtimon> or when/if we expose consensus::Params in libconsensus
686 2016-08-04T20:49:27  <jtimon> anyway, that's another topic
687 2016-08-04T20:49:39  <Chris_Stewart_5> sipa: When I serialize CPriv/CPub I get something that is larger than 32 bytes?
688 2016-08-04T20:50:35  <sipa> Chris_Stewart_5: CPrivKey uses OpenSSL DER serialization... which is 300 bytes or so for a private key
689 2016-08-04T20:50:41  <sipa> CPubKeys are 33 or 65 bytes
690 2016-08-04T20:50:49  <sipa> CKey is internally 32 bytes + compression flag
691 2016-08-04T20:52:18  <Chris_Stewart_5> ahh ok, that makes more sense. So basically CKey is the interface exposed inside of core... except for serialization. Something that could be implemented in a pull?
692 2016-08-04T20:52:55  <sipa> well there isn't one single obvious serialization for CKey
693 2016-08-04T20:55:52  <Chris_Stewart_5> Seems like the 32 byte serialization would be the intuitive one.. at least to me. Am I missing something here?
694 2016-08-04T20:56:53  <Chris_Stewart_5> oh nvm i see what you are talking about now, since CKeys can be both priv and pubs right?
695 2016-08-04T20:57:29  <sipa> no
696 2016-08-04T20:57:42  <sipa> CKey is a private key
697 2016-08-04T20:57:49  <sipa> but you need the compression flag too
698 2016-08-04T20:58:31  <sipa> and there is no deserialize because we use secure memory for private keys where possible
699 2016-08-04T21:02:29  *** TomMc has joined #bitcoin-core-dev
700 2016-08-04T21:08:55  <NicolasDorier> jtimon, I will soon make a PR similar to https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5  along with another change to parametize buriedsf height for regtest
701 2016-08-04T21:10:19  <jtimon> NicolasDorier: cool, but I believe the right time was in your PR, at least with the new ones if you didn't wanted to touch bip34
702 2016-08-04T21:11:03  <NicolasDorier> jtimon: I disagree, my PR was making a "big" consensus change so I wanted to keep it as simple as possible to review
703 2016-08-04T21:11:13  *** fengling has joined #bitcoin-core-dev
704 2016-08-04T21:11:28  <NicolasDorier> I wanted to be it merged the quickier I could so I can continue my work on libconsensus
705 2016-08-04T21:11:39  <jtimon> although I won't oppose the refactor, of course, just worry that it will be less acceptable
706 2016-08-04T21:12:16  <jtimon> how would using an array instead of two variables have been more complicated?
707 2016-08-04T21:12:26  <jtimon> anyway, as said I won't oppose
708 2016-08-04T21:12:34  *** Chris_Stewart_5 has quit IRC
709 2016-08-04T21:13:15  <NicolasDorier> jtimon: I don't think it wil lbe less acceptable, this buried deployment stuff will be a BIP. In the future other SF will end up using the same structure
710 2016-08-04T21:13:24  <NicolasDorier> anyway, I made two differents commit
711 2016-08-04T21:13:40  <NicolasDorier> we can take one and not the other
712 2016-08-04T21:13:51  <jtimon> NicolasDorier: yeah I guess the BIP is an opportunity to reorganize the struct
713 2016-08-04T21:15:15  <jtimon> anyway, I'm suffering from premature worry about controversy, let's not discuss about whether something will be acceptable or not when we both want it
714 2016-08-04T21:15:36  *** gabridome has joined #bitcoin-core-dev
715 2016-08-04T21:16:06  *** fengling has quit IRC
716 2016-08-04T21:20:56  *** gabridome has quit IRC
717 2016-08-04T21:21:05  *** spudowiar has joined #bitcoin-core-dev
718 2016-08-04T21:27:08  <GitHub193> [bitcoin] NicolasDorier opened pull request #8460: parametrize buried soft fork in regtest and refactor (master...buriedsf) https://github.com/bitcoin/bitcoin/pull/8460
719 2016-08-04T21:27:35  *** gabridome has joined #bitcoin-core-dev
720 2016-08-04T21:27:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
721 2016-08-04T21:27:46  <NicolasDorier> jtimon: worrying about controversy create a meta controversy :D
722 2016-08-04T21:28:21  <NicolasDorier> just created the PR
723 2016-08-04T21:31:31  *** TomMc has quit IRC
724 2016-08-04T21:33:17  *** gabridome has quit IRC
725 2016-08-04T21:33:48  <jtimon> yeah, I'm revieweing it
726 2016-08-04T21:34:59  *** gabridome has joined #bitcoin-core-dev
727 2016-08-04T21:35:16  <jtimon> and looking at 8418 too
728 2016-08-04T21:36:23  <jtimon> https://github.com/bitcoin/bitcoin/pull/8418/files#diff-c865a8939105e6350a50af02766291b7R981
729 2016-08-04T21:36:40  <jtimon>  .MineBlocksOnDemand() is starting too look like IsRegtest()
730 2016-08-04T21:37:12  <GitHub92> [bitcoin] jlopp opened pull request #8461: document return value of networkhashps for getmininginfo RPC endpoint (master...rpcMiningHelp) https://github.com/bitcoin/bitcoin/pull/8461
731 2016-08-04T21:37:39  *** gabridome has quit IRC
732 2016-08-04T21:38:16  *** gabridome has joined #bitcoin-core-dev
733 2016-08-04T21:43:11  *** gabridome has quit IRC
734 2016-08-04T21:43:59  *** gabridome has joined #bitcoin-core-dev
735 2016-08-04T21:44:24  *** TomMc has joined #bitcoin-core-dev
736 2016-08-04T21:44:54  <jtimon> oh, it was RegTest() or Params().NetworkID() == CChainParams::REGTEST directly, never mind, it's been a while since 3824, thinking out loud
737 2016-08-04T21:46:42  *** gabridome has quit IRC
738 2016-08-04T21:50:44  *** gabridome has joined #bitcoin-core-dev
739 2016-08-04T21:55:42  *** gabridome has joined #bitcoin-core-dev
740 2016-08-04T21:59:11  <jtimon> NicolasDorier: in #8460, how do you modify a couple of them? -buriedsfparams=bip65:1351,bip66:1251 ?
741 2016-08-04T21:59:29  <NicolasDorier> you repeat
742 2016-08-04T21:59:35  <NicolasDorier>  -buriedsfparams=bip65:1351  -buriedsfparams=bip66:1251
743 2016-08-04T21:59:47  <jtimon> ok, thanks
744 2016-08-04T22:02:04  <jtimon> https://github.com/bitcoin/bitcoin/pull/8418/files#r73610819
745 2016-08-04T22:03:06  *** gabridome has left #bitcoin-core-dev
746 2016-08-04T22:05:17  *** laurentmt has quit IRC
747 2016-08-04T22:06:52  *** spudowiar has quit IRC
748 2016-08-04T22:09:05  *** spudowiar has joined #bitcoin-core-dev
749 2016-08-04T22:09:54  *** Lauda_ has joined #bitcoin-core-dev
750 2016-08-04T22:10:48  *** Lauda_ has quit IRC
751 2016-08-04T22:11:27  *** TomMc has quit IRC
752 2016-08-04T22:12:26  *** Lauda_ has joined #bitcoin-core-dev
753 2016-08-04T22:12:44  *** fengling has joined #bitcoin-core-dev
754 2016-08-04T22:14:29  *** Lauda has quit IRC
755 2016-08-04T22:14:35  *** Lauda_ is now known as Lauda
756 2016-08-04T22:15:01  *** LaudaM has joined #bitcoin-core-dev
757 2016-08-04T22:17:11  *** LaudaM has quit IRC
758 2016-08-04T22:17:22  *** LaudaM has joined #bitcoin-core-dev
759 2016-08-04T22:17:26  *** fengling has quit IRC
760 2016-08-04T22:20:42  *** AaronvanW has quit IRC
761 2016-08-04T22:23:30  *** randy-waterhouse has joined #bitcoin-core-dev
762 2016-08-04T22:25:29  <NicolasDorier> jtimon: I think one bool is enough. fAllowOverwriteSoftforks which both BIP9 and buried SF use
763 2016-08-04T22:27:34  *** TomMc has joined #bitcoin-core-dev
764 2016-08-04T22:27:42  <jtimon> NicolasDorier: fine with me, sounds reasonable
765 2016-08-04T22:27:56  <NicolasDorier> will add commit to my PR later
766 2016-08-04T22:28:02  <jtimon> great
767 2016-08-04T22:37:00  *** spudowiar has quit IRC
768 2016-08-04T22:37:51  *** spudowiar has joined #bitcoin-core-dev
769 2016-08-04T22:39:48  <jtimon> NicolasDorier: you are not removing BIP34Height BIP65Height and BIP66Height in Consensus::Params
770 2016-08-04T22:41:17  <jtimon> you can leave:
771 2016-08-04T22:41:17  <jtimon>     /** Block hash at which BIP34 becomes active (for BIP30 optimization)*/
772 2016-08-04T22:41:17  <jtimon>     uint256 BIP34Hash;
773 2016-08-04T22:42:14  *** Guyver2 has quit IRC
774 2016-08-04T22:44:41  <NicolasDorier> oh
775 2016-08-04T22:51:03  *** LaudaM is now known as random4343
776 2016-08-04T22:51:12  *** random4343 is now known as LaudaM
777 2016-08-04T22:52:15  *** LaudaM is now known as CatWoman
778 2016-08-04T22:57:32  *** CatWoman has quit IRC
779 2016-08-04T22:57:43  *** LaudaM has joined #bitcoin-core-dev
780 2016-08-04T23:01:33  *** Giszmo has quit IRC
781 2016-08-04T23:04:27  <sipa> does anyone know offhand where the last segwit transaction in the chain is?
782 2016-08-04T23:04:30  <sipa> *testnet chain
783 2016-08-04T23:04:32  *** molly has joined #bitcoin-core-dev
784 2016-08-04T23:05:27  <sipa> i've reset the testnet chainparams for segwit to 0, and reconsiderblock/invalidateblock 100000 blocks, and it works fine
785 2016-08-04T23:07:34  *** molz has quit IRC
786 2016-08-04T23:13:43  *** fengling has joined #bitcoin-core-dev
787 2016-08-04T23:18:26  *** fengling has quit IRC
788 2016-08-04T23:27:09  *** molz has joined #bitcoin-core-dev
789 2016-08-04T23:30:21  *** molly has quit IRC
790 2016-08-04T23:39:19  *** d_t has quit IRC
791 2016-08-04T23:45:22  <NicolasDorier> jtimon: I fixed the nit as well as added the commit with the allowSfOverride
792 2016-08-04T23:48:59  *** belcher has joined #bitcoin-core-dev
793 2016-08-04T23:50:56  <jtimon> NicolasDorier: tiny last nit https://github.com/bitcoin/bitcoin/pull/8460/files#r73622457
794 2016-08-04T23:52:16  <NicolasDorier> jtimon: this is removed in later commits
795 2016-08-04T23:52:50  <NicolasDorier> oups
796 2016-08-04T23:52:52  <NicolasDorier> nop
797 2016-08-04T23:54:00  <NicolasDorier> removed :)
798 2016-08-04T23:54:30  <NicolasDorier> I did quite a lot of rebase to clean up the history. But now it should be stable
799 2016-08-04T23:55:08  <jtimon> good work
800 2016-08-04T23:56:52  <NicolasDorier> thanks, going to bed for real now (9am) :D
801 2016-08-04T23:58:52  <jtimon> oh, sorry about that